在MySQL的并发控制体系中，锁的粒度直接决定了系统的吞吐能力与响应延迟。行锁和表锁并不是简单的优劣关系，而是针对不同业务场景的两种取舍。理解它们背后的实现机制，才能在实际开发中做出正确选择，而不是凭直觉使用默认行为。
行锁与表锁的底层实现差异
MySQL的存储引擎决定了锁的能力边界。MyISAM引擎只支持表级锁，任何读写操作都会对整张表加锁，读锁之间兼容，但读写锁互斥。这意味着即使你只更新一行数据，其他会话对该表的查询也可能被阻塞。InnoDB则通过索引实现行级锁，它并不是锁住物理行，而是锁住索引项。如果一条SQL语句没有命中索引，InnoDB会退化为表锁，这是很多线上故障的根源。
行锁的实现依赖于InnoDB的事务与MVCC机制。当执行UPDATE user SET balance=balance-10 WHERE id=1时，若id是主键，InnoDB只在主键索引的对应记录上加排他锁。此时其他事务修改id=2的记录完全不受影响。而表锁由MySQL Server层管理，例如执行LOCK TABLES orders WRITE后，当前会话独占整张表，直到显式解锁。行锁的加锁成本高于表锁，因为需要遍历索引并维护锁结构，但在高并发点查场景中收益明显。
除了基本锁类型，InnoDB还有意向锁作为协调层。意向共享锁和意向排他锁是表级锁，用于标识事务即将在表中某些行上加锁，避免表锁和行锁的冲突检查遍历每一行。这种设计为混合锁粒度提供了基础，也让优化器能快速判断能否加表锁。
-- 查看当前锁等待情况 SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, b.trx_id blocking_trx_id FROM information_schema.innodb_lock_waits w JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;
基于业务场景的锁选择策略
选择行锁还是表锁，核心看三个维度：事务涉及的数据量、并发访问模式、以及索引使用情况。如果业务是单行更新且走唯一索引，例如扣减用户余额、修改订单状态，行锁是唯一合理选择。它能让数千并发各自操作不同记录而互不阻塞。反之，若要做全表统计修复、批量迁移历史数据，使用表锁反而更安全，因为行锁在海量记录下会产生大量锁对象，甚至触发死锁或锁内存溢出。
在低并发后台任务中，表锁的优势在于加锁极快且不会死锁。例如运营人员导出并清洗一张十万行配置表，用LOCK TABLES config WRITE锁住后处理，能避免中途被业务写入干扰。而高并发交易链路中，表锁是灾难，一次全表更新会让接口全部超时。此时必须确保SQL走索引，并使用SELECT ... FOR UPDATE精准锁定需要的行。
还要注意间隙锁的影响。InnoDB在RR隔离级别下，行锁会附带间隙锁，防止幻读。这意味着即使只锁一行，也可能锁住相邻区间，阻塞其他插入。如果业务不需要防幻读，可降到RC隔离级别减少锁范围。以下示例展示了行锁退化为表锁的典型错误：
-- name字段没有索引，行锁退化为表锁 UPDATE account SET status=1 WHERE name='test'; -- 正确做法：为name建立索引或改用主键 UPDATE account SET status=1 WHERE id=10086;
引擎特性与线上避坑实践
很多老系统仍在使用MyISAM，这类表在做读写混合时性能陡降，因为表锁的写优先机制会让查询排队。若系统出现大量Waiting for table level lock状态，首要方案是迁移到InnoDB。InnoDB在绝大多数场景下优于MyISAM，除非是纯只读且极少更新的报表库。
线上避坑的第一准则是监控锁等待。通过SHOW ENGINE INNODB STATUS能看到最近死锁信息，结合慢查询日志定位未走索引的更新语句。其二，控制事务长度，长事务持有行锁不放会拖垮整体。其三，批量操作拆小，例如每次更新五百行并提交，比一次性锁住十万行更稳健。最后，死锁发生时InnoDB会回滚代价小的事务，应用层需捕获异常重试。
以下Java代码片段演示了如何在代码中安全地使用行锁并处理重试，避免因为偶发锁等待导致请求失败：
public boolean deductBalance(long userId, int amount) {
for (int i = 0; i < 3; i++) {
try (Connection conn = dataSource.getConnection()) {
conn.setAutoCommit(false);
PreparedStatement ps = conn.prepareStatement(
"UPDATE user SET balance=balance-? WHERE id=?");
ps.setInt(1, amount);
ps.setLong(2, userId);
int rows = ps.executeUpdate();
conn.commit();
return rows > 0;
} catch (SQLException e) {
if (e.getErrorCode() == 1205) { // 锁等待超时
continue;
}
throw new RuntimeException(e);
}
}
return false;
}
综合来看，MySQL行锁和表锁的选择没有绝对标准，而是取决于索引设计、并发量与操作范围。日常开发应默认依赖InnoDB行锁，并确保SQL命中索引；在运维类大批量操作中主动用表锁简化控制。理清这两者的边界，才能构建既安全又高效的数据库层。