如何在mysql命令行中查看高精度查询时间?

18

我正在进行一些优化工作,注意到在一些人们发布在文章和问题中的 mysql dumps 中(现在我实际查找时无法再次找到),存在高精度执行时间(0.05985215 秒而不是 0.06 秒)。

我如何在命令行上查看这些更精确的查询时间?

编辑

例如:

+----------+
| COUNT(*) |
+----------+
| 11596    |
+----------+
1 row in set (0.05894344 sec)

使用分析工具可以解决一部分问题,但是输出的内容太长了,而且我需要记住启用它。我只想要一个简单高精度的持续时间。

SET profiling = 1;
<query>
SHOW PROFILES;

给我一个像这样的东西:

+----------------------+-----------+
| Status               | Duration  |
+----------------------+-----------+
| (initialization)     | 0.000005  |
| checking permissions | 0.00001   |
| Opening tables       | 0.000499  |
| Table lock           | 0.000071  |
| preparing            | 0.000018  |
| Creating tmp table   | 0.00002   |
| executing            | 0.000006  |
| Copying to tmp table | 6.565327  |
| Sorting result       | 0.000431  |
| Sending data         | 0.006204  |
| query end            | 0.000007  |
| freeing items        | 0.000028  |
| closing tables       | 0.000015  |
| logging slow query   | 0.000005  |
+----------------------+-----------+
14 rows in set (0.00 sec)

您能否提供包含高精度执行时间(例如0.05985215秒而不是0.06秒)的文章和问题的链接?我找不到任何相关内容。最快的解决方法可能是直接询问那些发布这些文章和问题的人是如何实现的。 - ax.
1
真正的问题是服务器是否支持。分析将向您展示每个步骤所需的 CPU 时间,不包括同时运行的并发查询。因此,我们必须检查是否仍有一些未经过分析的getrusage - vbence
4个回答

17

看起来最佳的解决方案是启用分析。没有其他可行的线索。

最佳解决方案,使用查询分析。

SET profiling = 1;
<query>
SHOW PROFILES;

10

最好查看MySQL命令行客户端的源代码来回答这个问题。相关的代码段如下(点击此处)

static void nice_time(double sec,char *buff,bool part_second)
{
  // ...
  if (part_second)
    sprintf(buff,"%.2f sec",sec);
  else
    sprintf(buff,"%d sec",(int) sec);
}

这个程序在sec值中将小数点后的数字数量硬编码为(2)。这表明在标准mysql安装中不可能有更高精度的时间。

当然,你可以补丁这段代码,使其可配置等,然后从源代码进行安装。我猜这就是你提到的那些文章和问题中的人所做的。了解他们的最佳方法是直接问他们(请查看我对您问题的评论)。


@ax 显然我只知道足够解决第一部分。我已经成功增加了有效数字的数量,但我认为结果在被输入到这里之前在其他地方被截断了。 - Ben Dauphinee
@Ben Dauphinee,你问过使用“高精度时间”的人他们是如何做到的吗?这应该比我为你修补更容易 :) - ax.
@ax 我已经在MySQL论坛上发布了一个帖子,询问是否可以或如何完成这个操作。当我得到结果时,我会进行跨贴发布,并接受你的答案,因为它引导了这个方向。 - Ben Dauphinee
像phpMyAdmin这样的工具允许通过GUI添加自定义函数。您可以简单地fork它,在编辑器中添加它,然后从GUI的其他部分调用它。 - kaiser

0

但这只会告诉你调用返回所花费的时间。就像在程序中在查询之前和之后保存微秒一样。换句话说,如果慢查询在不同的线程上运行,它也会增加查询的运行时间。真正的解决方案必须基于“getrusage()”,仅计算在线程中花费的CPU时间(运行查询)。 - vbence

-1

不太优雅,但能正常工作的解决方案是打补丁到/usr/bin/mysql:

# copy the original mysql binary to your home dir
cp /usr/bin/mysql ~/mysql
# patch it
sed -i -e 's/%.2f sec/%.8f sec/1' ~/mysql 
# run it from the home directory
~/mysql 

它能够工作是因为MySQL二进制文件中目前只有一个格式化字符串'%.2f sec',但这可能会随着时间的推移而改变。 您可以通过应用反向补丁来恢复到原始二进制文件:

sed -i -e 's/%.8f sec/%.2f sec/1' ~/mysql

2
对我来说,这将打印出类似于“2 rows in set (0.00000000 sec)”的结果。但是SHOW PROFILES显示它大约需要1毫秒的时间。因此,我怀疑提供数据的源不具有足够高的分辨率,以使其真正有所帮助。 - Jesse Pangburn

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接