需从nl2dsl生成逻辑、bi执行层、clickhouse三处协同定位腾讯混元sql慢查：先查dsl是否含未下推计算，再验执行sql的explain输出，接着关知识库/缩上下文测生成速度，最后核查clickhouse表引擎、索引与物化视图匹配性。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
排查腾讯混元驱动的SQL执行缓慢问题，需从NL2DSL生成逻辑、BI系统执行层、底层数据库（如ClickHouse）三处协同定位，不能只盯着大模型输出结果看。
确认慢查询是否源于NL2DSL生成阶段
打开WeData或DataXAI分析界面，在历史对话中找到该SQL对应的原始自然语言提问，点击“查看DSL解析”按钮。
检查DSL中是否包含未下推的计算逻辑：例如用户问“近30天各城市毛利率”，若DSL中将毛利/营收作为指标直接定义，而未在ClickHouse物化视图中预置该字段，则BI系统会在内存中逐行计算，导致响应延迟飙升。这种写法在小数据集上无感，但一旦扫描超千万行就会暴露。
对比同一问题的手工SQL：用相同维度和过滤条件，手动写出带WITH子句预聚合的ClickHouse SQL，执行耗时若显著低于NL2DSL生成版本，即可锁定是DSL生成策略问题。
提取并验证NL2DSL转换后的实际执行SQL
在WeData「智能分析」模块中，对已运行的分析卡片点击右上角「…」→「查看执行详情」→「展开原始SQL」。
复制该SQL，在ClickHouse客户端中执行EXPLAIN SYNTAX和EXPLAIN PIPELINE，重点观察：【是否出现多个JOIN未加PREWHERE】、【GROUP BY字段是否缺失ORDER BY优化提示】。
若发现EXPLAIN输出中存在ExpressionTransform节点频繁出现在Pipeline末尾，说明计算被拖到最终阶段，这是DSL未合理拆分聚合层级的典型信号。
检查知识库与上下文注入是否拖慢DSL生成
方法一：关闭知识库增强后重试
在提问前添加指令：“忽略所有知识库，仅基于通用语义理解生成DSL”。若响应速度明显提升，说明当前挂载的知识库存在冗余字段或低质量示例，干扰了NL2DSL的意图识别路径。
方法二：缩短上下文窗口
在WeData设置中将「对话上下文长度」从默认的10轮改为3轮，重新提交相同问题。混元Hy4 preview虽支持960K输入，但过长的历史对话会触发更复杂的思维链调度，反而降低首DSL生成速度。
注意：若业务强依赖多轮上下文（如连续钻取），不可盲目截断，应改用「显式锚定」方式——在新问题开头写明“基于上一轮‘XX城市销售额’结果，计算其环比”，而非依赖隐式记忆。
定位ClickHouse执行瓶颈
第一步：确认表引擎与分区键匹配性
执行SELECT engine,partition_key FROM system.tables WHERE name = 'your_table'，比对查询条件中的时间字段是否为分区键。若查询条件为WHERE dt = '2026-09-25'但分区键是toMonday(dt)，则无法剪枝，全表扫描不可避免。
第二步：检查稀疏索引粒度
运行SELECT * FROM system.parts WHERE table = 'your_table' AND active LIMIT 1，查看marks值。若单part marks超过1200，且查询常带高基数WHERE user_id IN (…)，说明跳数索引失效，需调整index_granularity或增加skip_indices。
第三步：验证物化视图是否命中
执行SELECT database,table,query FROM system.views WHERE query LIKE '%your_table%'，确认是否存在覆盖当前查询模式的物化视图。若存在但未被使用，大概率是NL2DSL生成时未声明MATERIALIZED VIEW HINT提示，需在WeData高级设置中开启「强制启用物化视图优化」开关。
