MySQL视图是否比复杂查询更高效?
P粉237689596
P粉237689596 2024-01-10 17:09:15
0
1
400

我在使用多个内连接的SELECT语句时遇到了问题。我的代码如下:

SELECT `movies02`.`id`, `movies02`.`title`,
       `movies03`.`talent`, 
       `movies07`.`character`,
       `movies05`.`genre`
  FROM `movies02`
 INNER JOIN `movies07` ON `movies07`.`movie` = `movies02`.`id`
 INNER JOIN `movies03` ON `movies03`.`id` = `movies07`.`performer`
 INNER JOIN `movies08` ON `movies08`.`genre` = `movies05`.`id`
 INNER JOIN `movies02` ON `movies08`.`movie` = `movies02`.`id`;

使用INNER JOIN获取电影中的演员以及他们扮演的角色似乎可以工作,但是获取电影类型的后两个连接不起作用,所以我想我可以将它们写成一个视图,然后在输出结果时将它们组合起来。因此,我最终会得到三个视图。一个用于获取类型、演员和角色,然后一个用于将所有内容组合在一起。问题是,这样做是否比使用一个大型的SELECT语句和多个连接更好?

我尝试了多次重写查询,并以多种方式进行了尝试

P粉237689596
P粉237689596

全部回复(1)
P粉827121558

当你执行涉及视图的查询时,MySQL / MariaDB的查询计划器会将所有视图和主查询组合成一个单独的查询,然后再确定如何访问表。因此,使用视图、公共表达式和/或子查询时,性能基本相同

也就是说,视图是封装一些查询复杂性的有用方式。

而且,您可以授予部分受信任的用户对视图的访问权限,而无需授予他们对底层表的访问权限。

视图的缺点与将任何应用逻辑放入数据库管理系统而不是应用程序中的缺点相同:更新更加棘手,更容易忘记更新。(如果您有一个可靠的应用程序更新工作流程,可以在更新应用程序代码时更新视图、存储函数和存储过程,则此问题不相关。)

也就是说,编写此类查询的一种好方法是从包含“顶级”实体的表开始。在您的情况下,我认为是电影。然后使用LEFT JOIN连接其他表,而不是使用INNER JOIN。这样,即使某些子实体(演员、类型等)缺失,您仍然可以在结果中看到电影。

专业提示:如果可以的话,为包含的实体(电影、类型、演员等)命名表,而不是使用whatever01whatever02之类的名称。能够查看查询并进行推理非常重要,而表名可以使这一点更容易。

热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板