MySQL:对ANALYZE TABLE的随机效果

Question

我有3个innodb表,比如说A,B和C.有一个查询可以连接这三个表来生成结果.

SELECT A.a, B.b, C.c
from A 
join B on A.id = B.a_id 
join C on C.id = B.c_id
where A.a = 'example' and B.b < 10;

在我使用'EXPLAIN'命令测试查询时,它给出了以下顺序:

B - C - A.

但是,这不是最佳的.所以我对所有表运行'ANALYZE TABLE',它给了我:

A - B - C.

,我相信这是正确的顺序.

然后我将SQL部署到生产中,并且无缘无故地,在1个月之后,执行计划切换回坏选项,即B-C-A.在那之后,我尝试了多次ANALYZE TABLE再次运行,但这一次,结果让我感到困惑.有时它也会给我B - C - A,有时它会给我A - B - C,有时甚至是其他执行计划.

所以我的问题是:

Answer 1

优化器选择重新排序表并使用基于内存统计信息的索引,包括表的大小,基数,值的分布,索引等.这些统计数据是估计值,并不是绝对准确的.

InnoDB会不时更新其统计信息,这就是运行ANALZYE TABLE时可能导致的结果.

但是,有些情况下,内存中的统计数据正好位于使优化器做出不同选择的尖端,因此您会看到这种翻转行为.

您可以通过在查询中指定索引提示来覆盖优化程序的默认算法以选择索引.

您可以通过指定覆盖优化程序的默认算法来重新排序表STRAIGHT_JOIN.这意味着您希望它按照您在FROM子句中给出的顺序读取表,并且不对它们重新排序.

您可以使用STRAIGHT_JOIN作为查询修饰符(如DISTINCT).在SELECT之后把它放好:

SELECT STRAIGHT_JOIN A.a, B.b, C.c
from A 
join B on A.id = B.a_id 
join C on C.id = B.c_id
where A.a = 'example' and B.b < 10;

但要小心使用索引提示或加入提示过于宽松.在数据的大小和分布稍微改变之后,优化器可以避免下周的翻转行为.如果您的代码中有太多覆盖,则可能会阻止优化器做得更好!