Sind MySQL-Ansichten effizienter als komplexe Abfragen?

Question

Ich habe ein Problem mit SELECT-Anweisungen, die mehrere Inner Joins verwenden. Mein Code lautet wie folgt:

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`;

Die Verwendung eines INNER JOIN, um die Schauspieler im Film und die von ihnen gespielten Rollen abzurufen, scheint zu funktionieren, aber die letzten beiden Joins, um den Filmtyp zu ermitteln, funktionieren nicht, also dachte ich, ich könnte sie in eine Ansicht schreiben und sie dann kombinieren bei der Ausgabe des Ergebnisses aufstehen. Am Ende habe ich also drei Ansichten. Eine, um das Genre, die Schauspieler und Rollen festzulegen, und eine, um alles zusammenzustellen. Die Frage ist: Ist das besser als die Verwendung einer großen SELECT-Anweisung und mehrerer Verbindungen?

Ich habe mehrmals versucht, die Abfrage umzuschreiben, und zwar auf viele verschiedene Arten

Answer 1

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

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

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

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

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

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