在mysql中查找索引记录的最有效方法？

Question

嘿所有我拥有数百万行的表格，一些选择查询关键字来自3个字段

公司，用户，文章

将这三个字段的复合索引创建为键

会更快吗？

或MD5（公司，用户，articleid）一起，然后索引创建的哈希。

感谢

Answer 1

复合索引似乎是要走的路，特别是因为某些单独的键似乎是相当有选择性的。唯一可能导致可能避免复合索引方法的情况是复合键的长度非常长（平均而言超过64个字符）。

虽然基于MD5的索引会更小，因此可能会稍快一些，但它可以让您处理过滤具有给定MD5值的记录列表中的误报的任务。

在构建复合索引时，会出现索引在中列出的顺序的问题。虽然这在某种程度上说明了指数的潜在效率，但在只有两个（甚至一个......）密钥的情况下，排序问题对指数的潜在可用性产生了更大的影响。在查询中使用。一个人通常首先尝试并放置最具选择性的列，除非这些（这些）选择性列是在查询中找不到这些列的完整集合时最不可能使用的列。

Answer 2

您必须确定基准测试，但我相信您会发现三个字段的复合索引与这些字段的散列的单个索引之间不存在显着的性能差异。 / p>

在我看来，创建原本不会存在且仅用于索引的数据是一个坏主意（除非出于性能原因而进行去标准化，但您需要一个确凿的案例在这里做）。对于32字节的md5数据字段（减去任何字段开销），请考虑对于每100万行，您创建了大约额外的30 MB数据。即使索引的速度提高了一点点，您也只是提高了该表的磁盘和内存要求。您的索引查找时间可能会被磁盘查找时间抵消。添加一个事实，你必须有应用程序逻辑来支持这个领域，我会认为它是不值得的。

同样，唯一真正知道的方法是对它进行基准测试，但我不认为你会发现很多不同。

Answer 3

对于性能，您可能会看到复合索引的优势。如果您只选择索引中的字段，则这是“覆盖索引”情况。这意味着数据引擎不必从磁盘读取实际数据页，只需读取索引即可返回应用程序请求的数据。这可以大大提升性能。如果存储哈希值，则可以消除利用覆盖索引的可能性（除非您只选择sql中的哈希值）。

最好的问候， 别

Answer 4

支持复合键的另一个考虑因素：在（公司，用户，articleid）上使用复合键意味着当您按公司，公司+用户或公司+用户+ articleid搜索记录时可以使用它。所以你几乎有3个索引。