tikv内22亿的表（分区表）加入到tiflash中会有风险么？

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
生产环境
【 TiDB 版本】
v4.0.8
【复现路径】做过哪些操作出现的问题

【遇到的问题：问题现象及影响】
当前有一个单表22亿，需要做聚合查询，在tikv内执行需要10s,不满足性能要求
考虑把表加入到tilflash中，不知道有没有什么风险？

SELECT
sum( xx ) AS xxx
FROM
t_xxx t
WHERE
app_xxx IN (
‘aaa’,
‘bbb’,
‘ccc’,
‘dddd’,省略几百个)
AND report_time BETWEEN ‘2023-09-04 00:00:00’
AND ‘2023-09-04 23:59:59’;

report_time 有一个单列索引

执行计划如下：
±-----------------------------±-----------±----------±-----------------------------±-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| StreamAgg_30 | 1.00 | root | | funcs:sum(Column#134)->Column#125 |
| └─TableReader_31 | 1.00 | root | | data:StreamAgg_10 |
| └─StreamAgg_10 | 1.00 | cop[tikv] | | funcs:sum(dbname.t_xxx.xxx)->Column#134 |
| └─Selection_29 | 1228580.34 | cop[tikv] | | ge(dbname.t_xxx.report_time, 2023-09-04 00:00:00.000000), in(dbname.t_xxx.app_package, “aaa”, “bbb”, “ccc”, “ggg”, “ddd”, “eee”, “fff”), le(dbname.t_xxx.report_time, 2023-09-04 23:59:59.000000) |
| └─TableFullScan_28 | 6198910.00 | cop[tikv] | table:t, partition:p20230904 | keep order:false |
±-----------------------------±-----------±----------±-----------------------------±-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

2

tiflash看上去适合你这个sql的查询。

然而，看上去你这个sql还有优化的空间啊。
执行计划直接一个TableFullScan ,是表太大了，索引也不好加了？

3

22亿的表（分区表），目前是有一个report_time索引，根据report_time做的分区，看执行计划是做了分区的裁剪，确实是全分区扫描，一个分区差不多600w，即使加上report_time，app_xxx 联合索引，看起来效果也不会特别好，in这个查询会有索引的跳跃扫描

4

时间区间会不仅限于1天的时间吗？如果区间都比较小的话，report_time字段先建个索引试试
如果时间可能会有一个月之类的长时间区间的话，确实用tiflash要比较好

5

时间范围基本锁定在一天，表按天分区的，单天数据有600w+，满足过滤条件的大约130w，感觉要建一个三个字段的联合索引才有效

1 个赞
6

4.0.8的版本有点低，加tiflash不知道会有什么坑 ，其他表之前做tiflash吗 。

7

之前有加过tiflash的表，当时初始化时候数据量小，才500w，逐步同步到现在最大的表也有5亿了；主要担心22亿的表，加tiflash会对tikv造成很大的影响，另外也没说这中间是如何同步的？

8

博客有相关文章，tiflash就是tikv的 leaner角色副本，就怕一下这么大的数据tiflash压力大

9

看执行计划应该扫描的是整个分区表，按日分区的话这样应该是最优了，放tiflash里面是否有必要，如果加联合索引的话对整个数据表应该会更大，可以的话是否按日进行分表是否会更好

10

我自己有个7亿数据的月分区表，单天大概是1000w左右的记录数量。
我尝试使用联合索引做你这个查询，可以做到0.3s内返回结果。
你也可以尝试一下这样是否能解决。

11

你这表是按天分区的，那索引意义不大，配置tiflash副本效果应该还可以，对于tikv没什么风险，tiflash可能压力会大一点，不影响。

12

加tiflash副本没有风险，不过要注意，最好不要将TiFlash和TiKV节点部署到一起。

13

试试where条件的联合索引

14

如果能利用好MPP并行计算优势 应该会有比较大帮助 但Tidb从V5.0版本才引入MPP架构
联合索引 最左匹配原则可以试一试 索引最佳实践中也有提示* 查询条件使用 IN 表达式时，后面匹配的条件数量建议不要超过 300 个，否则执行效率会较差。 索引的最佳实践 | PingCAP 文档中心