在MySQL的并发控制体系中，锁机制是保证数据一致性的核心手段。表锁和行锁是两种最基础的锁定粒度，前者由服务器层实现，后者主要由存储引擎层（如InnoDB）实现。合理运用这两种锁，可以在数据安全和系统吞吐之间找到平衡。
一、MySQL表锁的实现与配置
表锁是MySQL中最直接的锁定方式，它作用于整张表。当会话对表加锁后，其他会话对该表的读写操作都会被阻塞，直到锁被释放。表锁的优势在于开销极小、不会出现死锁，但并发度很低。
在MyISAM、MEMORY等引擎中，表锁是默认的并发控制方式；InnoDB也支持表级锁，但通常以行锁为主。我们可以使用LOCK TABLES语句显式加锁，使用UNLOCK TABLES释放锁。以下示例展示了如何对两张表分别加读锁和写锁：
-- 对user表加读锁，对order表加写锁 LOCK TABLES user READ, order WRITE; -- 此时当前会话可以读取user、读取和写入order SELECT * FROM user LIMIT 10; INSERT INTO order (user_id, amount) VALUES (1, 100); -- 释放所有表锁 UNLOCK TABLES;
读锁（READ）允许多个会话同时读取表，但任何会话都不能写入；写锁（WRITE）则是排他的，只有持有锁的会话能读写，其他会话全部阻塞。在实际维护中，若要做全表批量更新或导数据，可以显式加写锁避免增量数据干扰。
表锁的配置相对简单，主要通过系统变量concurrent_insert控制MyISAM引擎的并发插入行为，以及通过lock_wait_timeout控制锁等待超时（该参数更多作用于元数据锁）。但需注意，LOCK TABLES会隐式提交当前事务，并且与InnoDB的行锁机制混用时容易引发逻辑混乱，因此InnoDB业务表应谨慎手动加表锁。
二、MySQL行锁的机制与触发条件
行锁是InnoDB引擎的核心特性，它只锁定被访问的索引记录，从而允许不同会话操作同一张表的不同行。行锁显著提升了高并发场景下的吞吐量，但如果使用不当，也会带来死锁和锁等待问题。
InnoDB的行锁是通过索引实现的。也就是说，只有当SQL语句通过索引条件命中记录时，才会加行锁；如果未命中索引或做了全表扫描，InnoDB会退化为表锁（实际是锁住了所有记录或间隙）。下面是一段典型的事务中加行锁的示例：
-- 会话A：开启事务并对id=1的记录加排他锁 START TRANSACTION; SELECT * FROM account WHERE id = 1 FOR UPDATE; -- 会话B：尝试修改同一行会被阻塞 UPDATE account SET balance = balance - 100 WHERE id = 1; -- 会话A提交后，会话B才能继续执行 COMMIT;
在上述代码中，FOR UPDATE会对符合条件的行加排他锁（X锁），其他事务若要修改这些行必须等待。除此之外，还有共享锁（LOCK IN SHARE MODE）用于读锁场景。InnoDB还引入了间隙锁（Gap Lock）和临键锁（Next-Key Lock）来解决幻读问题，它们锁住的是记录之间的区间。
行锁的配置重点在于事务隔离级别和锁等待超时。参数innodb_lock_wait_timeout设定了行锁等待的秒数，默认50秒；innodb_deadlock_detect开启后，InnoDB会自动检测并回滚死锁中代价较小的事务。开发中应尽量缩短事务长度、保证索引命中，从而降低行锁冲突。
三、表锁与行锁的使用场景对比
选择表锁还是行锁，本质上是在并发度与运维便利性之间做取舍。下面通过常见业务场景说明两者的适用边界。
当执行整表数据迁移、schema变更、低峰期批量刷数时，表锁是简单可靠的选择。因为这类操作本身不希望有其他会话并发读写，用LOCK TABLES能快速冻结表状态，且不会产生行锁带来的碎片与死锁排查成本。相反，在订单交易、库存扣减、用户余额变更等高频并发写入场景中，行锁几乎是唯一合理的方案，否则表锁会让整个业务表串行化。
| 对比维度 | 表锁 | 行锁 |
|---|---|---|
| 锁定粒度 | 整张表 | 单行或索引区间 |
| 并发性能 | 低，易阻塞 | 高，支持并发写不同行 |
| 死锁风险 | 无 | 有，需业务规避 |
| 适用引擎 | MyISAM、InnoDB均支持 | 主要由InnoDB支持 |
| 典型场景 | 批量维护、只读报表期冻结 | 高并发交易、细粒度更新 |
从表中可以看出，两者并非二选一的关系。例如，在InnoDB中做在线结构变更前，可以先用表锁阻断写入，变更完成再放开；日常交易链路则完全依赖行锁。混合使用时的关键是：显式表锁必须在事务外或明确提交点使用，避免与行锁形成嵌套等待。
四、常见配置参数与避坑建议
无论是表锁还是行锁，都依赖一组MySQL系统变量来控制行为。理解这些参数能帮助我们在出现锁等待时快速定位。
对于表锁，除了前面提到的lock_wait_timeout，还需关注read_only参数：当实例设为只读时，普通用户无法加写锁或修改数据，常用于备库。对于行锁，innodb_lock_wait_timeout与innodb_rollback_on_timeout决定了等待超时后是回滚整个事务还是仅报错。建议将长事务拆分为小事务，并把锁等待超时设在一个可接受的范围（如3到10秒），防止连接堆积。
-- 查看当前行锁等待超时设置 SHOW VARIABLES LIKE 'innodb_lock_wait_timeout'; -- 会话级调整等待超时为5秒 SET SESSION innodb_lock_wait_timeout = 5; -- 查看当前被锁阻塞的事务信息（MySQL 5.7+） SELECT * FROM information_schema.INNODB_LOCK_WAITS;
另一个常见误区是认为MyISAM完全不支持并发。实际上，在concurrent_insert=2时，MyISAM允许在表尾并发插入，即便有读锁。但在InnoDB环境中，开发者常犯的错误是在无索引字段上做UPDATE，导致行锁升级为表级锁定，拖垮全表。因此，所有写SQL都应先EXPLAIN确认走了索引。
最后，监控锁状态不能只靠报错。定期采集performance_schema中的锁相关表，或在运维平台配置锁等待告警，才能在业务受损前发现热点行竞争。表锁与行锁的配置没有银弹，贴合业务节奏做压测才是稳妥路径。