大家平时如何采集和分析TiDB的慢查询日志呢？
通过 information_schema.slow_query/cluster_slow_query，或者 dashboard，都可以很容易查到慢查询日志
但里面的 SQL 语句不是原始的SQL语句，非常难难辨识。
如果SQL中没有包含注释，则通过dashboard中的格式化，能得到一个容易阅读的SQL语句
如果SQL中包含注释，则无法格式化出一个较为容易阅读的SQL
有什么办法能够捕获到原始的SQL语句么？
1 个赞
什么叫原始SQL，这里面的sql不就是原sql吗？ 慢查询里面都是原sql，SQL语句分析里面是做了过滤分组的，他要统计次数，sql语句一样的谓词不一样的分为一组，。
如果你觉得这个监控里面的sql不是原sql那就把 他的大概语句 发给开发。让开发去代码里面找他的sql语句，
根据执行计划推断，另外一般注释的都是中文 
举全例子，执行的SQL（原始SQL）：
SELECT
sleep(3) as time, # sleep
1 as id, # id
2 as name # name
from information_schema.tables
limit 1 # got top 1
通过慢查询查询出来的 SQL 语句显示为：
SELECT sleep(3) as time, # sleep 1 as id, # id 2 as name # name from information_schema.tables limit 1 # got top 1;
格式化之后的结果：
SELECT
sleep(3) AS time,
sleep 1 as id, # id 2 as name # name from information_schema.tables limit 1 # got top 1;
出来的都不是能执行的SQL语句了，这还是短的SQL语句，如果是表多，字段多的，中间有点注释的，这样的SQL语句如何看呢？
我没遇到你这个情况，我都是 慢sql里面直接复制出来。直接执行没问题。
SQL分析里面的，都是格式化 分组之后的， 复制出来。把谓词地方的? 改成双引号，里面放一些数据，然他能执行 执行计划。。
你这个是因为 加了 #sleep 这个东西格式化之后，不能执行了吗？？
你复制原始 sql试试呢，别复制格式化的sql。
慢查询中的原始sql，是实际执行的SQL，去掉换行后的结果，我举例中写了
嗯，慢查询里面确实格式是有问题。
格式化语句和原始语句
诶，general log 记录也有相同的问题。不知道大家有没有什么解决方案?
我试图通过 TIDB_DECODE_SQL_DIGESTS，或关联 STATEMENTS_SUMMARY、STATEMENTS_SUMMARY_HISTORY 取得 SQL 语句的归一化形式，我发现能够匹配的数据很少
井号不行，杠-杠-也不行
使用 ```
/* this is an in-line comment */
mysql> SELECT 1+1; # This comment continues to the end of line
mysql> SELECT 1+1; -- This comment continues to the end of line
mysql> SELECT 1 /* this is an in-line comment */ + 1;
mysql> SELECT 1+
/*
this is a
multiple-line comment
*/
1;
MySQL Server supports certain variants of C-style comments. These enable you to write code that includes MySQL extensions, but is still portable, by using comments of the following form:
/*! MySQL-specific code */
In this case, MySQL Server parses and 这里 executes 这里 the code within the comment as it would any other SQL statement, but other SQL servers should ignore the extensions. For example, MySQL Server recognizes the STRAIGHT_JOIN keyword in the following statement, but other servers should not:
没办法去约束程序的注释方式，这个影响面太大了
Digest的方案我在我的环境中验证过了，仅有一小部分能关联上
TiDB 支持将慢查询记录到文件中。你可以通过修改配置文件或运行时参数来启用慢查询日志并将其写入文件。这通常比从 information_schema 查询要有效得多。
- 配置示例：
yamlCopy Code
[log]
slow-query-log = true
slow-query-log-file = "/var/log/tidb_slow_query.log" # 指定日志文件路径
long-query-time = 1 # 设置慢查询阈值（单位：秒）
log-slow-query = true # 是否记录慢查询
1 个赞
其他的注释方式，已经被删除了，根本记录不下来