这条SQL在clickhouse上执行，会报内存超限，如果在tidb上跑的话，性能如何？

🪐 TiDB 技术问题
1

SELECT
sum(toDecimal64(a.inBytesTotal, 2)) AS inBytesTotal
FROM
biz_monitor_trace_detail a
RIGHT JOIN biz_monitor_trace b ON
a.traceId = b.id
AND b.alarmId = ‘2023022419154300120001’
AND b.dstIp = ‘223.99.7.182’
AND b.sourceType = ‘1’
AND b.ondemand = ‘1’
where
a.type = ‘Total’

2个表（trace和trace_detail）都是36亿左右。

2

这么大的为表没有试过。看数据库的配置和库表的优化情况吧

3

b表上符合这几个条件的数据量有多大？count一下看看。如果选择性很差，符合条件的数据很多。那神仙难救。

另外要注意tiflash对数值溢出没有检查

https://docs.pingcap.com/zh/tidb/stable/tiflash-compatibility/#tiflash-兼容性说明

  • 不支持检查溢出的数值。例如将两个 BIGINT 类型的最大值相加 9223372036854775807 + 9223372036854775807，该计算在 TiDB 中预期的行为是返回错误 ERROR 1690 (22003): BIGINT value is out of range，但如果该计算在 TiFlash 中进行，则会得到溢出的结果 -2 且无报错。

sum(toDecimal64(a.inBytesTotal, 2)) AS inBytesTotal

如果用tiflash+mpp的方案走（理论上是tidb体系下对你这个sql的最好方案），这个地方可能存在溢出的风险，你需要注意。

4

实践一下才知道吧

5

b表按条件查出来，大概100多万吧

6

:joy:这种建表真让人头大~ 如果建表规范一点就省去很多后期资源浪费

7

没办法，ck都扛不住。

8

如果使用tiflash的话，请问tiflash主机的内存需要多大才行？

9

100w行，我感觉这个条件选择性还可以，没想通为啥内存会炸。多大的内存？

tiflash整体内存不好估计，但是100w行左右join再sum，正常来说应该是吃不了多少内存的。

10

如果这个B表数据很大，过滤结果很少，把他单独插入到一个临时表C，然后，用这个C表的结果再去和a表关联
biz_monitor_trace b
AND b.alarmId = ‘2023022419154300120001’
AND b.dstIp = ‘223.99.7.182’
AND b.sourceType = ‘1’
AND b.ondemand = ‘1’

11

具体怎么操作呢？

12

你可以试试，我也不确定效率会不会提升：
insert into table_c as select * from biz_monitor_trace b
where b.alarmId = ‘2023022419154300120001’
AND b.dstIp = ‘223.99.7.182’
AND b.sourceType = ‘1’
AND b.ondemand = ‘1’
create index idx_001 on table_c(id);

a.traceId = b.id 这个b表id对应的a表的traceid是一对多还是一对一。如果1对一，那估计比较快。如果一对多，或者A表全表都是那可能不会很快
traceId 有索引吗？没有就搞一个
然后
SELECT
sum(toDecimal64(a.inBytesTotal, 2)) AS inBytesTotal
FROM
biz_monitor_trace_detail a
RIGHT JOIN table_c b ON
a.traceId = b.id
where
a.type = ‘Total’