SELECT卡住是因被事务锁住而非性能差；InnoDB行锁需走索引，否则退化为表锁；锁在事务提交后才释放，长事务易引发阻塞。
SELECT 卡住不是慢，是真被锁住了
MySQL里一条看似简单的 SELECT 突然卡住几秒甚至超时，大概率不是SQL写得差，而是被别的事务锁住了——不是“等一等就过”，是实实在在在排队。你查的那几行数据，可能正被另一个没提交的事务用 SELECT ... FOR UPDATE 或 UPDATE 锁着。
-
SHOW PROCESSLIST里状态显示Waiting for table metadata lock或Locked，基本可断定是锁问题 - 明明只查
id = 123，却卡住2秒以上？先查有没有长事务没COMMIT，尤其是那些执行了几十秒还没结束的UPDATE - MyISAM 表上跑
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：间隙锁，防止幻读，但会阻塞相同范围的INSERT -
lock_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，而是事务边界设计和应用层的锁意识。
