共计 2718 个字符，预计需要花费 7 分钟才能阅读完成。
作者：姚嵩
外星人 …
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
背景：
通过 obproxy 连贯 OB 后，发现：
kill 命令使⽤ show processlist 中的 ID 能执⾏胜利，
使⽤ information_schema.processlist
或者 oceanbase.__all_virtual_processlist 中的 ID 进⾏ kill 是失败的。
于是就进⾏了各种连贯测试，解惑两个问题：
- kill 中 session_id 的起源；
- 是否能够⼀次性⼲掉⼀个租户的所有连贯；
测试阐明：
阐明：
session_id 是 kill 语句的参数，session_id 和下⽂中的 ID 是同⼀对象；
视图 information_schema.processlist 的数据来源于表 oceanbase.__all_virtual_processlist。
登陆命令阐明(以本⼈测试的环境为例)：
登陆 observer：
mysql -uroot@sys -p -P2881 -h ${oberver_ip} -c -A oceanbase
登陆 obproxy：
mysql -uroot@sys#yjn_test -p -P2883 -h ${obproxy_ip} -c -A oceanbase
测试案例
登陆某个 observer 的节点：
⽬标：
确认 observer 上
show processlist
表 information_schema.processlist
表 oceanbase.__all_virtual_processlist
获取的 ID 是否雷同？
执⾏语句：
show processlist ;
select * from information_schema.processlist ;
select id,user,host,db,command,time,state,info from oceanbase.__all_virtual_processlist ;后果：
3 个语句取得的 ID 是雷同的，能够通过上⾯ 3 种⽅式获取 session_id；
登陆某个 obproxy 节点：
⽬标：
确认 obproxy 上
show processlist
表 information_schema.processlist
表 oceanbase.__all_virtual_processlist
获取的 ID 是否雷同？
执⾏语句：
show processlist ;
select * from information_schema.processlist ;
select id,user,host,db,command,time,state,info from oceanbase.__all_virtual_processlist ;后果：
information_schema.processlist 和 oceanbase.__all_virtual_processlist 中的 ID ⼀致；
show processlist 中的记录和上⾯ 2 表的 ID 不⼀致，执⾏ kill 语句的时候，采⽤的是 show processlist 中的 ID。
通过 observer 和通过 obproxy 登陆看到的 oceanbase.__all_virtual_processlist 的数据是⼀致的；
登陆集群内不同 observer 的节点：
⽬标：
确认⽤户登陆⼀个 observer 是否能看到登陆其余 observer 的 session 信息？
通过不同 observer 登陆查看 session 信息(super 权限⽤户登陆)：
后果：
在⼀个 observer 上能够看到其余 observer 的登陆信息；
登陆不同的 obproxy(他们连贯雷同的 OB)：
⽬标：
确认⽤户登陆⼀个 obproxy 是否能看到登陆其余 obproxy 的 session 信息？
执⾏语句：
show processlist ;通过不同 obproxy 登陆查看 session 信息：
后果：
在⼀个 obproxy 上通过 show processlist 语句不能看到其余 obproxy 的 session 信息；
测试总结：
1. 视图 information_schema.processlist 的数据来源于 表 oceanbase.__all_virtual_processlist；
命令 “show create table information_schema.processlist \G” 能够确认。
2. 表 oceanbase.__all_virtual_processlist 中记录的是所有到 OB 的连贯信息；
客户可能直连 observer，也可能是通过 obproxy 连贯 OB，所有连贯信息都会记录到表中；
3.show processlist 查看的是客户端连贯到软件的信息，所以当通过 obproxy 连贯 OB 时，show processlist 展现的是连贯到 obproxy 的信息，⽽不是连贯到 OB 的信息；
当直连 obsever 时，show processlist 展现的是连贯 OB 的信息；
4.obproxy 相当于 observer 的客户端，所以连贯不同的 obproxy，执⾏ show processlist 看到的连贯信息是不同的，它们是互相独⽴的；
释疑：
问题 1：
kill 中 session_id 的起源？
答案 1：
OB 中的 kill 命令是为了⼲掉⼀个 session 或者⼲掉这个 session 对应的 SQL 语句。
为了这个⽬的，能够⼲掉前侧连贯(指来源于客户端的连贯)，或者⼲掉后侧连贯(连贯到后侧的连贯)。
通过 show processlist 查看前侧连贯，即查看客户端到软件 (例如: obproxy) 的连贯 ID；
也能够直连 observer，通过 oceanbase.__all_virtual_processlist 查看后侧连贯。
在执⾏ kill 命令时，能够通过任意⽅式连贯 OB，并通过 show processlist 获取连贯 ID；
也能够通过直连后侧的 observer，通过 oceanbase.__all_virtual_processlist 表获取连贯 ID；
问题 2：
是否能够⼀次性⼲掉⼀个租户的所有连贯；
答案 2:
因为前侧连贯通过 show processlist 只能查看以后客户端到软件的连贯信息，查不到其余前侧的连贯信息。例如：客户通过多个 obproxy 连贯 OB，如果咱们连贯其中⼀个 obproxy 执⾏ show processlist 获取的连贯是不全的。
咱们能够直连 observer，并执⾏以下 SQL，失去⼲掉租户 tenant_ys 的所有连贯的命令：
select concat('kill',id,';') from oceanbase.__all_virtual_processlist where tenant='tenant_ys' ;