为什么 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段——那里藏着锁冲突的真实路径。
