ShardingSphere的GROUP BY下推失败需检查：①user_id是否为分片键；②开启sql-show日志确认下发SQL是否含GROUP BY和SUM()；③避免混用非分组字段、子查询等导致退化为内存归并。
ShardingSphere 的 GROUP BY 下推失败怎么查
直接在分库分表环境里写 SELECT user_id, SUM(money) FROM t_order GROUP BY user_id，大概率返回错误结果或全量拉取归并——不是 SQL 写错了，而是中间件没把聚合下推到各分片执行。
关键检查点：
- 确认
sharding-algorithm配置中，user_id真是分片键；如果不是，路由失效，中间件只能广播查询 - 打开
props.sql-show=true，看日志里下发到每个分库的 SQL 是不是带GROUP BY和SUM()；如果只看到SELECT *，说明下推被禁用或不满足条件 - 避免在
SELECT列表里混用非分组字段，比如SELECT user_id, SUM(money), order_no—— 这会强制走内存归并 - 子查询、
UNION、窗口函数、非分片键上的ORDER BY都会导致退化，别指望它还能下推
ClickHouse 通过 mysql 表引擎聚合 MySQL 分表数据时连接打满怎么办
用 ClickHouse 的 ENGINE = MySQL(...) 建表连多个 MySQL 分库，一并发查起来，MySQL 很快报 Too many connections —— 因为每个 ClickHouse 表实例默认独占一个连接，N 个分库 × M 个并发 = N×M 个连接。
必须手动限流：
- 在 ClickHouse 的
config.xml中配<mysql_max_connections>8</mysql_max_connections>，限制单个 MySQL 实例最大连接数 -
CREATE TABLE时显式写全连接参数：ENGINE = MySQL('host1:3306', 'db', 't_order_00', 'user', 'pwd')，不要依赖全局用户配置 - 聚合前务必加
WHERE dt >= '2026-04-01'这类条件，让过滤下推；否则 ClickHouse 会把所有分表全量拉过来再算，网络和内存双爆炸
Hive/ClickHouse 里 COUNT(DISTINCT uid) 不准，是不是 bug
不是 bug，是设计如此。Hive 默认用 ndv()（HyperLogLog），ClickHouse 用 uniq()，两者都是概率算法，误差率稳定在 1%～2%，数据量越大，相对误差越小，但绝对值不准。
要精确值，只有两条路：
- 改用
COUNT(DISTINCT uid) WITH UR（Hive 3.0+）或countDistinctMerge+ 预聚合（ClickHouse），但性能下降明显 - 绕开近似算法：ETL 阶段先按
uid去重，再汇总，或者用GROUP BY uid后计数，代价是临时存储翻倍 - 别在实时链路里强求精确——很多业务场景下，1% 误差可接受，硬上精确算法反而拖垮 SLA
LEFT JOIN 后做聚合，COUNT(*) 和 COUNT(字段) 结果为什么差很多
因为 COUNT(*) 统计的是连接后的行数，哪怕右表字段全是 NULL 也算；而 COUNT(orders.id) 只统计非 NULL 的值，LEFT JOIN 没匹配时 orders.id 就是 NULL，自然不计入。
典型误用：
- 想查“每个用户的订单数”，写了
SELECT u.name, COUNT(*) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.name→ 把没下单的用户也当“有 1 单”算 - 正确写法是
COUNT(o.id)或COALESCE(COUNT(o.id), 0) - 另外注意
WHERE和ON的位置：把o.status = 'paid'放WHERE会把没订单的用户全过滤掉，LEFT JOIN 彻底退化成 INNER JOIN
