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

发布于 2024-11-09 10:37:57 字数 1149 浏览 0 评论 0原文

我正在进行一些优化工作,并且我注意到在一些人们在文章和问题中发布的 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)

I'm working through some optimization work, and I've noticed that in some mysql dumps people post in articles and questions (which I cannot find again now that I'm actually looking), there are high-precision execution times (0.05985215 sec instead of 0.06 sec).

How can I see these more precise times for my queries on the command line?

EDIT

Example of this is:

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

Using profiling gets me part of the way there, but produces an output too long, and I have to remember to enable it. I am just looking for a simple high-precision duration.

SET profiling = 1;
<query>
SHOW PROFILES;

Gives me something like this:

+----------------------+-----------+
| 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)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

北风几吹夏 2024-11-16 10:37:57

似乎对此问题的最佳答案是启用分析。没有其他线索成功。

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

SET profiling = 1;
<query>
SHOW PROFILES;

It seems that the best answer to this is to enable profiling. There have been no other leads that pan out.

Best answer, use query profiling.

SET profiling = 1;
<query>
SHOW PROFILES;
成熟稳重的好男人 2024-11-16 10:37:57

这个问题最好通过查看 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);
}

硬编码为 (2) 的 sec 值小数点后的位数。这将使我得出结论,使用库存 mysql 安装不可能更高精度的时间。

当然,您可以修补此代码,使其可配置等,然后从源安装< /a>.我想这就是你提到的文章和问题中的人正在做的事情。你最好的机会就是直接问他们(请参阅我对你的问题的评论)。

this question is best answered by looking at the source of the mysql command line client. the 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);
}

has the number of digits after the decimal point for the sec value hard-coded into (2). this would make me conclude that higher precision times are not possible with a stock mysql install.

of course, you could patch this code, make it configurable, etc, and install from source. i guess this is what the people in the articles and questions you mentioned are doing. your best chance to find out is to just ask them (see my comment to your question).

半步萧音过轻尘 2024-11-16 10:37:57

如果没有看到您所说的转储,它可能是用户定义的函数?请参阅此线程(http://lists.mysql.com/internals/33707)陷阱以及如何做到这一点。

Without seeing the dumps you're talking about, it's probably a user defined function? See this thread ( http://lists.mysql.com/internals/33707 ) for a couple of gotchas and how to do it.

埖埖迣鎅 2024-11-16 10:37:57

不优雅,但有效的解决方案是修补 /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

Not elegant, but working solution is to patch /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 

It works because CURRENTLY there is only one format string '%.2f sec' in the mysql binary, BUT it may change over time.
You may revert to the original binary by applying reverse patch:

sed -i -e 's/%.8f sec/%.2f sec/1' ~/mysql
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文