会，而且影响非常直接——锁不是“等一等就过去”的小延迟，而是可能让查询从毫秒级拖到秒级甚至超时，尤其在高并发更新场景下。
锁等待导致查询卡住的典型现象
你执行一条
SELECT却迟迟没返回，或者
UPDATE突然变慢，十有八九是被锁住了。这不是 SQL 写得不好，而是别的事务正占着你要查/改的行或表。 现象：执行
SHOW PROCESSLIST;时看到状态是
Waiting for table metadata lock或
Locked更隐蔽的情况：
SELECT ... FOR UPDATE或
UPDATE在等一个未提交事务释放行锁，而那个事务可能已挂起几十秒 MyISAM 表上执行
ALTER TABLE时，所有后续读写都会排队——因为它是表级锁
InnoDB 行锁 ≠ 没有锁竞争
InnoDB 默认用行锁，但行锁生效的前提是：查询必须走索引。否则会退化为**全表扫描 + 表级锁意向锁升级**，实际效果和 MyISAM 差不多。
没索引的WHERE条件（如
UPDATE users SET status=1 WHERE phone LIKE '%123%'）→ 极大概率锁整张表 范围查询（如
SELECT * FROM orders WHERE created_at > '2024-01-01' FOR UPDATE）→ 触发间隙锁（
GAP LOCK），不仅锁命中行，还锁住“空隙”，阻塞其他插入 复合索引使用不当（比如只用到了最左前缀的一部分）→ 实际扫描行数远超预期，锁住更多行
如何快速定位谁在锁、锁了什么
别靠猜，用这几条命令组合查清楚：
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;
这条语句直接告诉你：哪个线程（waiting_thread）在等谁（
blocking_thread），等什么语句（
waiting_query），对方又在执行什么（
blocking_query） 配合
SELECT * FROM performance_schema.data_locks;可看到具体锁在哪几行、什么类型（
RECORD/
GAP/
NEXT-KEY） 注意：
INNODB_LOCKS在 MySQL 8.0.21+ 已废弃，必须用
performance_schema.data_locks
锁对性能的真实权衡点
锁本身不是敌人，问题是“锁得是否必要、是否及时释放”。很多性能问题其实来自设计惯性：
长事务（比如 Web 请求里开了事务但没提交，中间调了外部 API）→ 锁持续几十秒，连带阻塞其他操作 批量更新用UPDATE ... WHERE id IN (1,2,3,...,10000)→ 一次性锁上万行，不如分批（
WHERE id BETWEEN ? AND ?） 过度依赖
SELECT ... FOR UPDATE做业务校验 → 其实可以用唯一索引 + 插入失败捕获来替代（乐观锁思路） 误以为
READ COMMITTED就万事大吉 → 它虽减少锁持有时间，但不解决幻读；而
REPEATABLE READ下间隙锁又容易引发意外阻塞
真正难的不是加锁，而是判断哪条数据该锁、锁多久、能不能绕开锁——这需要结合业务语义，而不是只看 SQL 是否“语法正确”。
