以下时间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

其他limit 较大的SQL也存在同样问题 [image]

v7.5.7版本limit调整为100执行计划 SQL执行耗时：0.07秒 +------------------------------------+---------+---------+-----------+------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------…

默认索引B的explain analyze执行计划 +------------------------------------+----------+---------+-----------+-----------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------…

强制索引A的explain analyze执行计划 +---------------------------------+-----------+---------+-----------+---------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------…

去掉后的查询条件 `seller_id` = 1764332565 AND `spu_id` = 4399003 AND `sub_order_status` IN ( 10, 1000, 1100, 1200, 2000, 2003, 2004, 2005, 2006, 2007, 2010, 2015, 3000, 3010, 3020, 3030, 3035, 3040, 4000, 7000, 7500, …

去掉这个查询条件，也会走索引B，而不是索引A