作者： TUG 微尘原文来源：https://tidb.net/blog/8695e0f4

TiDB-v4.0.x 支持 OLAP 场景的一些实践经验

由于个人工作经验的局限性，本文将仅分享我个人最近两个月在 TiDB 支持 OLAP 场景 (BI 系统) 遇到的一些问题及调优方法。不足之处请大家批评、补充。

这类业务场景有一下特点:

• 数据量大，主要为 batch insert 和 select 业务

• 很多类似 select * 操作
  

• 较多 join 操作

• 每天定时做 drop partition
  

• …

Case1: tidb 节点系统盘使用量超过 80% 报警

现象： tidb 节点 系统盘 使用量超过 80% 报警

原因：

https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#tmp-storage-path

https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#mem-quota-query

调优方案:

调整 tmp-storage-path 或者 tmp-storage-quota

Case2: 单条 SQL 超过内存使用限制被 cancel

原因：

https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#mem-quota-query

调优方案：

调大 mem-quota-query

Case3: 海量 empty-region

现象：监控 PD->RegionHealth->empty-region-count 较大

原因：频繁 drop-partition 造成

调优方案：(这里注意: 升级到 4.0.x 的集群 region-merge 默认未打开)

https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices#region-merge- 速度慢

https://docs.pingcap.com/zh/tidb/stable/massive-regions-best-practices# 方法五开启 -region-merge

Case4: TiKV-CPU & TiKV-ThreadCPU->RaftStoreCPU 居高不下

现象: TiKV-CPU & TiKV-ThreadCPU->RaftStoreCPU 居高不下

原因: region-count 过大，集群负载高

调优方案：

https://docs.pingcap.com/zh/tidb/stable/massive-regions-best-practices# 海量 -region- 集群调优最佳实践

Case5: Transection too large

现象： insert into select from 、 delete from 等操作报错 Transection too large

原因：

调优方案：

1. 针对事务过大，可以考虑拆分事务

2. https://book.tidb.io/session4/chapter6/transaction-statement-count-limit.html#465- 如何绕开大事务的限制
   

3. https://book.tidb.io/session1/chapter6/big-txn-in-4.0.html#63-40- 的大事务支持