我在我运行的一个常见查询上运行了一个EXPLAIN语句，我很好奇为什么我的“possible_keys”只匹配我的索引字段的2/3。这是因为我使用LIKE子句吗？
这是我的MySQL控制台图像的链接，显示了我解释的查询和索引。 http://i.imgur.com/RCWb0to.png?1
如果您注意到我的索引中只有2个出现在possible_keys列中。
另外，为什么我的'key'列显示为NULL？ 我非常想更好地理解这一点，如果有一个很好的资源，我可以更详细地阅读这些内容，我将非常感谢链接和一些输入！
答案 0 :(得分：1)
Possible_keys仅考虑可能与当前查询相关的索引。您当然可以在表中包含其他索引，即使它们对此查询没有任何帮助。
MySQL考虑列中值的频率，并且可能决定不使用索引，因为您正在搜索无助于缩小行集的值。
通过类比，如果你看一本书后面的索引，你就不会在索引中看到“the”这个词。它只会列出书中的每个页码，这将是毫无意义的。在这种情况下没有理由使用索引，它实际上会使搜索更慢来使用索引。
同样地，您正在搜索术语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
您可能对我的演示文稿How to Design Indexes, Really感兴趣。
答案 1 :(得分：0)
您在开头使用的是％。所以它不能使用索引，它必须对该列进行全面扫描。所以它不会使用索引来扣除代码。
但是对于实际选择的索引，MySQL查询优化器会进行一些启发式猜测。如果它确定全表扫描比使用这些索引更快，它可以选择忽略现有密钥。如果需要，您可以强制mysql使用索引。您可以查看mysql文档以获取详细信息。
