背景
1、产品的问题点
- PG 不支持update | delete limit语法
2、问题点背后涉及的技术原理
- 更新、删除语法不支持限制条数的用法, 例如: 满足条件的有1000条, 而用户一次只想更新或删除10条.
3、这个问题将影响哪些行业以及业务场景
- 批处理、消费消息队列的内容
4、会导致什么问题?
- 如果符合条件的记录数很多, 可能导致一条SQL delete|update的记录数超多. 如果既有insert又有高吞吐的update,delete, 那么这种大批量操作将导致大量tuple旧版本的产生, 并且只能在事务结束后进行垃圾回收, 从而导致表膨胀.
- 分批操作可以降低单个事务的产生的dead tuple记录数. 解决单个事务内产生过多旧版本导致垃圾回收不及时的问题.
5、业务上应该如何避免这个坑
- 可以使用ctid来模拟update | delete limit语法
- 《在PostgreSQL中实现update | delete limit - CTID扫描实践 (高效阅后即焚)》
- 《PostgreSQL skip locked与CTE妙用 - 解决并发批量更新锁冲突带来的锁等待，提高处理吞吐》
- 《PostgreSQL SELECT 的高级用法(CTE, LATERAL, ORDINALITY, WINDOW, SKIP LOCKED, DISTINCT, GROUPING SETS, ...) - 珍藏级》
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 没有太大问题, 但是需要了解ctid的用法
7、数据库未来产品迭代如何修复这个坑
- 希望内核直接支持update | delete limit语法
