根本原因是事务持有行锁时间过长，导致后续请求排队等锁；常见于“查-改-更”中将耗时操作置于事务内，应将非数据库操作移出事务，并确保WHERE条件走有效索引、避免函数操作和前缀顺序错误。
为什么 SELECT ... FOR UPDATE 在高并发下会卡住？
根本原因不是 SQL 写得慢，而是事务持有行锁时间过长，后续请求只能排队等锁。常见于“查-改-更”三步操作中：先 SELECT ... FOR UPDATE 锁住记录，中间做业务逻辑（比如调用外部 API、复杂计算），最后才 UPDATE。这期间锁一直不释放，其他事务全被堵住。
实操建议：
- 把非数据库操作（如日志记录、HTTP 调用、格式转换）全部移到事务外，只在事务内做最小必要的读写
- 确认是否真需要
SELECT ... FOR UPDATE：如果只是防止重复下单，可用唯一索引 +INSERT IGNORE替代 - 避免在事务中使用
SLEEP()、USLEEP()或同步阻塞调用 - 检查隔离级别：默认
REPEATABLE READ下 gap lock 范围更大，若业务允许，可降为READ COMMITTED（需确认 binlog 格式兼容）
如何让 UPDATE 语句不扫全表？
UPDATE 慢 = 锁住的行多 + 锁持有时间长。最典型是没走索引的条件，导致 MySQL 扫描并锁住整个聚簇索引。
检查方法：
EXPLAIN UPDATE users SET status = 1 WHERE name = 'alice';如果
type 是 ALL 或 index，说明没走有效索引。
实操建议：
- 确保
WHERE条件字段有单列索引或符合最左前缀的联合索引（例如WHERE category = ? AND status = ?，索引应为(category, status)） - 避免在索引字段上做函数操作：
WHERE DATE(created_at) = '2024-01-01'无法用索引，改用WHERE created_at >= '2024-01-01' AND created_at - 注意隐式类型转换：比如
user_id是BIGINT，但传了字符串'123'，MySQL 可能放弃索引 - 批量更新时，用
IN列表要控制长度（建议 ≤ 500），过大易触发锁升级或执行计划退化
事务里能用 SELECT 不加锁吗？
能，但必须明确目的。普通 SELECT 在 REPEATABLE READ 下是快照读（不加锁），但一旦混入 SELECT ... FOR UPDATE 或 UPDATE，当前读就会触发行锁或 gap lock。
关键点：
- 只读查询尽量用纯
SELECT，别加任何锁提示 - 如果需要“看到最新数据但不锁”，可用
SELECT ... LOCK IN SHARE MODE（共享锁，允许其他读，阻塞写），但比无锁开销大 - 想彻底规避锁竞争？考虑将热点读写分离：写库用事务强一致，读库用从库 + 应用层容忍秒级延迟
- 注意 autocommit：PHP/Python 默认开启，但某些 ORM（如 Django 的
atomic块）会显式关掉，容易误以为“没写 UPDATE 就没事务”，其实 SELECT 也在事务里
为什么加了索引还是锁等待？
索引只是前提，不是万能解。常见陷阱包括：
- 范围查询锁住 gap：比如
WHERE id > 100，即使id有索引，也会锁住满足条件的所有间隙，其他事务插入新记录可能被堵 - 联合索引失效：查询用了部分前缀，但顺序错，例如索引是
(a, b, c)，却写了WHERE b = 1 AND c = 2，索引完全无效 - 统计信息过期：
ANALYZE TABLE没跑过，优化器选错执行计划，本该走索引却走了全表扫描 - 锁升级未发生但锁数量爆炸：一次更新 10 万行，即使每行都命中索引，也等于加了 10 万个行锁，InnoDB 有锁资源上限，可能直接拒绝新锁请求
真正压测时，别只看 QPS，盯紧 SHOW ENGINE INNODB STATUS\G 里的 TRANSACTIONS 和 LATEST DETECTED DEADLOCK 段——那里藏着锁冲突的真实路径。
