我在 GitHub issue 里面也回复了。 如楼上所说，cop 这里是显示问题，实际上有 ExchangeSender 算子的肯定是 mpp 而不是 cop。 tidb 在之前版本开始支持输出另一种格式的执行计划。从 v7.4 开始，dashboard 开始使用这种新的格式的执行计划来做展示，这个执行计划是没有这个显示问题的，并且和 EXPLAIN ANALYZE 的格式基本完全一样，只是多了一列 estimated cost。 在 v7.4 之前，也可以看“图形”面板的计划，这个也是没有这个显示问题的。或者也可以从对应的系统表里面查 BINARY_PLAN 列用 tidb_deco…

目前 TiDB 提供了 agg_to_cop() Hint 指示优化器下推聚合函数，可以试下看能不能解决问题。 文档：https://docs.pingcap.com/zh/tidb/dev/optimizer-hints#agg_to_cop

可以参考楼上兄弟回复的演示，就像最后一张图的那样。 创建绑定的时候它会自动识别其中的常量，在 show bindings 的结果中可以看到显示成 ? 或者 ...，就算你实际的 SQL 中的常量是其它的值也是可以匹配上的。

假如需要绑定的 hint 是强制使用索引 idx_a，那么可以这样创建绑定： create binding for select * from t limit 1 using select * from t use index (idx_a) limit 1 创建的绑定会自动把 SQL 中的所有常量替换成 ? 或者 ... 这样的标识符，而不需要人工指定是哪些常量。

在之前的版本里，TiDB 支持了用 SQL 语义上的 outer 表来作为 build 端进行 hash join。 这个主要是为了优化小表 outer join 大表场景下的表现。 GitHub Issue: https://github.com/pingcap/tidb/issues/6868

是的，从执行计划上看不出来。 因为你只 select 了 name 这一列，所以这个 Projection 从一开始就只有 name 这一列。 但是下面的 Table Reader 的话，如果你不打开列裁剪的话，会把整张表的列都读上来，但是这个没在执行计划里面展示。 感兴趣的话，这个可以在 DoOptimize() 函数里面打断点看。

好的。

关于执行计划不稳定的问题，能提供更多信息吗，比如 SQL、选错的计划、预期的计划、统计信息？ 统计信息和计划选择方面在最近几个版本有不少优化，可能已经可以解决问题。

这个是个已经定位的 bug https://github.com/pingcap/tidb/issues/29503 目前 master 分支和 5.3 上的最新版本已经修复，其它分支预计会在下个版本修复。 触发这个 bug 的必要条件是 record-db-qps 被打开。 作为临时的绕过措施，可以在某一台 tidb 上关掉 record-db-qps 创建 binding。

TiDB 对关联子查询会自动使用 apply 算子，但是不支持这种语法。 我看你贴的 SQL 不是 MySQL 语法，MySQL 语法的话大概是这样： select case when 1 then (select value from b where a.col=b.col limit 1) else (select value from c where a.col=c.col limit 1) end from a; 先看看是不是想要的效果呢？

从 analyze version 2 开始是的。

目前的采样算法为了保证随机性，还无法避免一次 full table scan。 最近几次主要是对分布式采样并计算统计信息时的 CPU 和内存消耗的优化。

新采样方法在 analyze version 2 才可以使用。 Analyze version 2 禁用了 statistics feedback 和 fast analyze 这两个早期引入但是没有达到 GA 的功能。现在一般也不太建议使用这两个功能。

Analyze 和统计信息相关在最近几个版本分阶段都有一些优化。 5.3 上对采样方法有一些优化，通过使用 sample by rate 或者不指定可以用到新的采样方法，指定 sample number 的话还是旧的采样方法。 https://docs.pingcap.com/zh/tidb/dev/statistics#全量收集

tidb-server-status-port 默认是 10080 端口~ 这个端口可能被浏览器限制访问，如果被限制的话可以用 curl 等其它工具或者手动设置浏览器关闭限制。

多谢反馈。 文档的细节我们后面会增加相关说明；提供的统计信息我们也会尽快分析来定位问题根本原因。

那还方便提供一下统计信息吗？可以参考相关文档导出。

是的，可以参考 SPM 相关文档，SQL 是在标准化之后进行匹配的，像这样的可以提供参数列表的地方标准化的时候会有特殊处理，单个参数会被标准化成 ? ，而多个参数会被标准化成 ...，因此需要分别创建 binding 来覆盖所有情况。

可以考虑使用 window function 替代 SQL 比较复杂尝试理解了一下里面用户变量的用法，可以参考一下以下的方法来改写 @created_at 应该是用来计算每个 created_at 和上一行的 created_at 的差，这个的用法应该可以借助 LAG()，写成 created_at - lag(created_at) over () @concat_user 看起来是想拿来判断这一行是不是这个 concat_user 的第一行数据，这个应该可以借助 ROW_NUMBER()，写成类似 row_number() over (partition by date, disti…