背景
我正在使用包含60多个表的MySQL InnoDB数据库，并且我正在创建不同的视图，以便在代码中快速轻松地进行动态查询。我对20 to 28 tables选择100 to 120 columns和row count below 5,000的INNER JOINS（没有多对多关系）有几点看法，它可以快速点亮。
实际问题
我正在创建一个包含34 tables的INNER JOINS（没有多对多关系）和使用150 columns选择约row count below 5,000的主视图，看起来它太多了。做一个SELECT需要永远。我想知道我是否达到某种视图大小限制，如果有任何增加它的方法，或任何技巧可以帮助我通过这个明显的限制。
重要的是要注意我不使用 Aggregate functions，因为我知道它们对性能的负面影响，这是我非常关注的方式。
答案 0 :(得分：5)
MySql不使用“System R算法”（我认为是Postgresql，Oracle和SQL Server使用），它不仅考虑了不同的合并算法（MySQL只有嵌套循环，尽管你可以伪造一个散列连接通过使用哈希索引），以及加入表和可能的索引组合的可能方式。结果似乎是查询的解析 - 以及查询执行 - 可以非常快速地达到一定程度，但是当优化器选择错误的数据路径时，性能会急剧下降。
看看你的解释计划，并试着看看a）性能下降是由于你要返回的列数（只做SELECT 1或其他）或b）如果是由于优化器选择表扫描而不是索引使用。
答案 1 :(得分：3)
视图只是一个命名查询。当您在MySQL中引用视图时，它只是将名称替换为实际查询并运行它。
您似乎将它与物化视图混淆，后者是您从查询中创建的表。之后，您可以查询该表，而不必再次执行原始查询。
物化视图未在MySQL中实现。
要提高效果，请尝试使用关键字explain来查看优化查询/视图的位置。