行级锁适合高并发下更新少量分散行、读写混合访问不同主键、且有合适索引精准定位的场景；表级锁更适用于大批量导入导出、全表只读统计及低并发短事务等维护操作。
行级锁性能通常优于表级锁，但实际效果取决于并发场景、数据分布和事务设计。高并发更新少量行时，行级锁减少锁冲突；而全表扫描或批量更新时，行级锁可能因锁管理开销反超表级锁。
行级锁适合什么场景
行级锁（如 InnoDB 的 RECORD LOCK）在以下情况表现更好：
- 事务只修改几行数据，且这些行在物理上分散（避免锁升级或间隙锁放大）
- 读写混合负载中，多个事务频繁访问不同主键值，例如用户订单更新、账户余额扣减
- 有合适索引支持 WHERE 条件，确保 MySQL 能精准定位并锁定目标行，而非退化为全表扫描加锁
表级锁何时更高效
表级锁（如 MyISAM 的 TABLE LOCK 或 InnoDB 中的 LOCK TABLES WRITE）在以下情况反而更快：
- 大批量导入/导出（如 LOAD DATA INFILE）、全表统计（COUNT(*)无WHERE）、重建索引等维护操作
- 低并发、高吞吐的只读报表查询，配合读锁可避免 MVCC 版本链遍历开销
- 事务逻辑简单、持续时间极短，且锁竞争几乎不存在，此时表锁的轻量机制省去行锁哈希查找与锁队列管理成本
真实性能差异怎么测
别只看理论，用压测验证：
- 用 sysbench 或自建脚本模拟 50+ 并发线程，分别执行 UPDATE t SET x=x+1 WHERE id=?（单行）和 UPDATE t SET x=x+1 WHERE status=0（范围大）
- 观察 Innodb_row_lock_waits 和 Innodb_row_lock_time_avg（information_schema.INNODB_METRICS）指标变化
- 对比开启 innodb_status_output_locks 后的 SHOW ENGINE INNODB STATUS 输出，看是否出现锁等待链或隐式锁转换
容易被忽略的关键细节
锁性能不是单纯比“粒度”，还要看引擎行为：
- InnoDB 行锁基于索引实现：没走索引会锁全表（实际是每行加锁，但效果等同表锁）
- UPDATE/DELETE 语句若触发唯一索引冲突，可能产生额外的意向锁与死锁检测开销
- 长事务持有行锁不释放，会导致其他事务在相同行上反复重试，平均响应时间陡增，此时表锁的确定性反而更可控
