dashboard记录的慢查询不是原始SQL问题

[xxxxxxxx (Hacker Z Vu Xy Nh8)]

tidb版本 6.1.7

最近发现在dashboard平台上记录的一些update慢查询，有些带where，有些不带where，然后去看了一下表的记录数，都是上亿的表了，于是就赶紧联系业务，跟业务再三确认，业务对该表的update语句肯定都是带where条件的，所以现在的现象就是dashboard记录的SQL不像是原始SQL，像是被改过，需要官方确认给答疑一下。

业务表的记录如下

dashboard记录的如下

这里还有个问题，即便是不带where是原始update语句，那么超过一亿行记录的表全表更新1.2秒就执行完了，这明显也是不正常的。

dashboard记录的update语句有些又带where条件，如下，现在搞的很疑惑

慢日志记录的情况，对这个表的更新总共记录了3961次，有where条件的是2265次，没有where条件的1696次

[WalterWj (王军 - PingCAP)]

难道 dashboard 显示问题？你要不要去慢日志文件中 grep 试试能否找到异常记录。

[Kongdom]

@xxxxxxxx

这里还有个问题，即便是不带where是原始update语句，那么超过一亿行记录的表全表更新1.2秒就执行完了，这明显也是不正常的。

看执行计划是point_get，应该是带where条件，是不是因为语句太长截断了？语句超长时，dashboard只显示部分内容，但执行还是执行全部的。

[xxxxxxxx (Hacker Z Vu Xy Nh8)]

刚才去慢日志查看发现也是没有where条件

[Kongdom]

嗯，长度应该只展示29363，这么长。

SQL 语句展示不全

在数据库中查询到的sql最后也是(len:29363);结尾，而不是全部的sql语句

[xxxxxxxx (Hacker Z Vu Xy Nh8)]

从现象看，记录的是一条完整的记录，不是截断那种，尾部有分号

[WalterWj (王军 - PingCAP)]

感觉是记录上的 bug。

执行计划中的表能和 sql 对的上对吧。

[Kongdom]

可以从数据库里information_schema.cluster_slow_query查一下看看。dashboard也是从这里取得。

[Kongdom]

@xxxxxxxx

这里还有个问题，即便是不带where是原始update语句，那么超过一亿行记录的表全表更新1.2秒就执行完了，这明显也是不正常的。

这个尾部有分号么？应该不会吧，全表update的执行计划里，不会是point_get，这个代表了主键命中。

[tidb菜鸟一只 (小菜一颗)]

按你页面显示的sql模板id去表里查下SELECT * FROM INFORMATION_SCHEMA.STATEMENTS_SUMMARY_HISTORY b WHERE b.DIGEST=‘b823d47ec2c34e7981f6c1823e44177b0ae108fc14cc10dc92b0e0264d3e4d3b’

[小龙虾爱大龙虾 (Minghao Ren)]

我只知道 TiDB 有个这个问题，就是记录带注释的 SQL 的时候会记录有点问题，一般也不影响用，像这样

不知道你是不是这样的问题，你的图基本啥也看不到了，执行计划看着都是对的，你检查下看看吧

[YuchongXU]

bug了，给截断了

[Kongdom]

应该不算bug吧，正常操作。对于超长内容，只是显示的时候显示部分内容，执行的时候还是全部执行。全部显示没太大必要。