你这是2个问题， 这个问题就如楼上所说。 假如你要控制连进tiproxy的ip只能访问一组特定的tidb节点，参考下面这个。 https://docs.pingcap.com/zh/tidb/stable/tiproxy-load-balance/#基于标签的负载均衡

支持插件，但不支持注册成函数。 tidb的插件模块是给审计用的。 https://github.com/pingcap/tidb/blob/942c686bfc5bda4bf031690d3c81201cb4835973/docs/design/2018-12-10-plugin-framework.md?plain=1 这是设计文档。你这个方式别研究了，死路一条。

明白了。 考虑下来我真觉得你应该考虑一下sm4的静态加密，另外这个sm4启用以后的性能回退问题要和老板商量一下的。 这个方案对你来说才是比较彻底的，当然也是改动会比较大的。 目前其他方案感觉都比较难以走下去。除非放弃sm4，用aes之类的代价会低很多。你也省事。

https://docs.pingcap.com/zh/tidb/stable/dm-ddl-compatible/#忽略的-ddl-语句 [image] 4里面的create function属于忽略的ddl。

这个文档的后续，我在另一个帖子看到了，确实走不下去的。 就是走下去了效率上，确实饶了大圈子，居然还用go调用http接口，去java/python里面转了一圈。这就是注册成功，也很慢的。 我记得tidb自己在sm4的文档里面说过，选这个静态加密方法，可能造成大比例的性能回退。 https://docs.pingcap.com/zh/tidb/stable/encryption-at-rest/#tikv SM4 加密只在 v6.3.0 及之后版本的 TiKV 上支持。v6.3.0 之前的 TiKV 仅支持 AES 加密。SM4 加密会对性能造成影响：最严重的情况下，会对吞吐造成 50…

go和c还不一样吧，如果c，多个连接可能需要多个线程，本身就比go提供的协程要重，消耗更多系统资源，io方式如果不是多路复用就更慢。 现在io基本都是多路复用，再加go协程，不活动的连接对资源消耗极少。同样的cpu资源，tidb能支持更多连接，如果连接不活动，消耗的资源也更少。销毁/建立一个协程的代价也更低。 在新技术的加成下，连接数的制约应该说是大大下降了。 你用sysbectch压一下确实有用，但是如果每个连接都跑满负载的话，得到的连接数肯定是远远小于你的硬件实际能支持的最大连接数的。 我个人是觉得连接数的制约，对于tidb来说已经不太重要了。不如关注其他的制约因素，例如从cpu，…

设置资源组不是立刻生效。需要重建连接。如果之前老的连接还连在上面，直接跑的话是限制不住的。

UDF不支持. 另外国密算法里面sm3/sm4的支持情况看下面这个链接。 https://docs.pingcap.com/zh/tidb/stable/release-6.3.0/#安全

这块代码是这样的。 里面的async-io指得是raftstore.store_io_pool_size这个设置大于0. 注释说测试数据显示这样会有更好的性能，并且如果发现你手动修改raftstore.store_io_pool_size，将无法动态设置raft-engine.batch-compression-threshold。 确实有点霸道，逻辑也确实有点乱，连续两个！=，其实就是raft-engine.batch-compression-threshold是默认值，那么一定会被设置为4k。

[image] [image] 这两个图就已经对不上了。03这台机器的pd启动时间一边显示是4.18，另一边显示是1.08。 如果os上显示没问题，那么问题出在采集上的可能性还是挺大的。 另外我发现，你使用了域名来访问每台机器，那么网络中某一时刻的域名对应的ip被污染了，也会采集到错误的机器数据。这也是一种可能性。

直接扩容就可以了。随用随扩。

liunx可还行，就算是个windows，win7和win11能一样么。

这个指标应该是和top命令里面看到的是一样的才对。 也不太可能有第二个来源，你的os是什么？

你这个密码时已经base64过一次的嘛？ 我尝试解码了一次，还原后的字符串末尾有些乱码。所以我怀疑你这密码并没有被base64加密过。 我比较认同 @hey-hoho 的看法，你这个密码可能确实容易出问题，=结尾可能会被看作是已经base64以后的密码，处理上可能会尝试使用base64解码以后的字符串作为密码，那个密码就是错误的。

https://docs.pingcap.com/zh/tidb/stable/sql-statement-prepare/#prepare 可以用prepare语句模拟一下这种带？的sql，看看是不是还是慢了。 prepare testsql from 'select DATE_FORMAT(?, '%Y') '; set @date1=‘2024-01-01’; execute testsql USING @date1; 类似这样

你这都8个节点了，还一点监控都不要啊。 你就是打算二次开发，也起码有个基础的监控看几天才知道那些要，那些不要吧。何必难为自己呢。

根因是 For a large table with multiple range queries, if the region count exceeds 128, the last range may be not limited. 问题在于扫描的region超过128就会报错。analyze后能正常，可能是有了比较准确的统计信息后，扫描的region个数小于128了。 当然重启能解决更好，不过我感觉恐怕于事无补。 另外这个issue，其实代码改动非常小。 [image] 改动一下pd代码里面对应文件的这个判断的位置就完成修复了。 如果着急，不如自己搞个8.5.…

几个要素都有，大表，超过128个region，count。

看上去是这个bug。描述非常接近。 好消息是这个bug修掉了，坏消息是这个bug2周前才修的，现在还没有最新可用的子版本包含这个修复。