背景
1、产品的问题点
- PG 复杂JOIN优化器有巨大提升空间
2、问题点背后涉及的技术原理
- PostgreSQL 有两套JOIN顺序、JOIN方法的自动优化方法. (包括子查询提升后的JOIN).
- 穷举.
- 有2个问题, 1. 表越多耗时越长(穷举组合N的阶乘-1种), 2. 一次性生成执行计划, 然后执行, 这种方法随着JOIN层级越深, JOIN相匹配记录的评估会越来越不准确.
- geqo, 类似图式算法(TSP)
- geqo算出的JOIN顺序, 相对来说不是很准确.
3、这个问题将影响哪些行业以及业务场景
- 偏数据分析的业务场景
- ERP系统(例如odoo, sap. 或者企业自己写的ERP软件), 使用框架生成的SQL, 通常会有很多表的JOIN(见过几十个上百个表的JOIN).
4、会导致什么问题?
- 无法高效率的得到最优的query plan. 原因是随着JOIN层级越深, JOIN相匹配记录的评估会越来越不准确.
5、业务上应该如何避免这个坑
- 可以使用AQO优化器, 对于复杂query有一定提升.
- 《PostgreSQL SQL动态优化器 aqo 背景论文》
- 《[未完待续] PostgreSQL PRO 特性 - AQO(机器学习执行计划优化器)》
- 《数据库优化器原理(含动态规划、机器学习建模优化器aqo) - 如何治疗选择综合症》
- 通过参数和SQL写法, 固定JOIN顺序
- join_collapse_limit, from_collapse_limit
- 使用HINT
- 使用sr_plan, 篡改执行计划
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 需要非常专业的DBA, 而且随着输入where条件的变化, 固定的执行计划并不一定符合所有条件.
- 第三方的aqo插件, 无法保障其品质.
7、数据库未来产品迭代如何修复这个坑
- 希望内核层面支持多表JOIN的动态优化执行计划, 而不是一次性生成执行计划, 然后按计划执行.
- 希望可以支持动态优化: （复杂QUERY优化、机器学习、AP类查询动态根据上一步的实际执行统计信息(每个node结果集的柱状图、高频词、记录数等)调整下一步nodeplan）
