MySQL视图的使用可能导致性能问题，因为优化器不会将外部查询的谓词推入视图。创建覆盖索引（如(player, happened_in, score)）可以帮助优化查询，特别是当player为相等谓词，happened_in用于GROUP BY时。视图查询先物化为中间表，然后外部查询再应用player条件，导致可能不使用索引。对比独立查询，直接使用相同的覆盖索引可能更有效，避免中间表的生成。"
111855273,10296697,Vue中实现文件下载及状态判断,"['Vue框架', '前端开发', 'axios', 'HTTP请求']
如何让MySQL使用索引进行视图查询？ 简短的答案，提供了MySQL可以使用的索引。
在这种情况下，最佳索引可能是“覆盖”索引：
... ON highscores (player, happened_in, score)
MySQL可能会使用该索引，并且EXPLAIN将显示：player(由于player = 24(索引前导列上的相等谓词。GROUP BY(索引中的第二列))，可能允许MySQL优化使用 索引中包含score列将使查询完全可以从索引中满足，而不必访问(查找)索引所引用的数据页。
那是快速答案。 更长的答案是，MySQL不太可能使用player前导的索引进行视图查询。
为什么视图会导致性能问题
MySQL视图的问题之一是MySQL不会将谓词从外部查询“推”到视图查询中。
您的外部查询指定player。MySQL优化器在运行内部“视图查询”时不考虑该谓词。 该视图查询将在外部查询之前单独执行。 执行该查询的结果集“物化”； 也就是说，结果存储为中间MyISAM表。 (MySQL称它为“派生表”，当您了解MysQL执行的操作时，它们使用的名称就很有意义。)
最重要的是，当MySQL破坏形成视图定义的查询时，MySQL并未使用您在player上定义的索引。
创建中间“派生表”之后，然后使用该“派生表”作为行源来执行外部查询。 在外部查询运行时，将评估player谓词。
请注意，存储了视图查询中的所有行(对于您而言)是每行player的行，而不仅仅是在外部查询中指定相等谓词的行。
某些人可能无法料想到视图查询的处理方式，这是与其他关系数据库处理视图查询的方式相比，在MySQL中使用“视图”会导致性能
最低0.47元/天 解锁文章
1174
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
