索引表中的每一列答案

【问题标题】：Indexing every column in a table索引表中的每一列
【发布时间】：2011-03-13 18:30:59
【问题描述】：

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

1) 对存储在内存中的表进行索引时是否会提高速度？

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

非常感谢。

【问题讨论】：

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

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

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

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

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

【讨论】：

【解决方案4】：

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

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

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

推论：不要为“标志”（0/1、T/F、M/F、Yes/No）或低基数列（yes/no/maybe、M/F/etc、day-of -周，...）。

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

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

【讨论】：