table_cache 命中率有什么问题？

Question

在my.cnf我有：

table_cache            = 524288
open_files_limit        = 65535

两者都处于 mysql 配置的最大允许值。两者都小于最大打开文件限制：

# cat /proc/sys/fs/file-max
2097152

MySQL 变量状态：

mysql> SHOW GLOBAL STATUS LIKE 'open%';
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| Open_files               | 193    |
| Open_streams             | 0      |
| Open_table_definitions   | 594    |
| Open_tables              | 802    |
| Opened_files             | 537248 |
| Opened_table_definitions | 4895   |
| Opened_tables            | 9174   |
+--------------------------+--------+
7 rows in set (0.00 sec)

服务器有 32GB 内存。大部分免费！

尽管如此，当我运行 mysqltuner 脚本时：

它说：

[!!] 表缓存命中率：13%（853打开/6K打开）

table_cache 命中率低的任何原因？

Answer 1

有一件事，在这里，你应该使用这个表格，而不是：

mysql> show global status like '%open%';

其中一些计数器是全局的，其中一些是会话的，因此不使用GLOBAL关键字会为您提供一组拆分的数字（尤其是Opened_table*值）。

调优脚本的问题在于，在决定值是否在合理范围内时，它们不可能考虑所有需要考虑的因素……例如，如果您使用FLUSH TABLES，您的Opened_files和Opened_tables计数器将立即增加因为所有被刷新的表都会在再次访问时重新打开......当然，这完全没有负面意义。

使用mysqldump备份通常会发出FLUSH TABLES或FLUSH TABLES WITH READ LOCK在备份过程的开始，这意味着如果你跑了日常备份和有甚至几天的服务器正常运行时间，你可以很容易地看到一个非常贫穷的“table_cache的命中率”，而且，再一次，它没有任何意义。

“Table_cache 命中率”实际上不是来自 MySQL 的值。这是根据其他两个值的计算。他们在 mysqltuner 中所做的就是将 open_tables 除以 open_tables（现在打开的数量与曾经打开的数量相比）。

badprint "Table cache hit rate: $mycalc{'table_cache_hit_rate'}% (".hr_num($mystat{'Open_tables'})." open / ".hr_num($mystat{'Opened_tables'})." opened)\n";

因此，如果您随着时间的推移观察这两个值并且没有看到Opened_tables快速增加，除非在备份后流量增加的时间段内，那么您没有问题。

这对我来说似乎是一个误报。