从监控、dmesg 和 log 中大的查询来看，可以优化下 tidb log 中 expensive_query 可以优化一下
感谢回复，这个要是优化不动了呢，有啥好解决方法吗
避免 tidb oom，或者是在内存使用限制可以看下tidb的配置文件参数部分关于以下参数的描述；
https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file
ssd 或者nvme 做swap 靠谱吗？
1、改sql，开发说一台MySQL都能扛得住，表示没有可优化的空间了
2、取消就影响业务了，这个没人能同意
https://book.tidb.io/session4/chapter7/tidb-oom.html#74-tidb-oom-的常见原因
可以，但是需要根据 sql 的执行情况而定；
能详细一点吗，注意啥
意思是如果你的 sql 占用内存超出了 swap 的限制还是会被 oom。
PS：3.1 版本的 tidb 集群我们建议升级到 4.x 最新版本哈，功能上是完全覆盖的。对于你的问题也可以使用
这个参数作为兜底方案
这个参数我看了，是不是超出这个路径所在的空间也是oom，还是查询会排队？
这个空间是可以设置的超出按照 oom 计算。
我swap设置3.5T和tmp-storage空间设置3.5T，哪个性能更佳，为啥？
这个没有时间对比过，但是理论上都是用的磁盘缓存结果，应该差不多，3.5T 有点过了，，，还是合理设置吧，可以在测试环境跑一下。
主要我不知道取数据原理，复杂查询是不是要把所有数据拿到本地，然后再做数据合并，我们数据量有点大，所以才选用tidb的，原理文章，请指条明路，我学习一下
建议使用 tmp-storage 关闭 swap 。
- swap 是 os 层面的控制，当物理内存不足时，拿出部分硬盘空间当SWAP分区（虚拟成内存）使用。
- tmp-storage 是 TiDB 针对查询进行优化，在某些算子超过了内存限制的时候，触发落盘的操作。
目前是v3.10，需要升级操作啊
tmp-storage设置，多个线程触发大内存操作时，会不会因为申请不到内存，也没触发落盘，造成oom
如果在 v4.0 版本，使用 tmp-storage 相关配置项，出现 sql 未落盘，tidb 持续 oom 的情况，那么建议将 tmp-storage 的相关配置信息，以及 TiDB 的 log 文件，操作系统的 message 信息提供下，这里再分析下~~~