一个是看执行最慢的，如果时间都显示0那可能不是某个sql导致的，看看哪一类sql最多，然后看执行计划是不是有问题，比如小表全表扫描这种执行不慢但是比较耗费资源的

直接去数据库里面show processlist看当前哪些sql最慢，大概率就是导致cpu高的慢sql

我们这边研发用的gitlab和svn

【大家的 TiDB 集群数有多少】 2 套 【所在的公司有用海光服务器吗？使用数量有多少？】 没有 【除了海光服务器，目前在用的服务器品牌有哪些？】 一套老的是华为的物理机，新的是浪潮的物理机，测试机都是vmvare

那只能做一下业务压测了，一般关注cpu，内存去考虑扩容就行，不用太关注连接数，毕竟这个连接数包括了活跃的和sleep的，并不能反映集群的压力情况

tidb默认不限制最大连接数，我这边都是不设置的，也可以根据集群负载来调整 https://docs.pingcap.com/zh/tidb/stable/manage-cluster-faq/#tidb-同时支持的最大并发连接数

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。

没太看明白，比如一台机器有一个内网地址192.168.0.1，有一个基础网络IP 10.0.0.1 ，那topology里都用192.168的内网地址来部署就行了，这样集群内部通讯使用独立的交换机性能更好，10的地址是用来人工登录服务器的，现在问题是什么呢

导出成csv，用 LOAD DATA导入

【PingCAP 10周年祝福语 】: 相约下一个十周年！ 【你对TiDB 印象最深刻的事情】: tiup和tiflash的上线

数据库一般没这种参数吧，毕竟重启对生产系统影响也挺大的，我感觉这种主要得查查是什么原因导致占用这么多内存，该优化SQL优化SQL，该扩容扩容，另外我看tidb和tikv是混部的，这种也容易相互影响

这个参数不会让tidb重启，只会终止最耗内存的sql，tidb节点重启一般都是操作系统OOM把tidb进程kill掉 https://docs.pingcap.com/zh/tidb/stable/configure-memory-usage/

16G确实太小了，官方建议的生产环境配置是64G，我们这边ticdc 平时内存也得用10G左右，高峰能到20G以上

8.0以后的版本才有的 [image] https://docs.pingcap.com/zh/tidb/v8.1/release-8.1.0/

看文档tidb-jdbc对性能上没什么特别的提升，至于性能瓶颈和优化分布式场景这里主要看tidb节点上层有没有负载均衡吧 [image]

是这个吧

都是私有云，公有云应该不会考虑，tidb用的物理机 【使用的 TiDB 版本】 6.1.6 【节点数量有多少】 tikv 32节点

我看开了多个帖子，直接这个帖子说吧，tiproxy里基于地理位置的负载均衡可以让亚洲的tiproxy连接亚洲的tidb，欧洲的tiproxy连接欧洲的tiproxy，如果想同时用两边的tiproxy并且两边同时要高可用，那你应该搞4个tiproxy，亚洲2个，欧洲两个，亚洲的应用连亚洲的tiproxy的虚IP，欧洲的应用连欧洲tiproxy的虚IP

虚ip不能和其他ip冲突，找公司网络或者基础设施的同事申请一个吧