将 tidb_opt_prefer_range_scan参数调整为on可以满足预期,但是不知道是否有其他影响。
[image]以下时间update耗时均为5秒+
09-23 10:23 均正常
09-23 13:49 store-5
09-23 15:03 均正常
09-23 20:17 均正常
09-23 20:58 store-16
09-23 21:02 store-16
09-23 21:25 store-16
09-24 08:47 均正常
09-24 14:40 均正常
09-24 15:03 均正常
[image]
[image]改SQL的话,子查询一个排序、外层再套一个排序,岂不是很别扭。
能在不改变SQL的情况下,尽量按照v5.3.3版本的查询结果显示嘛
16:58:07 [10.221.202.67] {root} (dw_trade_order_seller_db) > explain analyze SELECT /*+ USE_INDEX(trade_order_seller idx_seller_id_create_time_us)*/
-> id,
-> order_no,
-> sub_order_no,
-> biz_type,
-> biz_channel,
-> biz_code,
-> biz_id,
-> abs(sub_or…
这个值默认100,我没有调整。
测试的时候我调大也没用,不生效。
集群只有版本区别,索引都是一样的。7.5.7版本也有index:idx_selid_status_close_time(seller_id, sub_order_status, close_time),但是SQL选择了走index:idx_seller_id_create_time_us(seller_id, create_time_us)
怀疑是选错了索引导致预估的行数不一样,当把limit10000调整为100,预估行数就一致了。
执行计划是不一样的,正常的执行计划是Limit_13,而异常的执行计划走了TopN_9
v7.5.7版本limit调整为100执行计划
SQL执行耗时:0.07秒
+------------------------------------+---------+---------+-----------+------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------…
默认索引B的explain analyze执行计划
+------------------------------------+----------+---------+-----------+-----------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------…
强制索引A的explain analyze执行计划
+---------------------------------+-----------+---------+-----------+---------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------…