Mysql
table_cache 命中率有什麼問題?
在
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 命中率低的任何原因?
有一件事,在這裡,你應該使用這種形式,而不是:
mysql> show global status like '%open%';
其中一些計數器是全域的,其中一些是會話的,所以不使用
GLOBAL
關鍵字會給你一組數字(尤其是Opened_table*
值)。調整腳本的問題是它們不可能考慮到在決定值是否在合理範圍內時需要考慮的所有因素……例如,如果你使用
FLUSH TABLES
,你的Opened_files
和Opened_tables
計數器將立即增加因為所有被刷新的表都會在再次被訪問時重新打開……當然,這完全沒有負面意義。用於
mysqldump
備份通常會在備份過程開始時發出 aFLUSH TABLES
或FLUSH TABLES WITH READ LOCK
再一次,這並不意味著什麼。“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
快速增加,除非可能是在備份後流量增加期間,那麼您就沒有問題。這對我來說像是一場虛驚。