背景

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）