OLTP和OLAP混用场景TiDB节点的参数设置

🪐 TiDB 技术问题
,
1

对于这种混用场景是否需要单独为不用类型的查询配置独立的TiDB节点分别调优相关的参数，有什么最佳实践方案？

2 个赞
2

参考这个看看

2 个赞
4

tiflash

1 个赞
5

tidb天生就适合这个场景

1 个赞
6

根据这个原则，平衡高并发短查询的低延迟需求 与 复杂分析查询的高吞吐需求

1 个赞
7

建议分节点部署。TiDB 节点适配 OLTP 低延迟，TiFlash 节点优化 OLAP 高吞吐，按查询类型分流调优。

1 个赞
8

TiFlash不支持高并发，如果是大表关联查有下推，联结过程说是在TiFlash进行Hash分组后关联，最终结果还是要返回TiDB层，这几个节点的内存配比应该是不同的。

1 个赞
9

如果装了tiflash，你可以通过环境变量控制用不用

1 个赞
10

我理解你这里说的tidb节点是指tidb server节点吧？我认为最好是在tidb server节点把不同类型的负载隔离开，OLAP负载会大量使用内存去进行数据聚合，肯定会和OLTP产生资源争用，造成性能和响应时间的波动，并且OLAP如果导致OOM的话还会影响在线交易的中断。建议不同类型的负载通过不同的负载均衡器走不同的tidb server，物理上进行隔离。

2 个赞
11

tidb应该会自己选择最优的

1 个赞
12

具体问题具体分析,所有参数配置都是跟着业务特点来的

2 个赞
13

请问现在解决了吗？ 在 OLTP 和 OLAP 混用场景下，TiDB 的参数设置核心是平衡高并发短查询的低延迟需求与复杂分析查询的高吞吐需求

1 个赞
14

是的，我也是这么认为。但是有些查询不是说会自动选择是否能路由到TiFlash，要想让开发控制可能还是挺麻烦的事。

1 个赞
15

自动选择会根据机器的负载情况进行判断吗？好像还不行吧

1 个赞
16

这个就需要开发对TiDB比较了解才能减轻运维的工作量了

2 个赞
17

是啊，通常系统最早设计与测试时，都是用同样的环境通过并发布的。你混用了，理论上可行，但运维的兄弟就辛苦了。

2 个赞
18

这种场景建议单独部署不同配置的 TiDB 节点来适配业务场景。比如 OLTP 侧重事务响应，需优化并发与锁处理；OLAP 侧重分析性能，需提升内存与向量化执行能力，混跑易互相干扰。最佳实践是用节点标签分流流量，做好资源隔离，并通过监控验证不同节点的负载与效果。

1 个赞
19
  • 资源隔离：通过参数隔离 OLTP/OLAP 对 CPU、内存、IO 的占用；
  • 优先级控制：让 OLTP 事务优先执行，避免 OLAP 大查询阻塞核心业务；
  • 避免资源耗尽：限制 OLAP 查询的内存和并发，防止 OOM 或集群过载；
  • 兼顾性能：OLTP 需低延迟（小事务、高并发），OLAP 需高吞吐（并行计算、大内存）。
1 个赞
20

全局并发与优先级参数

参数名 推荐值 作用 适用场景说明
tidb_server_handle_pool_size OLTP 占比高：CPU 核数 * 2；OLAP 占比高：CPU 核数 * 4 TiDB 处理 SQL 请求的线程池大小 控制 TiDB 节点的最大并发处理能力，避免线程过多导致上下文切换
tidb_low_priority_query_thread_ratio 0.3（30%） 低优先级线程池占比 预留 30% 线程给 OLAP 查询，70% 线程优先处理 OLTP 高优先级事务
tidb_priority_low_query_cpu_threshold 0.7（70%） 低优先级查询触发 CPU 阈值 当 TiDB CPU 使用率超过 70% 时，自动限制 OLAP 查询的 CPU 占用
tidb_enable_stmt_control ON 开启语句级资源控制 配合下面的 tidb_stmt_cpu_limit 限制单条 OLAP 查询的 CPU 耗时
tidb_stmt_cpu_limit 600（单位：秒・核）
2 个赞
21

tidb_stmt_cpu_limit 有什么作用呢?