SELECT 卡住不是慢，是真被锁住了
MySQL里一条看似简单的 SELECT 突然卡住几秒甚至超时，大概率不是SQL写得差，而是被别的事务锁住了——不是“等一等就过”，是实实在在在排队。你查的那几行数据，可能正被另一个没提交的事务用 SELECT … FOR UPDATE 或 UPDATE 锁着。
SHOW PROCESSLIST 里状态显示 Waiting for table metadata lock 或 Locked，基本可断定是锁问题明明只查 id = 123，却卡住2秒以上？先查有没有长事务没 COMMIT，尤其是那些执行了几十秒还没结束的 UPDATEMyISAM 表上跑 ALTER TABLE，后续所有读写全排队；InnoDB 虽好，但一旦行锁退化成表锁，效果一样
为什么加了索引还锁整张表？
InnoDB 默认用行锁，但前提是查询**必须走索引**。否则引擎会退化为全表扫描 + 意向锁升级，实际效果和 MyISAM 表锁无异。
UPDATE users SET status=1 WHERE phone LIKE ‘%123%’：前缀模糊匹配，不走索引 → 极大概率锁全表SELECT * FROM orders WHERE created_at > ‘2024-01-01’ FOR UPDATE：范围查询触发 GAP LOCK，不仅锁命中行，还锁住间隙，阻塞其他插入复合索引 (a,b,c)，只写 WHERE a = 1 AND c = 3：最左前缀没用全，可能扫更多行、锁更多行，性能和锁开销双双上升
lock_mode 和 lock_type 在哪儿看？怎么对应到实际行为？
真正影响查询性能的，不是“有没有锁”，而是锁的类型（lock_type）和模式（lock_mode）。它们藏在 INFORMATION_SCHEMA.INNODB_TRX 和 INNODB_LOCKS（MySQL 5.7+ 已移除，改用 performance_schema.data_locks）里，但更实用的是从现象反推：
lock_mode X locks rec but not gap：普通行锁，只锁命中的记录，不影响新插入lock_mode X locks gap before rec：间隙锁，防止幻读，但会阻塞相同范围的 INSERTlock_mode X locks rec but not gap, waiting：当前事务正在等某条记录的X锁释放，说明有阻塞链lock_type TABLE 出现，基本就是表锁生效了——检查是否用了非索引字段、是否显式加了 LOCK TABLES、或是否触发了DDL元数据锁
容易被忽略的锁释放时机
锁不是执行完语句就放，而是**等到事务结束（COMMIT 或 ROLLBACK）才释放**。这意味着一个 SELECT … FOR UPDATE 开头的事务，哪怕后面只读了几行、什么都没改，只要没提交，锁就一直挂着。
应用层开启事务后，忘了 COMMIT 或异常没 ROLLBACK → 长时间持有锁，拖垮并发连接池配置不合理，连接复用时残留未提交事务 → 新请求继承旧锁状态，问题隐蔽难排查autocommit=0 的会话下，哪怕只执行一条 SELECT … FOR UPDATE，也得手动 COMMIT 才能释放锁
锁机制本身没有错，错的是我们常把“加锁”当成孤立操作，而忘了它绑定在整个事务生命周期里。真正要调优的，往往不是SQL，而是事务边界设计和应用层的锁意识。
评论(0)