锁等待超时主因是UPDATE未走索引导致全表锁或被永久阻塞，应查INFORMATION_SCHEMA.INNODB_TRX、INNODB_LOCK_WAITS、INNODB_LOCKS三张表定位堵点。
锁等待超时不是超时参数没设够，而是你的 UPDATE 正在等一个永远不释放的锁——或者它自己根本没走索引，正在锁全表。
查清谁在堵路：立刻查三张系统表，别用 SHOW ENGINE INNODB STATUS
错误刚报出来时，SHOW ENGINE INNODB STATUS\G 看起来很“权威”，但它只保留最后一次死锁或锁等待快照，新事务一进来就覆盖掉了。真正能闭环定位的，是这三张表：
-
INFORMATION_SCHEMA.INNODB_TRX：找trx_state = 'LOCK WAIT'的事务，记下trx_mysql_thread_id和trx_started时间 -
INFORMATION_SCHEMA.INNODB_LOCK_WAITS：直接关联出blocking_trx_id和requested_trx_id，确认谁卡住了谁 -
INFORMATION_SCHEMA.INNODB_LOCKS：结合lock_trx_id和lock_rec_id，定位到具体哪一行、哪个索引页被锁住
别依赖 SHOW PROCESSLIST——它只显示连接状态，不反映行级锁关系；也别等错误日志里出现 SQL 再查，那时锁可能早已释放。
为什么 UPDATE 会锁全表：索引缺失导致行锁退化
InnoDB 的行锁依赖索引。一旦 WHERE 条件无法命中索引（比如用 name 字段更新但没建索引），引擎就会退化为全表扫描 + 表级意向锁，所有并发 UPDATE 都排队等一个锁。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 验证方法：
EXPLAIN UPDATE big_table SET status = 1 WHERE name = 'xxx';，如果type列是ALL或index，说明在扫全表 - 补索引不是万能解药，但能切掉 80% 锁问题：对高频更新字段加
INDEX，组合条件优先建联合索引 - 注意索引顺序：
WHERE status = ? AND created_at > ?应建(status, created_at)，而非反过来 - 避免隐式类型转换：比如
user_id是BIGINT，但传入字符串'123'，会导致索引失效
批量 UPDATE 别在一个事务里硬扛：拆小、分批、移出非 DB 操作
锁等待时间 = 事务开始到提交之间所有操作耗时。哪怕只更新 1000 行，如果事务里混了 HTTP 调用、日志写入、循环计算，锁就一直挂着。
- 把
SELECT FOR UPDATE后长时间处理再更新，改成先查id列表、再算逻辑、最后UPDATE ... WHERE id IN (...)单条提交 - 批量更新必须分片：每 100~500 行一个事务，用
COMMIT释放锁，而不是一次性提交 10 万行 - 发消息、调第三方 API、生成文件这些操作，一律移出事务块，改用异步队列或最终一致性补偿
高并发场景慎用 REPEATABLE READ：改用 READ COMMITTED 可减少间隙锁范围
REPEATABLE READ 隔离级别下，InnoDB 默认启用间隙锁（Gap Lock），用于防止幻读。但在高并发更新场景中，它会显著扩大锁范围，增加冲突概率。
- 如果业务能接受已提交读语义（比如订单状态变更、计数器累加），可将事务隔离级别临时设为
READ COMMITTED - 执行方式：
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;，或在应用层配置（如 Spring 的@Transactional(isolation = Isolation.READ_COMMITTED)） - 注意：
READ COMMITTED不影响当前事务内已读数据的可见性，但会减少其他事务被阻塞的可能性
最容易被忽略的是：你以为在“优化 SQL”，其实是在优化锁持有路径；你以为在“调参”，其实是在掩盖一个没提交的长事务——那个 trx_state = 'RUNNING' 却卡在 trx_started 十分钟前的线程，才是真正的堵点。
