MySQL：对ANALYZE TABLE的随机效果

我有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,有时甚至是其他执行计划.

所以我的问题是：

>为什么部署后执行计划会发生变化？
>除了固定执行计划(数据得到更新和快速变化,因此最佳计划可能在未来发生变化),有没有办法保证始终确保最佳计划？

解决方法:

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

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

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

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

您可以通过指定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;

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

标签：mysql,indexing,sql-execution-plan,explain
来源： https://codeday.me/bug/20190529/1179790.html