数据库的读锁和写锁在业务上的应用场景总结

我们的原则通常是，优先使用锁范围小的查询模式，以尽量提升数据库的并发性能。即先选select ... ，不行再用select ... in share mode，再不行再提升为select ... for update。而结论1告诉我们何时无需用select ... for update，在此原则下，我们需要搞清楚的是何时需要用select ... for update，所以这个结论可以忽略。

我们的日常开发中，大部分情况下不需要自己单方面保证数据的一致性和业务逻辑的完整性，所有数据的修改方都可以通力合作。所以结论3可以暂时忽略。

所以，日常开发过程中，我们需记住：

1. 优先使用select ...

2. 当有关联关系的两个实体可能同时新增时，一方因新增实体修改关联关系，需使用select ... in share mode查询另一方数据进行关联关系的更新。

3. 如果读取出来的数据需要修改后再提交，需使用select ... for update读取数据。

如果你不幸需要与第三方系统（或难以修改的遗留系统）以数据库的方式进行集成时，需再多记住一点：

4. 当数据一致性和业务逻辑完整性只能由自己单方面保证时，且自己利用了数据的某种单调性增量处理数据时，需使用select ... in share mode查询更新数据。

如果还有其他漏掉的场景规则，欢迎大家补充。

数据库的读锁和写锁在业务上的应用场景总结

标签：技术   mysql数据库   需求   取数据   增量处理   历史版本   强制   结束   范围