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