Mysql key: 单键能保证比复合键快吗？

Question

在以下两种情况下：

create table `Table` (
    `id` int(10),
    `column1` int(10),
    `column2` int(10),
    KEY (`column2`)
);

和

create table `Table` (
    `id` int(10),
    `column1` int(10),
    `column2` int(10),
    KEY (`column1`, `column2`)
);

现在考虑查询 select * from Table where column2=xxx;

第二种情况是否有可能比第一种情况更快，例如在行恰好密集地聚集在第 1 列上的情况下？

或者我们可以 100% 肯定地说第一种情况总是至少和第二种情况一样快吗？

我尝试搜索 composite/compound 按键速度，但与单键相比无法找到 100% 确定的答案。

Answer 1

阅读此处：https://dev.mysql.com/doc/refman/8.0/en/multiple-column-indexes.html

您的第一个索引会更快，因为查询将是索引扫描。您的复合索引实际上会导致查询成为慢速行扫描。只有当您要查找的列位于索引的最左侧时，才会使用该索引。由于 column2 不是最左边的，因此不会使用您的索引。

复合索引将仅用于如下查询：

select * 来自 Table 其中 column1='X'
select * 来自 Table 其中 column1='X' 和 column2='Y'

索引的重要之处在于知道您将如何查询数据。如果你不知道，过早优化可能对你没有任何好处。

Answer 2

Is there any possibility that the second scenario will be faster than the first scenario

是的。

这是 table 统计数据不正确以至于服务器错误地使用索引而不是 table 扫描的情况。例如，统计数据显示大约 1% 的行包含值 xxx，而实际上这是 50%。

当然出现这种情况的概率极低，但也不为零。

ANALYZE TABLE 将解决此问题。

Answer 3

字面回答：不保证100%；正如 Erik 指出的那样，“单列”与“复合”也不是正确的问题。

实际答案：给定 where column2=xxx，你应该有一个索引 starting with column2.

长答案：

数据库引擎在“缓存”索引和数据方面应用了很多智能。目标是使典型查询速度更快平均。

如果“搅动”不多，数据块和索引会被放入 RAM（“buffer_pool”），并且它们会存放在那里。重启后的 first 查询将不得不做一些 I/O 从磁盘中获取块；这很慢。后续查询可以跳过部分或全部提取；因此它们更快。也就是说，其他查询可以碰巧使_this 查询更快。因此，100% 被打败了。（如果不将一切都降低到恒定但低效的速度，就无法实现“100%”。）

更多关于创建最佳索引的信息：http://mysql.rjweb.org/doc.php/index_cookbook_mysql

让我进一步混淆。在您的特定 3 列 table 和您的特定 SELECT * 中，这是通常啄食顺序；从最慢到最快

INDEX(column2, column1) -- index's BTree is bulkier than the next
INDEX(column2)          -- good (and recommended)
INDEX(column2, column1, id) -- "covering" all of "*" is in the index

建立索引时，最好将所有重要查询（Select、Update、Delete）收集在一起，以决定使用哪一组索引。该问题仅解决了该特定模式的一个特定 select。

Mysql key: 单键能保证比复合键快吗？

Mysql key: is single key guaranteed to be faster than compound key?

mysql

compound-key

composite-key