通过分析发现sql有现瓶颈在有并发的算子上，想调整并发提升速度，tidb_executor_concurrency该怎么调合适

[Jolyne]

【 TiDB 使用环境】生产环境 /测试/ Poc
测试
【 TiDB 版本】
5.4.1
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
tidb_executor_concurrency 这个值的如何调到合适的值。
【资源配置】
【附件：截图/日志/监控】

[我是咖啡哥]

调大这个，内存够大不？

tidb_executor_concurrency 从 v5.0 版本开始引入

• 作用域：SESSION | GLOBAL
• 是否持久化到集群：是
• 默认值：5
• 范围：[1, 256]

变量用来统一设置各个 SQL 算子的并发度，包括：

• index lookup
• index lookup join
• hash join
• hash aggregation（partial 和 final 阶段）
• window
• projection

OOM解决方案里面都是建议设置为1
tidb_executor_concurrency = 1 来触发 HashAgg 落盘功能。
https://docs.pingcap.com/zh/tidb/stable/configure-memory-usage#数据落盘

[Jolyne]

我理解这里的值如果大于1是表示可以执行多个算子，等于1的话只有一个算子执行，数据量大的话会落盘来减轻压力，但是会消耗大量内存。有一点不明白的是，这样是不是大多数情况下都比多并发来的快？

[tidb菜鸟一只 (小菜一颗)]

我觉得应该类似于oracle开并行吧，消耗的应该是CPU和内存，因为原来是一个一个算子单独执行，并顺序把数据拉入内存，现在改成并行，太容易给服务器造成过大的压力。

[我是咖啡哥]

tidb_executor_concurrency = 1 来触发 HashAgg 落盘功能。
落盘减少OOM了，不会消耗大量内存。但是慢了呀，磁盘肯定比内存慢啊。