mysql - 索引表中的每一列

Question

我有几个关于 MySQL 索引的问题：

1) 索引存储在内存中的表时是否有任何速度增加？

2) 当搜索我在列字段上匹配的表时，索引每一列是否会破坏索引的目的？

非常感谢。

score 23 · Accepted Answer

索引任何基于内存或文件系统的表将加快基于该列选择或排序结果的查询。这是因为索引像树结构一样工作，搜索距离取决于树的深度，它比列的行数增加得慢很多（对数）。

为每一列建立索引不会破坏索引的目的，但它会减慢插入和更新，因为这些更改会导致该表的每个索引的更新。此外，索引占用了数据库服务器上的空间，因此这是另一个需要考虑的缺点。

与此问题相关的其他 SO 要阅读的问题：

score 2 · Accepted Answer

1) 是的，当然。
2）不，它不会违背索引的目的。请记住，mysql 每个表不能使用超过 1 个索引，并且添加更多索引会减慢插入/更新/删除操作。因此，请避免创建未使用的索引，而是创建与您的查询最匹配的多列索引。

score 0 · Accepted Answer

磁盘空间中索引的成本通常是微不足道的。表更改时更新索引的额外写入成本通常适中。额外锁定的成本可能很高。

这取决于表上的读写比率，以及索引实际用于加速查询的频率。

索引会占用磁盘空间来存储，并且需要时间来创建和维护。未使用的没有任何好处。如果查询有很多候选索引，则可能会因为让服务器为查询选择“错误”的索引而减慢查询速度。

使用这些因素来决定您是否需要索引。

通常可以创建永远不会使用的索引——例如，一个只有两个可能值的（非空）字段上的索引几乎肯定是没用的。

您需要解释您自己的应用程序的查询，以确保经常执行的查询尽可能使用合理的索引，并且创建的索引不超过所需的索引。

score 0 · Accepted Answer

关于 Q1...查询优化器有时会选择扫描表，即使存在“非常好”的索引。这种权衡是基于一个复杂的算法，但是，作为一个经验法则：

如果需要使用超过约 20% 的索引，则忽略索引并简单地扫描表被认为更有效。

这样做的原因是：使用索引意味着扫描索引 BTree（看起来很像一张表），然后跳转到数据 BTree 以查找记录。如果它只是扫描数据，就可以避免这种来回。缺点是它需要忽略多达 80% 的行。

推论：不要费心索引“标志”（0/1、T/F、M/F、是/否）或低基数列（是/否/也许、M/F/等、星期几、 ...）。

另一方面，从低基数列开始的复合索引可能非常有用：

WHERE deleted=0 AND created_at > NOW() - INTERVAL 1 DAY
INDEX(deleted, created_at)

4 回答 4