show processlist 中的 id 列值非常大的原因是什么？

[KaiNiao]

【 TiDB 使用环境】测试
【 TiDB 版本】6.5.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】show processlist 中的 id 列值非常大，是什么原因呢？
【资源配置】
【附件：截图/日志/监控】

MySQL [sbtest]> show processlist;
±--------------------±-----±----------------------±-------±--------±-----±-----------±-----------------+
| Id | User | Host | db | Command | Time | State | Info |
±--------------------±-----±----------------------±-------±--------±-----±-----------±-----------------+
| 1146067149119639773 | root | 192.168.141.127:59404 | sbtest | Sleep | 446 | autocommit | NULL |
| 1146067149119640025 | root | 192.168.141.127:59904 | sbtest | Query | 0 | autocommit | show processlist |
±--------------------±-----±----------------------±-------±--------±-----±-----------±-----------------+
2 rows in set (0.00 sec)

[我是咖啡哥]

我的环境V6.4的也是这样。
官方文档介绍： ID 列：客户连接 ID，从这看不是的。可能新版本改了。我v5.4的版本里面的id是比较小的。

[裤衩儿飞上天]

+1 蹲个答案

[dba-kit (张天师)]

其实是正常现象，TiDB的PROCESSLIST/CLUSTER_PROCESSLIST里的id值和MySQL不一样，不是递增的

[h5n1]

猜测是时间 机器ID啥的各种hash计算后的值

[我是咖啡哥]

是递增的。我测试了几个，\s看到的Connection id和processlist表中的id都是递增的。相减是个固定的值
只是不清楚在此基础上加的这个64位的数是哪里来的。
connection id --》 ID
1233 --》1393474857554937041
1235 --》1393474857554937043

[xingzhenxiang]

每增加一个连接+1，到了最大值后重新从1开始
我的v4.0.11很小

[KaiNiao]

Connection id和processlist表中的id是不同的字段对吧

[ffeenn (ThatBoy)]

这个好像与线程ID有关系

[xingzhenxiang]

新版本机制不一样了，我的v6.5.0也很大，这是个空库，按照以前不应该有这么大的

[我是咖啡哥]

对，应该是V6以后变了，5.4的都很小。

[tony5413]

哦，新版本就是这么设计的的呀，还没用V6。

[我是咖啡哥]

老版本这2个值是一样的，新版本不一致拉。

V6版本：

[h5n1]

[人如其名]

6.1添加了global kill，那么就需要connectionID全局唯一，为保证全局唯一由原来的本地自增变成了serverID和本地connectionID一起由类似于UUID生成算法的一些位运算机制生成了64位的连接号。

[KaiNiao]

好的，谢谢大佬

[KaiNiao]

专业！

[人如其名]

global connection id中的serverID 是随机函数生成的一个1-200多万的一个随机数，然后写入pd的ectd配置中，如果etcd中存在相同的serverID（也就是其他节点也是这个值），那么就重新生成。也就是serverID只是个随机数，和本地主机名之类的都没有关系。

[KaiNiao]

谢谢大佬！