我找了研发 connection_id 和show proxysession 的 id列值一样 这个正常
如果通过obproxy，业务拿到的connection id 就是这个cs_id，业务需要根据id终止请求：kill query / kill connection 都是 proxy 提供的这个cs_id， 这个id 就是32位唯一的整数。
官方文档：
“cs_id 为 ODP 内部标记的每个 Client 的 id 号，connection_id 为整个 OceanBase 数据库标记的每个 Client 的 id 号。connection_id 通过 SELECT CONNECTION_ID(); 语句获取。”
官网的文档解释：
ODP作为反向代理，业务看到的ODP就是一个整体OceanBase 数据库。 ODP分配的connection_id，就是数据库client id。
文档解释的应该是observer 节点会话id * ID：进程的 ID，即当前会话的 Client Session ID，该 ID 是会话在客户端中的唯一标识。
如果是 observer的会话id ,那么是不是 应该使用 gv$ob_processlist 查询到才对呢 ？？？您试下能查询到不，我这查询不到
你可以把你操作的截图发一下
对的，就是你这样操作的。
你看我就三个节点 ，都是2881端口。 能看到servr_sessid的是 2883端口 。 还都是 sys 租户
你看这次的截图
应该也是正常的 ODP 和 后端 server的每一个session 都会建立一个连接 建链后的那个session 连接 可能已经关闭了 所以测试的时候 测试不到 也属于正常
但是 为啥 不用 server_sessid 查询使用 cs_id 就能查询到呢 ？
设计的时候 应该都可以查 只是建链后的那个session 连接 可能已经关闭了 没有办法查了
这也是个原因 不过上面说的也是个原因
很详细
