CTE 执行计划,sql慢

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
5.1.2. 现在使用CTE问题。

【概述】 场景 + 问题概述

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】

【应用软件及版本】

【附件】 相关日志及配置信息

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息

监控(https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

SELECT
d.year_month_desc ‘年月’,
i.theme ‘主题’,
i.index_name ‘指标’,
e.entity_name ‘组织’,
sc.scenario_name ‘场景’,
p.product_lvel1_name ‘产品大类’,
p.product_name ‘产品中类’,
re.region_name ‘客户区域’,
cu.customer_name ‘客户类型’,
mtd ‘当月累计’,
ytd ‘当年累计’
FROM
v_dwd_total_fact f
LEFT JOIN dwd_gaap_date d ON d.yyyymmdd = f.yyyymmdd
LEFT JOIN v_dwd_total_entity e ON f.entity_code = e.entity_code
LEFT JOIN dwd_gaap_index i ON f.index_id = i.index_id
LEFT JOIN dwd_gaap_scenario sc ON f.scenario_id = sc.scenario_id
LEFT JOIN v_dwd_total_product p ON f.product_code = p.product_code
LEFT JOIN v_dwd_total_region re ON f.region_code = re.region_code
LEFT JOIN v_dwd_total_customer cu ON f.customer_code = cu.customer_code
ORDER BY
f.yyyymmdd,
i.index_id;

执行计划过大,在附件执行计划.txt (7.9 MB)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

2 个赞

你对比涉及几个表联表join字段的数据类型是否一致?

2 个赞

v_* 这些表都是视图

2 个赞

这看下来不是 CTE 问题是你的 视图里面有 笛卡尔积吧

预估行数都超出屏幕宽度了。。
还是先逐一优化下 视图吧

1 个赞

tidb的视图查询条件能下推到底层基表吗

1 个赞

视图内 简单的 SQL 是 ok 的
left join 的应该都不行

1 个赞

主要是确定 这种语法能使用到索引吗,视图和表做关联。

1 个赞

还想问下。CTE 应该怎么玩。

1 个赞

先分几步走

  1. 视图内的 table 能不能有效使用索引。如果 SQL 书写规范肯定是可以的


    不过看你的 eq 关联方法 圈套了 function 这种是不能用 index 的。

  2. 确认下你的视图内的 SQL 使用方式 如果是 CTE 查询。这种带递归的 SQL 是没法用 逻辑转换改写来 改写 SQL 的。你可以理解为 每个 CTE 是一个 虚拟表 ,之间关联无法使用索引 。一般都会转化为 hashjoin 来解决

鉴于你这种超复杂 SQL ,建议将物理表 添加到 tiflash 上并开启 MPP ,使用 MPP 引擎来加速。注意v5.X 版本 可以支持的 下推函数有所不同(尤其使用了 window_function),需要关注每个子版本支撑的下推函数类型。
https://docs.pingcap.com/zh/tidb/stable/release-5.3.0#提升改进

或者 尝试将部分中间结果存储在 临时表中来启动加速的作用。需要 V530 版本的支持

2 个赞

ok. 我们这边回去测试一下

1 个赞

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。