锁本身不阻塞普通 SELECT，但隐式加锁会拖慢查询
默认隔离级别（
REPEATABLE READ）下，普通
SELECT不加锁，但一旦涉及
JOIN、子查询、或被事务上下文包裹，InnoDB 很可能自动升级为一致性读（consistent read），背后依赖的是 MVCC + undo log —— 这本身不锁行，但若并发写多、undo 历史版本堆积，就会显著拉长查询扫描时间。更隐蔽的是：当查询走不到索引，触发全表扫描时，即使没显式加锁，也会因大量记录被其他事务的 X 锁/间隙锁“挡住”，导致
SELECT ... FOR UPDATE或
UPDATE等语句排队等待，间接拖慢整个查询链路。 检查是否真在“等锁”：执行
SHOW ENGINE INNODB STATUS\G，重点关注
TRANSACTIONS和
LOCK WAIT部分 确认查询是否走了索引：
EXPLAIN看
type是否为
ALL或
index，
key列是否为
NULL避免在长事务里执行大范围
SELECT：MVCC 版本链越长，可见性判断开销越大
SELECT ... FOR UPDATE 为什么一用就卡？
这不是“查询慢”，是主动排队等锁。该语句会在匹配行上加 X 锁（排他锁），如果这些行正被另一个未提交事务修改，当前查询就会阻塞，直到对方提交或超时（由
innodb_lock_wait_timeout控制，默认 50 秒）。更麻烦的是：它还会触发间隙锁（gap lock），锁定 WHERE 条件范围内的空档，防止幻读 —— 比如
WHERE id BETWEEN 10 AND 20，即使表中只有 id=12 和 id=18 两行，也会锁住 (10,12)、(12,18)、(18,20) 这三个间隙，其他事务插入 id=15 就会被拦住。 只在真正需要更新前“预占资源”时才用：
SELECT ... FOR UPDATE不该用于只读展示场景 确保 WHERE 条件能命中索引，否则会升级为表级锁（尤其在
READ COMMITTED下虽不加间隙锁，但没索引仍会锁全表） 超时不是万能解：调小
innodb_lock_wait_timeout只会让报错更快，不解决根本争用
表锁 vs 行锁：什么时候 MySQL 会退化成锁整张表？
InnoDB 默认行锁，但以下情况会“被迫”锁表或锁大片：
没有可用索引的UPDATE/
DELETE：优化器无法定位具体行，只能遍历并逐行加锁 → 实际效果接近表锁 显式使用
LOCK TABLES ... WRITE：MyISAM 风格操作，直接锁死整表，InnoDB 虽支持但严重损害并发 DDL 操作（如
ALTER TABLE加字段）：MySQL 5.6+ 支持
ALGORITHM=INPLACE，但若字段类型变更或需重建聚簇索引，仍会锁表数秒至数分钟 主从延迟场景下建索引：MySQL ≥ 5.5 中，
CREATE INDEX在主库执行后才同步到从库，期间主库写入积压，从库重放慢 → 表面是锁问题，实则是复制瓶颈
如何快速判断锁争用是不是性能瓶颈？
别猜，看指标。核心就两个状态变量：
SHOW GLOBAL STATUS LIKE 'Innodb_row_lock_%'：重点关注
Innodb_row_lock_waits（每秒等待次数）和
Innodb_row_lock_time_avg（平均等待毫秒数），> 50ms 就值得警惕
SHOW STATUS LIKE 'Table_locks%'：若
Table_locks_waited持续增长，说明有 MyISAM 表混用或 InnoDB 触发了隐式表锁（比如没索引的 DML） 配合慢日志：开启
long_query_time = 0抓取所有带锁等待的查询，再用
pt-query-digest统计锁等待占比 锁机制不是性能敌人，而是数据安全的守门人。真正伤性能的，是没索引的查询、过长的事务、以及把“读”和“写”逻辑揉在同一事务里还反复查同一张大表 —— 这些地方，比调
innodb_lock_wait_timeout管用十倍。
