如何在mysql命令行中查看高精度查询时间?
我正在进行一些优化工作,并且我注意到在一些人们在文章和问题中发布的 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
似乎对此问题的最佳答案是启用分析。没有其他线索成功。
最佳答案,使用查询分析。
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.
这个问题最好通过查看 mysql 的源代码来回答命令行客户端。 相关代码,
有硬编码为 (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,
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).
如果没有看到您所说的转储,它可能是用户定义的函数?请参阅此线程(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.
不优雅,但有效的解决方案是修补
/usr/bin/mysql
:它有效,因为当前 mysql 二进制文件中只有一种格式字符串“%.2f sec”,但它可能会随着时间的推移而改变。
您可以通过应用反向补丁恢复到原始二进制文件:
Not elegant, but working solution is to patch
/usr/bin/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: