MySQL索引:为什么多列索引比单列索引表现差？
我正在学习索引，我想我应该尝试使用MySQL Sakila数据库进行一个实验。我有以下查询：
SELECT title, release_year
FROM film
WHERE release_year < 2010
AND rating = 'R';这是我尝试的第一个索引：
CREATE INDEX idx_releaseYear ON film(rating);当我运行查询时，MySQL解释返回了以下内容：
编辑:我对这些结果的解释是: MySQL使用索引(按等级排序)快速查找所有R级电影，然后检查索引返回的每一行的发行年份。
接下来，我创建了一个关于评级和release_year的索引：
CREATE INDEX idx_releaseYear ON film(rating, release_year);当我运行查询时，MySQL解释返回了以下内容：
编辑:我的期望: MySQL将使用索引(按等级排序，然后按release_year排序)快速查找所有R级电影和release_years < 2010，并且只使用电影表从索引返回的行中检索电影标题。尽管数据库中的所有电影都有相同的release_year，但我认为按评级对索引排序，然后发布年份将表现得更好(或者至少通过使用索引的第一列)作为第一个查询，因为在第一个查询中，它必须随机地检查发行年份。
为什么第一个单列索引比第二个多列索引更好？我认为他们的表现至少是一样的，因为评级是第一位的。
有一件事你应该注意：数据库中的所有电影都有2006年的发行年。
回答 2
Stack Overflow用户
发布于 2019-01-31 22:03:44
你的期望是对的。EXPLAIN是不精确的，不要太相信它。
WHERE release_year < 2010
AND rating = 'R'是(通常)最好用
INDEX(rating, -- first, because it is tested with '='
release_year) -- last, because it is a range.如果您能够同时运行这两种方式，那么观察SESSION STATUS LIKE 'Handler%'可以让您精确地查看读取的行(也许还可以写入临时表)。我讨论这种技术，http://mysql.rjweb.org/doc.php/index_cookbook_mysql#handler_counts。该博客还解释说，综合指数是最好的。
这方面的例外是：
- 也许统计数据表明，使用索引是不值得的；简单地扫描表可能更好。
- 或许将其扩展为“覆盖”会更好。(对所讨论的查询不适用。)
- 也许
PRIMARY KEY应该是这一对列，或者至少从它们开始。这避免了索引BTree和数据BTree之间的跳跃。
如果表只有一千行，您可能无法看到此索引、该索引或甚至没有索引之间的差异。但是，如果你期望这个表会增长，最好现在就建立最好的索引，而不是明年半夜当你的网站出现性能问题而忘记细节的时候。
副词..。如果你点击ORDER BY release_year LIMIT 5，综合指数真的会发光。这是因为索引可以用于所有的WHERE，所有的ORDER BY，并到达LIMIT，并且只触及5行。几乎任何其他场景都需要在临时表中收集大量行，对其进行排序，然后剥离5行。
Stack Overflow用户
发布于 2019-01-30 21:16:52
您的表中有195行。我不知道您的数据结构，但是很可能所有的行都适合于一个数据页，也许是两个。
索引不是为该大小的数据设计的。它们旨在使查询在大得多的数据集上运行得更快。使用索引有一些开销。例如，MySQL需要同时加载数据页和索引页来运行查询。通过减少正在阅读的页面数量，您可能得不到任何节省。
道理很简单。不要在非常小的查询上判断性能。通常，在这些情况下不需要索引，因为它们有额外的开销。
https://stackoverflow.com/questions/54449604
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号