我对我运行的一个常见查询运行了 EXPLAIN 语句，我很好奇为什么我的“可能键”只匹配 2/3 的索引字段。这是因为我使用了 LIKE 子句吗？
这是一个指向我的 MySQL 控制台图像的链接，其中显示了我解释的查询和索引。 http://i.imgur.com/RCWb0to.png?1
如果您注意到我的索引中只有 2 个出现在 possible_keys 列中。
另外，为什么我的“键”列显示为 NULL？ 我非常想更好地理解这一点，如果有一个很好的资源可以让我更详细地阅读，我将非常感谢一个链接和一些输入！
【问题讨论】：
Possible_keys 只考虑可能与当前查询相关的索引。您当然可能在表中还有其他索引，即使它们对此查询没有任何帮助。
MySQL 会考虑列中值的频率，并且可能决定不使用索引，因为您正在搜索无助于缩小行集范围的值。
以此类推，如果您查看一本书背面的索引，您不会在索引中看到“the”这个词。它只会列出书中的每个页码，这是没有意义的。在这种情况下没有理由使用索引，实际上使用索引会使搜索变慢。
同样，您正在搜索术语 empl_id=86560 AND week_number=22，但这些特定值可能在您的表中非常常见，以至于 MySQL 认为读取每一行并丢弃那些不 em> 匹配
术语deduction_code LIKE '%VIS%' 不能使用索引。以此类推，搜索电话簿并找到我在某人姓名的中间中带有“VIS”的每个姓名。这本书被排序的事实并没有帮助，你仍然需要从头到尾搜索它。
您的 key 列是 NULL，因为查询决定对此查询不使用索引。另一个线索是type 列显示“ALL”，这意味着它正在执行表扫描，读取表中的每一行。
见http://dev.mysql.com/doc/refman/5.6/en/explain-output.html#explain-join-types
您可能对我的演示文稿感兴趣，How to Design Indexes, Really。
【讨论】：
您在开头使用带有 % 的 like。所以它不能使用索引，它必须对该列进行全面扫描。所以它不会使用索引作为扣除代码。
但是对于实际选择的索引，MySQL 查询优化器会做一些启发式猜测。如果它认为全表扫描比使用这些索引更快，它可能会选择忽略现有的键。如果需要，您可以强制 mysql 使用索引。您可以查看 mysql 文档以获取详细信息。
【讨论】：