锁会导致select卡住而非变慢，典型表现为等待元数据锁或行锁，常见于长事务、未走索引的查询及gap lock；可通过innodb_lock_waits和data_locks定位阻塞源与锁类型；优化需聚焦索引设计、缩短事务、拆分批量操作及读写分离。
锁会让 SELECT 卡住，不是“慢”，是真等
会，而且影响非常直接——锁不是“等一等就过去”的小延迟，而是可能让查询从毫秒级拖到秒级甚至超时。你执行一条 SELECT 却迟迟没返回，大概率不是 SQL 写得差，而是被别的事务锁住了行、间隙或整张表。
典型现象包括：
-
SHOW PROCESSLIST显示状态为Waiting for table metadata lock或Locked - 明明只查几条数据，却卡住 2 秒以上
-
SELECT ... FOR UPDATE或普通UPDATE突然变慢，而源头是一个几十秒没COMMIT的长事务 - 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）→ 实际扫描行数远超预期，锁住更多行
怎么快速定位谁在锁、锁了什么？别靠猜
用两条命令组合查清楚，比看日志快十倍：
第一，查谁在等、谁在挡：
SELECT r.trx_id waiting_trx_id,
r.trx_mysql_thread_id waiting_thread,
r.trx_query waiting_query,
b.trx_id blocking_trx_id,
b.trx_mysql_thread_id blocking_thread,
b.trx_query blocking_query
FROM information_schema.INNODB_LOCK_WAITS w
INNER JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id;第二，查具体锁在哪几行、什么类型（RECORD/GAP/NEXT-KEY）：
SELECT * FROM performance_schema.data_locks;
注意：performance_schema.data_locks 需要提前开启相关 consumer（如 events_transactions_current 和 data_locks），否则返回空。
优化方向：索引、事务粒度、读写分离
锁性能问题多源于长事务、批量操作或过度使用 FOR UPDATE。真正有效的优化不是调参数，而是改逻辑：
- 所有
WHERE条件尽量走索引；建复合索引时，把高频过滤字段放最左 - 避免在事务里做 HTTP 调用、文件读写、睡眠等耗时操作——事务越长，锁持有时间越长
- 批量更新拆成小事务（比如每次 500 行），而不是一口气
UPDATE ... WHERE id IN (1..100000) - 读多写少场景下，用主从复制 + 读写分离，把
SELECT导到从库，天然避开主库锁竞争
最容易被忽略的一点：很多“锁慢”问题其实发生在应用层——比如一个事务开了但没关，或者 ORM 自动生成了无索引的 IN 查询。先确认是不是数据库真瓶颈，再动手调锁。
