17370845950

根本原因是事务持有行锁时间过长，导致后续请求排队等锁；常见于“查-改-更”中将耗时操作置于事务内，应将非数据库操作移出事务，并确保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';

实操建议：

• 确保 WHERE 条件字段有单列索引或符合最左前缀的联合索引（例如 WHERE category = ? AND status = ?，索引应为 (category, status)）
• 避免在索引字段上做函数操作：WHERE DATE(created_at) = '2025-01-01' 无法用索引，改用 WHERE created_at >= '2025-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 段——那里藏着锁冲突的真实路径。