我正在尝试查看问题统计信息的组成。
我正在计算问题的 QPS 图和总和的 QPS 图:
Com_select
Com_update
Com_delete
Com_replace_select
Com_set_option
Com_begin
Com_commit
基本上所有非零 Com_* 统计信息。但我仍然有高达 200 QPS 的图表差异。
有谁知道没有考虑到什么?
我正在使用 4.1.22 版本的 MySQL。
我正在尝试查看问题统计信息的组成。
我正在计算问题的 QPS 图和总和的 QPS 图:
Com_select
Com_update
Com_delete
Com_replace_select
Com_set_option
Com_begin
Com_commit
基本上所有非零 Com_* 统计信息。但我仍然有高达 200 QPS 的图表差异。
有谁知道没有考虑到什么?
我正在使用 4.1.22 版本的 MySQL。
我对此做了一些测试。我才知道我们又错过了一个重要的计数。
那就是Qcache_hits
将其包含在列表中,您将在两个地方看到几乎相似的计数。
“退出”也被考虑在内。我找不到它的文档,但已经测试过它可以工作:
首先,我发出两个连续的检查Questions
来测试测试本身:
root@mysql-5.1.51> show global status like 'questions';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions | 21113 |
+---------------+-------+
root@mysql-5.1.51> show global status like 'questions';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions | 21114 |
+---------------+-------+
因此,像这样的每次调用都会使 +1 on Questions
-- 我们将在未来的测试中减少它。
现在,我退出了一个活动会话,然后再次测试:
root@mysql-5.1.51> show global status like 'questions';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions | 21116 |
+---------------+-------+
我确保启用常规日志以测试 Quit 操作没有发出任何有趣的查询——它不是。
我不确定是否还有其他需要考虑的操作。
顺便说一句,从5.0.72和5.1.31 开始,规则发生了变化。阅读本文了解更多信息。