我们看到一个奇怪的统计数字的表打开数量。 我已经附加了下面的mysqltuner转储。
它说我们已经在过去的24小时里打开了94,000张桌子。 但总共只有15000个表，我们知道在这个特定的从属副本上只有大约100个表被访问。
而且它说我们只caching那些94k的2k。
我如何理解这些数字？ 以及如何解决caching问题 – 确定我们可以“增加表caching”，但这听起来不像根本问题。
-------- General Statistics -------------------------------------------------- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.1.41-3ubuntu12.9-log [OK] Operating on 64-bit architecture -------- Storage Engine Statistics ------------------------------------------- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 4G (Tables: 14960) [--] Data in InnoDB tables: 225M (Tables: 570) [!!] Total fragmented tables: 2115 -------- Performance Metrics ------------------------------------------------- [--] Up for: 2h 13m 36s (647K q [80.798 qps], 28K conn, TX: 247B, RX: 542M) [--] Reads / Writes: 63% / 37% [--] Total buffers: 2.5G global + 2.7M per thread (1000 max threads) [OK] Maximum possible memory usage: 5.2G (66% of installed RAM) [OK] Slow queries: 0% (783/647K) [OK] Highest usage of available connections: 5% (57/1000) [OK] Key buffer size / total MyISAM indexes: 1.0G/1.4G [OK] Key buffer hit rate: 100.0% (763M cached / 74K reads) [OK] Query cache efficiency: 55.5% (335K cached / 604K selects) [OK] Query cache prunes per day: 0 [OK] Sorts requiring temporary tables: 0% (312 temp sorts / 113K sorts) [!!] Temporary tables created on disk: 47% (59K on disk / 124K total) [OK] Thread cache hit rate: 99% (63 created / 28K connections) [!!] Table cache hit rate: 2% (2K open / 94K opened) [OK] Open file limit used: 75% (3K/5K) [OK] Table locks acquired immediately: 99% (577K immediate / 583K locks) [!!] Connections aborted: 45% [OK] InnoDB data size / buffer pool: 225.3M/256.0M -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Temporary table size is already large - reduce result set size Reduce your SELECT DISTINCT queries without LIMIT clauses Increase table_cache gradually to avoid file descriptor limits Your applications are not closing MySQL connections properly Variables to adjust: table_cache (> 2048) 请参阅官方手册中的“MySQL如何打开/closures表” ，以便对表caching的相当好的描述以及如何使用它以及一些有用的注释。 查询中使用的每个表可能会有多个句柄，这意味着如果您有较高的请求并发性并使用包含多个表的查询，则每个表可能需要数十个句柄。
你可以做的一件有用的事情是使用某种forms的监视来每分钟检查open_table / opened_tables的值，看看它们是如何工作的。 在我的情况下，很容易看到交通突然高峰可能导致opens_tables大幅增加。
还有这个和你的问题非常相似的问题 。
lwdba @ localhost（DB information_schema）::显示像'query％'这样的variables;
+ —————————— + ———- +
| variables名| 值|
+ —————————— + ———- +
| query_alloc_block_size | 8192 |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 67108864 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
| query_prealloc_size | 8192 |
+ —————————— + ———- +
在这个显示中， query_cache_size （全局variables）是64M。 query_cache_limit是1M。
这意味着我可以有多达64个查询caching其最大数据集为1M或更less，或128个查询与500K数据集caching，或任何其他组合，总共可达64M。
您可能需要使用这些设置（ query_cache_size和query_cache_limit ）来玩一些游戏，以便正确caching更大的查询数据集。 否则，不符合这两个variables限制的查询将不会被caching。