mysql事务中行锁和表锁有什么区别_mysql锁粒度解析

innodb默认行锁并发高但开销大，myisam仅表锁并发低；行锁依赖索引，无索引条件可能锁全表；rr级别有间隙锁防幻读，rc无；锁范围需通过innodb_trx等视图验证，无自动锁升级但锁过多会性能陡降。

行锁只锁被操作的那几行，表锁会锁整张表

mysql 的锁粒度直接决定并发能力。InnoDB 默认用 ROW_LOCK（行级锁），比如执行 UPDATE users SET name='a' WHERE id=10，只会给 id=10 这一行加锁；而 MyISAM 只支持 TABLE_LOCK（表级锁），哪怕你只更新一条记录，整个 users 表都不可写。

行锁靠索引实现——没走索引的 WHERE 条件（如 WHERE status='draft' 且 status 无索引），InnoDB 可能退化为锁全表（准确说是锁所有扫描到的行，但效果接近表锁）。

• 行锁开销大、加锁慢，但并发高、冲突少
• 表锁开销小、加锁快，但一写就堵住所有其他写操作
• 显式加表锁用 LOCK TABLES users WRITE，必须配对 UNLOCK TABLES

间隙锁（Gap Lock）是行锁的延伸，只存在于可重复读（RR）隔离级别

InnoDB 的行锁不是孤立的“某一行”，而是包含前后间隙。比如 select * FROM orders WHERE amount > 100 for UPDATE 在 RR 级别下，不仅锁住所有 amount > 100 的现有行，还会锁住这些行之间的“间隙”，防止其他事务插入新记录破坏当前查询结果的一致性。

这个机制能避免幻读，但也容易引发死锁或锁等待——特别是范围条件 + 无唯一索引时。

• 读已提交（RC）级别下，Gap Lock 被禁用，只锁实际命中的行
• INSERT 操作在 RR 下可能触发 Insert Intention Lock，和 Gap Lock 冲突
• 唯一索引等值查询（如 WHERE id=5）不会加 Gap Lock，只加 Record Lock

如何查当前有哪些锁在生效

不能只看 SQL 写得“像不像只影响一行”——锁的实际范围得靠运行时信息验证。最直接的方式是查 information_schema.INNODB_TRX 和 INNODB_LOCKS（MySQL 5.7）或 performance_schema.data_locks（8.0+）。

常用组合：

SELECT trx_id, trx_state, trx_started, trx_query  FROM information_schema.INNODB_TRX;

再关联 INNODB_LOCK_WAITS 看谁在等谁，或者用 SHOW ENGINE INNODB STATUSG 查最近的死锁详情。

• trx_state = 'LOCK WAIT' 表示该事务正在等锁
• 注意 trx_query 显示的是被阻塞前最后执行的语句，不一定是加锁源
• 8.0 中 data_locks 表里 LOCK_DATA 字段会显示具体锁住的主键值或间隙范围

锁升级不存在，但锁数量爆炸会导致性能陡降

MySQL（尤其是 InnoDB）没有“行锁自动升级为表锁”的机制。但如果你在事务中批量更新 10 万行，InnoDB 就真会持有着 10 万个行锁——内存占用飙升、锁管理开销变大、甚至触发 innodb_lock_wait_timeout 超时。

这时候看似是“锁太多”，本质是事务粒度太大。优化方向不是换锁类型，而是拆事务、加覆盖索引减少扫描行数、或改用 UPDATE ... LIMIT N 分批处理。

• 大批量更新尽量避开业务高峰
• 确认是否真的需要事务包裹全部操作——有些日志类更新可设为 AUTOCOMMIT=1
• 使用 EXPLAIN 确保 WHERE 条件走了索引，否则锁的行数远超预期

锁的实际行为高度依赖隔离级别、索引结构和语句执行计划，光记“行锁好、表锁差”没用。真正踩坑的地方，往往出在“我以为只锁一行，其实锁了一片”。