行级锁和表级锁的性能差异，关键不在“锁本身快慢”，而在于并发冲突概率和锁管理开销。高并发写场景下，行级锁通常更优；但若大量单行更新演变成“伪热点行”或索引失效导致全表扫描，行锁反而可能退化为表级效果，甚至更差。
明确锁粒度触发条件MySQL 的 InnoDB 默认加行级锁，但前提是走索引。如果 WHERE 条件未命中索引（如无索引字段、函数操作、隐式类型转换），InnoDB 会升级为锁全表（实际是锁所有索引记录+间隙，近似表级）。
用EXPLAIN确认执行计划是否走了索引，尤其注意type是否为const/ref/range，避免ALL UPDATE/DELETE 语句尽量只更新必要字段，避免SELECT *后再更新——减少事务持有锁时间主键或唯一索引更新最安全；普通二级索引更新可能引发额外的聚簇索引锁，需留意识别并化解“行锁变慢”的真实原因不是行锁慢，而是某些常见模式让行锁失去优势：《WEB开发者性能优化最佳实践》《WEB开发者性能优化最佳实践》下载热点行争用：比如库存扣减集中在商品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，快速定位隐式锁升级源头