SELECT ... FOR UPDATE 锁范围过大导致性能差，主因是未加WHERE条件或未走索引致全表扫描；应确保命中索引、下推判断逻辑到WHERE、减少返回字段、按固定顺序访问资源，并酌情降级隔离级别至READ COMMITTED。
事务里 SELECT ... FOR UPDATE 锁太多，怎么缩范围
锁等待性能差，往往不是因为并发高，而是事务持有了不该持有的锁。最常见就是 SELECT ... FOR UPDATE 没加 WHERE 条件，或者条件没走索引，导致扫描全表、锁住整张表或大量无关行。
实操建议：
- 先用
EXPLAIN确认SELECT ... FOR UPDATE是否命中索引；没命中就加索引，别硬扛 - 避免
SELECT ... FOR UPDATE后再做业务判断——比如查出一堆用户再循环判断是否满足条件，这会让锁持续到整个循环结束；应把判断逻辑下推到WHERE子句中 - 如果只更新某几列，考虑用
SELECT id, version ... FOR UPDATE替代SELECT * ... FOR UPDATE，虽不减少锁行数，但降低网络和内存开销，间接缩短事务时间 - InnoDB 的行锁是“锁索引”，不是锁数据行本身；联合索引要注意最左匹配，
WHERE status = ? AND user_id = ?和WHERE user_id = ?可能锁的范围完全不同
事务太长导致锁持有太久，怎么拆
一个事务里混着查库、调外部 HTTP、格式化 JSON、写日志……这些操作不涉及数据库，却让锁一直挂着。MySQL 不知道你在等什么，它只看事务没提交，就继续 hold 住所有锁。
实操建议：
- 把非数据库操作（如发消息、调 API、生成文件）全部挪到事务 提交之后 执行
- 如果必须在事务内做判断再决定是否更新，优先用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO替代“先查后更”，省掉一次 SELECT 加锁 - 批量更新别用循环单条
UPDATE；改用UPDATE ... WHERE id IN (...)，但注意IN列表长度别超max_allowed_packet，否则报错Packets larger than max_allowed_packet are not allowed - PHP 中用
mysqli_begin_transaction()/pdo->beginTransaction()显式控制边界，别依赖框架自动管理——有些 ORM 默认把整个请求包进一个事务里
隔离级别设太高，无意中扩大锁范围
默认 REPEATABLE READ 下，SELECT ... FOR UPDATE 会加间隙锁（Gap Lock），防止幻读。但如果你的业务根本不需要可重复读（比如纯追加日志、单次扣减），那这个间隙锁就是纯负担。
实操建议：
- 确认业务能否接受
READ COMMITTED：它不加间隙锁，只锁命中的记录，锁范围小很多；但要注意此时UPDATE可能被其他事务覆盖（丢失更新），需配合version字段或WHERE条件校验 - 不要全局改隔离级别；用
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED在连接粒度调整，或在 ORM 中为特定 DAO 方法单独配置 -
READ UNCOMMITTED和SERIALIZABLE基本不用——前者读脏数据风险高，后者锁太狠，性能崩得比REPEATABLE READ还快
死锁检测开销大，怎么让它少触发
死锁不是锁等待，是两个事务互相卡住对方需要的锁。MySQL 每次检测都要遍历锁等待图，高并发下这个开销本身就会拖慢响应。频繁死锁说明事务访问资源的顺序不一致。
实操建议：
- 所有事务按固定顺序访问表和行：比如总是先更新
orders再更新order_items，且order_items按id ASC排序后再更新 - 用
SELECT ... FOR UPDATE ORDER BY id ASC显式排序，避免优化器选错执行计划导致行锁顺序混乱 - 监控
SHOW ENGINE INNODB STATUS输出里的LATEST DETECTED DEADLOCK，重点看 “WAITING FOR THIS LOCK TO BE GRANTED” 和 “HOLDS THE LOCK(S)” 两段，定位哪类语句总在抢同一组记录 - 应用层捕获
Deadlock found when trying to get lock错误后，不要无脑重试 3 次；先 sleep 随机毫秒（比如 10–100ms），再重试，避免重试风暴
真正难优化的从来不是单条 SQL，而是事务边界模糊、锁粒度和业务语义错配。比如一个“下单”事务里混着库存扣减、优惠券核销、积分变动，每个子动作都该有自己的锁范围和失败策略，而不是全捆在一起等 commit。
