背景
1、产品的问题点
- 世界上最痛苦的事情莫过于
- 打开了一个网页, 结果鼠标漏斗不停的转呀转.
- 执行了1条SQL, 但是不知道它什么时候能跑完.
- PG 无法预测大查询剩余执行时间
2、问题点背后涉及的技术原理
- 用户提交SQL后, 数据库经过parse, query rewrite, plan, execute几个阶段执行. 用户等待执行结果的返回.
- 执行过程并不知道跑到哪个NODE了, 已执行的NODE代价估算是多少, 花了多少时间? 还有哪些NODE没有执行, 分别的代价估算是多少, 预计还要花多久?
- 执行计划是什么, 当前执行到哪里了, 每个步骤花了多少时间, 扫描了多少条记录, 多少个数据块, IO时间多少, op CPU 多少. 还剩多少时间. 返回多少行, 已返回多少行, 花了多少时间.
- 《DB吐槽大会,第12期 - 没有自动成本校准器》
3、这个问题将影响哪些行业以及业务场景
- 通用
4、会导致什么问题?
- 当任务不可预期时, 无法对此作出正确的响应, 例如
- 报表类的业务, 每天2点开始跑报表, 早上8点老板们需要拿到报表结果进行重大决策, 现在是6点半, 报表还没跑完, 还剩多久能跑完? 8点前能不能跑完? 接下来应该怎么办?
5、业务上应该如何避免这个坑
- 《官人要杯咖啡吗? - PostgreSQL实时监测PLAN tree的执行进度 - pg_query_state - Oracle 兼容10046 - progress》
- 把代价因子参数校准为时间为标准, 这样就可以得到较为准确的单个SQL的执行时间.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 管理复杂度增加.
7、数据库未来产品迭代如何修复这个坑
- 通过执行计划的每个node的代价以及已执行的过程和代价(行选择性估算、代价 与 实际行选择性、耗费时间等对齐估算)进行校准, 估算剩余时间.
- 用户可配置
- 开关控制: 打开或关闭
- 阈值控制: 当代价大于多少的时候, 跟踪执行过程
