行级锁和表级锁的性能差异，关键不在“锁本身快慢”，而在于并发冲突概率和锁管理开销。高并发写场景下，行级锁通常更优；但若大量单行更新演变成“伪热点行”或索引失效导致全表扫描，行锁反而可能退化为表级效果，甚至更差。
明确锁粒度触发条件
MySQL 的 InnoDB 默认加行级锁，但前提是走索引。如果 WHERE 条件未命中索引（如无索引字段、函数操作、隐式类型转换），InnoDB 会升级为锁全表（实际是锁所有索引记录+间隙，近似表级）。
- 用 EXPLAIN 确认执行计划是否走了索引，尤其注意 type 是否为 const/ref/range，避免 ALL
- UPDATE/DELETE 语句尽量只更新必要字段，避免 SELECT * 后再更新——减少事务持有锁时间
- 主键或唯一索引更新最安全；普通二级索引更新可能引发额外的聚簇索引锁，需留意
识别并化解“行锁变慢”的真实原因
不是行锁慢，而是某些常见模式让行锁失去优势：
- 热点行争用：比如库存扣减集中在商品ID=1001，大量事务排队等同一行锁 → 改用“分段库存”（如按仓库/批次拆分）或乐观锁+重试
- 长事务持锁：事务中混入日志打印、远程调用、循环处理 → 拆分为多个短事务，或把非DB操作移出事务边界
- 间隙锁阻塞：范围查询（如 WHERE price BETWEEN 100 AND 200）会锁住间隙，导致插入被阻塞 → 若业务允许，可考虑关闭 innodb_locks_unsafe_for_binlog（5.6+已废弃，新版用 READ COMMITTED 隔离级别规避）
表级锁不是“坏选择”，而是有适用场景
MyISAM 或显式 LOCK TABLES 在以下情况反而更高效：
- 批量导入/重建报表表（一次性写入+后续只读），此时表级锁省去逐行加锁开销
- 数据迁移或归档任务，需短暂阻塞写入但不希望锁等待堆积 → 配合 SET lock_wait_timeout = 3 快速失败，避免雪崩
- 读多写少且写操作极少的配置表，用表锁简化逻辑比维护复杂行锁更稳妥
验证与持续观测不能只看“是否加锁”
真正影响性能的是锁等待时长和事务回滚率：
- 监控 SHOW ENGINE INNODB STATUS\G 中的 TRANSACTIONS 和 SEMAPHORES 区段，重点关注 lock wait 和 os_waits
- 用 performance_schema 查看锁等待事件：events_waits_history_long 过滤 wait/synch/mutex/innodb/...
- 慢日志中增加 long_query_time=0 并开启 log_queries_not_using_indexes，快速定位隐式锁升级源头
