Question

我正在完成一些优化工作，我注意到在一些mysql转储中人们发表文章和问题（现在我实际上找不到了），有高精度的执行时间（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)

Answer 1

似乎最好的答案是启用分析。没有其他的线索可以解决。

最佳答案，使用查询分析。

SET profiling = 1;
<query>
SHOW PROFILES;

Answer 2

通过查看source of the mysql command line client可以最好地回答这个问题。 relevant piece of code，

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安装可以实现更高的精度时间。

当然，您可以修补此代码，使其可配置等，以及install from source。我想这就是你提到的文章和问题中的人正在做的事情。你发现的最好机会就是问问他们（见我对你问题的评论）。

Answer 3

如果没有看到您正在谈论的转储，它可能是用户定义的函数？请参阅此主题（http://lists.mysql.com/internals/33707）了解一些问题以及如何操作。

Answer 4

不优雅，但工作解决方案是修补/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

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

4 个答案: