【 TiDB 使用环境】
tidb v5.4.0
【概述】 场景 + 问题概述
有一个sql查询，多个表关联查询的，比较慢，直接用kill tidb query 645;杀进程，但是执行完之后事务一直处于in transaction状态，执行几次都是这样，是不是变成僵尸进程了呢？有什么办法可以去除吗？
【背景】 做过哪些操作
【现象】 业务和数据库现象
【问题】 当前遇到的问题
【业务影响】
【TiDB 版本】
【应用软件及版本】
【附件】 相关日志及配置信息
监控（https://metricstool.pingcap.com/)
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
请问是在对应的host来kill的么，就是查询在哪个tidb，就需要在哪个tidb执行kill tidb
能来问不会犯这种错误，哈哈
这个问题我最近做过测试，在tidb5.3.2中，这种sql(大概率多表联合，且是limit m, n这种，m很大），每次查询后，在后台挂一个时间不断递增的僵尸session,且不能被kill ；在tidb5.4.2中,僵尸session还是会有，但是可以被kill；在tidb6.1.1中，实测僵尸session不会出现。
我5.4的版本也遇到这种情况，kill tidb id(事务ID) ，kill tidb session_id，并且在对应tidb的host去操作也是kill不掉，难道要升级到6.1 ？
看以前的贴子都是重启tidb server
我们生产版本是5.3.2，目前再考虑这个事情怎么做，是否要升级。临时解决方案是将相关sql中的index hash join强制hint为index join可以绕过这个bug,实测有效。
重启确实可以杀死僵尸session,但是不能一直重启
indexHashJoin hang in handleTask · Issue #35638 · pingcap/tidb (github.com)和这个issue类似，可以产靠下，但是这个已经在5.4中被修复了，不能复现了，
实际上已经kill了，只是还显示在这里，要想清掉就重启tidb-server，不是很影响。具体的判断是否kill了，就观察tidb日志，只要tidb日志中有kill的字样，就说明已经发起了kill。
好的，我看看
是的，我刚才重新执行kill tidb 645;就好了
这个问题低版本每次需要重启，要么升级一下吧
嗯，我也很想升级，架构师不同意
他们能接受这个bug，那就这样了。
我们有时候要升版本，也会遇到各种阻力。
问题原因，解决办法做个报告发给他们，决策权给他们就可以了。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。
