plan_replayer_12111524.zip (193.0 KB)

健康度都没有问题

这个参数默认就是on，但是优化器估的不准。

这些都是session级别的，应用程序不太能适配，且应用改造比较大。

收集完统计信息也是这样

将 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]

由于业务逻辑，所有的DML操作都是显示事务。但出现执行耗时较长的DML时，提示有大量的锁。 [img_v3_02qe_b20e7b9c-ece3-480e-9296-4dd75f40687g] [img_v3_02qe_a9818e73-0b45-45ff-8afc-e69011a668bg] tidb server节点日志 [2025/09/24 14:40:34.996 +08:00] [INFO] [prewrite.go:444] ["prewrite encounters lock"] [session=3971944250] [txnID=4610316133958945…

未发现异常 [image] [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…

开启 tidb_enable_ordered_result_mode参数后，v7.5.7可以走到正确的执行计划。 不知道开启该参数是否会导致其他问题 https://docs.pingcap.com/zh/tidb/v7.5/system-variables/#tidb_enable_ordered_result_mode

这个值默认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