数据库里到底怎么挑表锁和行锁，啥时候用哪个才合适呢？

关于数据库里到底怎么挑表锁和行锁，啥时候用哪个才合适，这确实是一个在实际开发中经常会让人纠结的问题，选择哪种锁不是一个死规定，而是根据你具体要做什么操作、对数据一致性的要求有多高，以及你愿意承受多大的性能开销来决定的，我们可以把它想象成收拾房间：你是想把整个房间（表）的门锁上不让任何人进来，还是只把某个抽屉（行）锁上,让别人还能进房间收拾其他东西？

我们得搞清楚表锁和行锁最基本的区别。

表锁，顾名思义，就是锁住整张表，当某个连接（比如一个用户的操作）给表加了一个写锁（比如为了更新数据），那么在这个锁被释放之前，其他任何连接都不能对这张表进行读或写操作（这里指类似的写锁或需要排他的操作），它们必须排队等着，这就像你开会时把会议室的大门锁了，宣布“里面在搞大扫除，谁也别进来”，那么所有人都得在门口等着，直到你打扫完开门，表锁的优点是开销小，加锁快，因为数据库只需要管理一个锁就行了，但缺点也显而易见，就是并发能力太差了，非常容易导致其他操作阻塞，在高并发的场景下,整个系统可能会卡死。

行锁，是只锁住需要操作的那一行或多行数据，而不是整张表，其他连接仍然可以访问和修改这张表里没有被锁住的其他行，这就像你在一个开放的办公区，只把自己工位的抽屉锁起来修电脑，其他同事依然可以自由出入办公区，使用他们自己的工位，行锁的优点是粒度细，并发度高，多个操作可以同时进行，不容易产生阻塞，但缺点则是开销大，加锁慢，因为数据库需要为每一行操作的数据都维护一个锁，如果一次性更新几万行，就可能产生几万个锁,管理这些锁本身就会消耗大量内存和CPU资源。

具体什么时候该用哪个呢？这个选择很大程度上取决于你的业务场景和操作类型。

倾向于使用表锁的场景主要有以下几种：

1. 需要操作表中绝大部分甚至全部数据时。 你要给全公司的员工薪水都上涨10%，这涉及到更新整张员工表，这时候如果你用行锁，会给每一行记录都加上锁，锁的开销会非常大，可能比直接锁整张表还要慢，在这种情况下，直接使用表锁反而效率更高，因为只需要管理一个锁，一些数据库系统在执行类似UPDATE table_name SET column = value这种没有WHERE条件的全表更新时,可能会自动升级为表锁。
2. 执行涉及多表的复杂查询或数据迁移，并且需要绝对的数据一致性时。 你要计算某个关键的业务指标，这个计算需要连续读取A、B、C三张表，并且要求在这期间三张表的数据都不能有任何变化，为了保证你读到的数据是“一瞬间”的快照，避免在读取过程中有其他操作修改数据导致计算结果不准，你可能会选择一次性给这三张表都加上读锁，这样可以确保你得到完全一致的数据视图，但这种操作要非常谨慎，并且要尽快完成释放锁,否则对线上业务影响巨大。
3. 当业务逻辑本身就需要串行化执行时。 有些极其特殊的场景，比如某个核心配置表，要求同一时间只能有一个人修改，修改时必须完全排他，这种情况下，用表锁来实现最直接、最不容易出错。

而倾向于使用行锁的场景则更为常见，尤其是在现代的业务系统中：

1. 高并发的在线交易处理系统。 这是行锁最典型的用武之地，比如电商网站的秒杀场景，成千上万的用户同时抢购100件商品，核心操作是更新商品的库存数量（UPDATE products SET stock = stock - 1 WHERE id = 123 AND stock > 0），这里必须使用行锁，只锁住ID为123的这件商品记录，这样，多个用户虽然同时在抢，但数据库会让他们排队修改这一行数据，既能保证库存不会超卖（一致性），又不会影响其他不同ID商品的正常购买（高并发），如果这里用了表锁，那整个商品表在秒杀期间都会被锁住，所有用户都无法浏览或购买其他商品,网站就卡死了。
2. 大多数普通的增删改查操作。 只要你的WHERE条件能够精准地定位到少量的几条记录（比如通过主键ID更新），数据库默认就会使用行锁，比如修改某个用户的个人信息、审核一条订单状态等，这些操作是日常业务中最普遍的,行锁保证了系统能够同时服务大量用户。
3. 当业务无法接受长时间等待时。 如果你的应用要求快速响应，那么就应该尽量避免使用可能导致长时间阻塞的表锁，行锁虽然也可能有等待（比如两个人同时修改同一条数据），但等待的范围被限制在少数几条记录上，不会扩散到整张表，从而降低了系统“卡顿”的风险。

除了场景，数据库引擎本身的支持也是关键因素。

MySQL流行的InnoDB引擎主要支持行级锁，也支持表锁，而MyISAM引擎只支持表锁，如果你用的是MyISAM引擎，那么讨论行锁就没有意义了，所有并发问题都只能通过表锁机制来解决，这也是为什么MyISAM不适合高并发写操作的原因，技术选型时,数据库引擎对锁的支持程度也是一个重要的考量点。

总结一下选择的思路：

• 看操作范围： 动大部分数据？考虑表锁，动小部分数据？坚决用行锁。
• 看并发要求： 要求高并发，允许多个用户同时搞？用行锁，不要求高并发，甚至可以接受短暂停摆？或许可表锁。
• 看一致性要求： 要求一个绝对静止的、跨多表的数据视图？表锁能保证，只要求单条或少量数据在修改时不被打扰？行锁就够了。

最后要记住，现代数据库的查询优化器通常会帮我们做出初步的选择，当我们执行一条SQL语句时，数据库会根据SQL的类型（是SELECT还是UPDATE）、WHERE条件的 selectivity（能过滤掉多少数据）、表的大小以及当前的系统负载，来自动决定使用哪种锁或者锁的粒度，我们的责任更多在于设计合理的SQL（比如尽量使用索引让WHERE条件更高效，避免全表扫描导致锁升级）、选择合适的数据引擎，以及在非常特殊的业务场景下，通过数据库提供的手动加锁提示（如MySQL的LOCK IN SHARE MODE、FOR UPDATE）来显式地控制锁行为,但后者需要非常谨慎地使用。

（主要思路参考自《高性能MySQL》、数据库系统概论类教材及行业实践中的常见总结）