ORDER BY DESC 本身不加锁，但会引发执行计划失控：若索引未显式声明 DESC 或使用函数/范围条件，将触发 filesort 和全表扫描，导致扫描行数暴增、间隙锁扩大、锁持有时间延长，极易引发死锁。
ORDER BY DESC 本身不加锁，但会让执行计划失控
MySQL 的 ORDER BY 语句本身不直接加锁，但它会显著影响优化器选择的访问路径。一旦排序无法走索引，就会触发 Using filesort 或全表扫描，导致扫描行数暴增、间隙锁范围扩大、锁持有时间拉长——这些才是死锁的温床。
尤其在 DESC 场景下，索引是否真正生效比 ASC 更敏感。很多开发者以为建了 (created_at) 就能支持 ORDER BY created_at DESC，其实 MySQL 5.7 完全不认这个方向；8.0+ 也必须显式声明为 (created_at DESC)，否则照样 Using filesort。
- 联合索引中，
WHERE shop_id = ? ORDER BY created_at DESC要求索引是(shop_id, created_at DESC)，写成(shop_id, created_at)在 5.7 下完全失效 -
ORDER BY ABS(updated_at)、ORDER BY IF(status='paid', 1, 0)这类函数包裹字段，索引必然失效 - 即使有索引，如果
WHERE条件用了IN ('a','b','c')这种范围等值，后续的ORDER BY列也无法复用索引顺序（除非是覆盖索引且排序列紧随其后）
降序扫描常隐含非唯一索引 + 范围锁组合
业务中用 ORDER BY ... DESC 的场景，往往对应“查最新 N 条”，比如 WHERE status = 'pending' ORDER BY created_at DESC LIMIT 10。这类查询天然容易落在非唯一索引上（status 通常不是唯一），而 status = 'pending' 可能匹配成百上千行。
这时 InnoDB 不是只锁结果里的 10 行，而是按索引物理顺序逐行扫描、加锁，直到凑够 10 条为止。由于是 DESC，它可能从 B+ 树最右叶子节点开始往左扫——而另一个事务用 ASC 扫，或两个事务扫描起始点不同，就极易出现 A 锁了 row5 再锁 row2、B 锁了 row2 再锁 row5 的交叉等待。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 非唯一索引上的
WHERE + ORDER BY查询，加锁顺序依赖 B+ 树遍历路径，不可控 - 没有
LIMIT或LIMIT值过大时，扫描行数可能远超预期，锁住大量无关间隙 -
SELECT ... FOR UPDATE ORDER BY created_at DESC比同条件的UPDATE更危险：前者明确要求锁定所有扫描到的行（含间隙），后者若走唯一索引可能只锁命中行
EXPLAIN 看不到的陷阱：filesort 阶段锁不释放
很多人只盯着 EXPLAIN 的 type 和 key 字段，却忽略 Extra 里是否出现 Using filesort。一旦出现，意味着 MySQL 必须把满足 WHERE 的所有行读出来、排序、再取前 N 条——而这些“读出来”的行，在事务结束前都处于被加锁状态（尤其是 READ-COMMITTED 以上隔离级别）。
更糟的是，如果数据量大、sort_buffer_size 不够，filesort 会落盘写临时文件，整个语句执行时间被拖长数秒，锁就挂在那里不动，期间任何想插入/更新相邻主键区间的事务都会被阻塞。
-
EXPLAIN显示rows=1000，但实际因filesort导致锁住了 1000 行 + 对应间隙，远超业务需要 - 应用层 BEGIN 后执行该查询但未 COMMIT，
trx_query在information_schema.INNODB_TRX中为空、trx_started却很久，说明锁被“捂”着不动 - 死锁日志里看不到明显冲突 SQL？很可能是这个
filesort查询持锁太久，成了其他事务的“背景墙”
真正有效的缓解手段不是加索引，而是收敛访问顺序
建对索引只是前提，关键是要让所有事务以**相同确定性顺序**访问数据。对 ORDER BY ... DESC 场景，不能只依赖索引方向，还要结合业务逻辑强制统一路径。
- 批量操作前，先用单表
SELECT id FROM t WHERE ... ORDER BY created_at DESC LIMIT 100拿到 ID 列表，再用UPDATE ... WHERE id IN (...)——InnoDB 对IN列表内部会按主键升序重排加锁，天然收敛 - 避免在应用层分页时“跳着取”，比如第一页取
ORDER BY id DESC LIMIT 0,20，第二页却用WHERE id ，两次结果集顺序稍有差异就可能打乱加锁顺序 - 高并发更新同一状态批次时，改用
UPDATE t SET status='processing' WHERE id IN (SELECT id FROM (...) ORDER BY id ASC LIMIT 100) AND status='pending'，确保子查询先排好序再更新
最易被忽略的一点：死锁日志里看到的“受害者”事务，往往不是问题源头，而是那个刚好撞上已持锁数秒的 filesort 查询的倒霉蛋。排查时别只盯报错 SQL，得顺着 trx_wait_started 时间往前翻，找那个沉默持锁的长事务。
