锁本身不阻塞普通 SELECT，但隐式加锁会拖慢查询：在 REPEATABLE READ 下，JOIN 或事务中 SELECT 触发一致性读依赖 MVCC+undo log，高并发写导致 undo 堆积拉长扫描；全表扫描时被 X 锁 / 间隙锁阻挡，间接拖慢查询链路。
锁本身不阻塞普通 SELECT，但隐式加锁会拖慢查询
默认隔离级别（REPEATABLE READ）下，普通 SELECT 不加锁，但一旦涉及 JOIN、子查询、或被事务上下文包裹，InnoDB 很可能自动升级为一致性读（consistent read），背后依赖的是 MVCC + undo log —— 这本身不锁行，但若并发写多、undo 历史版本堆积，就会显著拉长查询扫描时间。更隐蔽的是：当查询走不到索引，触发全表扫描时，即使没显式加锁，也会因大量记录被其他事务的 X 锁 / 间隙锁“挡住”，导致 SELECT …… FOR UPDATE 或 UPDATE 等语句排队等待，间接拖慢整个查询链路。
- 检查是否真在“等锁”：执行
SHOW ENGINE INNODB STATUSG，重点关注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 管用十倍。
