会，锁会导致查询从毫秒级拖至秒级甚至超时；典型现象包括SELECT卡住、UPDATE变慢、SHOW PROCESSLIST显示Waiting for table metadata lock或Locked；InnoDB行锁需依赖索引，否则退化为表级锁；可通过INNODB_LOCK_WAITS与performance_schema.data_locks定位锁信息；锁的性能问题多源于长事务、批量操作或过度使用FOR UPDATE。
会，而且影响非常直接——锁不是“等一等就过去”的小延迟，而是可能让查询从毫秒级拖到秒级甚至超时，尤其在高并发更新场景下。
锁等待导致查询卡住的典型现象
你执行一条 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 是否“语法正确”。
