MySQL索引为NULL,但有可用的键

时间:2018-08-02 17:55:40

标签: mysql performance indexing

运行mysql查询时出现以下问题: 查询非常慢,当我使用解释查询键为null时,但可能的键可用并且顺序正确,我也尝试为每行添加独立索引,但键仍为NULL。

您可以在此处查看表,索引和mysql的解释:https://snag.gy/vcChl6.jpg

2 个答案:

答案 0 :(得分:1)

优化器可能刚刚决定没有理由使用索引。

由于您使用的是SELECT *,这意味着,如果它使用了索引,则必须使用索引中的主键才能返回并从聚集索引中查找所有必要的数据。这称为双重查询,通常对性能不利。由于该表中的记录很少,因此优化程序可能会决定,它可以轻松地进行全表扫描,从而更快地获得结果。

简而言之,这是预期的行为。

如果您只想SELECT的某些列,则将它们添加到t1索引中,然后仅SELECT仅添加所需的列,并带有给定的WHERE子句。然后应该使用索引。随着表大小的增长,一旦它估计双重查找比全表扫描便宜,它也可能会开始使用索引。

答案 1 :(得分:0)

一个猜测:大多数行是那个“项目”和那个“ lang”的。

优化器不了解这一事实,因此它采用的索引显然是最好的:

(id_project, id_lang)

同样好:(id_lang, id_project)

不公平... EXPLAIN提到了名为id_project和id_lang的索引(无用),但是索引列表显示了复合索引t1(id_project, id_lang)(有用)。

然后,如Willem所建议的,它必须在索引和表之间跳动。正常情况下(也就是说,当它具有足够的统计信息时),优化程序会说“哦,引用了约20%以上的表;让我们忽略任何索引。”

您可以做的事情:

  • 摆脱那个索引。
  • *更改为仅包含所需列的列表。特别是,如果您避免使用3个TEXT列,则会进行两个优化。或者,任何不超过255个字符的优化都可以更改为VARCHAR(255)
  • 使用其他一些过滤,排序,限制等方法。如果这是一个Web应用程序,您真的要获取约534行吗?