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+）。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
常用组合：
SELECT trx_id, trx_state, trx_started, trx_query FROM information_schema.INNODB_TRX;
再关联 INNODB_LOCK_WAITS 看谁在等谁，或者用 SHOW ENGINE INNODB STATUS\G 查最近的死锁详情。
-
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条件走了索引，否则锁的行数远超预期
锁的实际行为高度依赖隔离级别、索引结构和语句执行计划，光记“行锁好、表锁差”没用。真正踩坑的地方，往往出在“我以为只锁一行，其实锁了一片”。
