如何优化table_cache？

Question

我搜索了谷歌，但找不到确切的答案。有些人的这个值是 10000 甚至 20000。其他人说即使 1000 对 1GB 的 RAM 来说也太多了。我糊涂了。

我的数量在opened_tables增长。Mysqltuner 说我应该提高table_cache价值。我试着把它提高到 2K，然后是 3K，然后是 4K，然后我把它变成了 512，看看会发生什么。这是报告：

Currently running supported MySQL version 5.0.67-community-nt-log
Operating on 32-bit architecture with less than 2GB RAM
Archive Engine Installed
Berkeley DB Engine Not Installed
Federated Engine Installed
InnoDB Engine Installed
ISAM Engine Not Installed
NDBCLUSTER Engine Not Installed
Data in InnoDB tables: 12M (Tables: 3)
Data in MEMORY tables: 380K (Tables: 2)
Data in MyISAM tables: 83M (Tables: 84)
Total fragmented tables: 16
All database users have passwords assigned
Up for: 16h 12m 55s (161K q [2.000 qps], 6K conn, TX: 281M, RX: 22M)
Reads / Writes: 69% / 31%
Total buffers: 128.0M global + 2.1M per thread (100 max threads)
Maximum possible memory usage: 334.3M (16% of installed RAM)
Slow queries: 1% (11/161K)
Highest usage of available connections: 10% (10/100)
Key buffer size / total MyISAM indexes: 32.0M/4.1M
Key buffer hit rate: 97% (849K cached / 20K reads)
Query cache efficiency: 28% (26K cached / 93K selects)
Query cache prunes per day: 0
Sorts requiring temporary tables: 1% (1 temp sorts / 21K sorts)
Temporary tables created on disk: 1% (2 on disk / 15K total)
Thread cache hit rate: 99% (10 created / 6K connections)
Table cache hit rate: 5% (139 open / 2K opened)
Open file limit used: 20% (232/1K)
Table locks acquired immediately: 99% (116K immediate / 116K locks)
InnoDB data size / buffer pool: 12.5M/32.0M
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Increase table_cache gradually to avoid file descriptor limits
table_cache (> 512)
Scan Complete

mysql> show global STATUS LIKE 'open%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_files    | 222   |
| Open_streams  | 0     |
| Open_tables   | 127   |
| Opened_tables | 2335  |
+---------------+-------+
4 rows in set (0.00 sec)

然而，opened_tables仍在增长。我应该再提一次吗？还是不值得关注？

另外，也有人说问题通常是创建了很多临时表。正如我们从统计数据中看到的，这不是我的情况。table_cache和RAM之间的比例是多少？

Answer 1

你没有找到答案的原因是没有答案。的适当值table_cache与系统内存量无关。

请注意，table_cache它table_open_cache 在 MySQL 5.1.3中被重命名，并在较新版本的 MySQL 中由新名称引用。

正如我提到我回答这个类似最近的问题，其中，可以增加的东西opened_tables，有些人都是无害的和不可避免的（如用做备份mysqldump，其中，在大多数情况下，问题的一些变种FLUSH TABLES，这增加这些计数器为每个表在刷新后重新打开，要么是为了备份表，要么是由其他客户端线程访问最近刷新的表，这些表自然必须重新打开）。

我没想到在那篇文章中提到的是——我相信你会发现一些有趣的东西——在你的服务器上运行 mysqltuner 的行为本身可以增加opened_tables计数器，从而使它自己的结果无效.

我的回答的评论者引用了这篇文章，作者指出，调整table_cache越“优化”，性能越差。

最重要的是，这是一个很好的变量示例，除非您有特定的理由来调整它，否则最好不要理会它，并且调整脚本的输出不算数。调整脚本通常是善意的，但这有时是关于它们的最好的说法：

有时看似正确的相关性的问题在于，人们开始相信它们将永远正确。几年前，Oracle DBA 放弃了基于比率的调优，我们希望 MySQL DBA 能效仿他们。

我们更热切地希望人们不要编写“调整脚本”来编纂这些危险的做法并将它们教给成千上万的人。这导致我们不该做什么的第二个建议：不要使用调整脚本！您可以在 Internet 上找到几种非常流行的方法。最好忽略它们。

我们还建议您避免使用我们在过去几段中大量使用的“调​​音”一词。相反，我们更喜欢“配置”或“优化”（只要这是您实际在做的事情；请参阅第 3 章）。“调整”这个词让人联想到一个没有纪律的新手调整服务器并观察会发生什么的图像。我们在上一节中建议，最好将这种做法留给正在研究服务器内部结构的人。

“调整”您的服务器可能是一种惊人的时间浪费。

^{——施瓦茨，男爵；扎伊采夫，彼得；瓦迪姆特卡琴科 (2012-03-05)。高性能 MySQL：优化、备份和复制（Kindle 位置 12173-12182）。OReilly Media - A. Kindle 版。}

附带说明一下，MySQL 5.0 即将结束。MySQL 5.0.67 于 4 年前发布，此后在 5.0 版本系列中修复了大量错误。如果我有一个 5.0.67 服务器，并且它可以工作，那么我最不想做的就是更改有关其配置的任何内容。