会，锁会导致查询从毫秒级拖至秒级甚至超时；典型现象包括SELECT卡住、UPDATE变慢、SHOW PROCESSLIST显示Waiting for table metadata lock或Locked；InnoDB行锁需依赖索引，否则退化为表级锁；可通过INNODB_LOCK_WAITS与performance_schema.data_locks定位锁信息；锁的性能问题多源于长事务、批量操作或过度使用FOR UPDATE。

mysql锁会影响查询性能吗_mysql性能权衡说明 第1张

会，而且影响非常直接——锁不是“等一等就过去”的小延迟，而是可能让查询从毫秒级拖到秒级甚至超时，尤其在高并发更新场景下。

锁等待导致查询卡住的典型现象

你执行一条 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 是否“语法正确”。