MySQL table_cache 和 Opened_tables

Question

我见过有人用Open_tables和Opened_tables的对比来评估MySQL中table_cache是​​否太小。但是，我相信 Opened_tables 在正常运行时间内是累积的，所以这不是一个有效的比较。唯一需要注意的是，也许 Opened_tables 只会在未命中时受到冲击 - 尽管即使如此，如果每秒打开的表仍然很小，它逐渐增长可能不是问题。

如果将 Open_tables 与 Opened_tables 进行比较无效，是否有另一种方法可以获得测量数据？

这是在 MySQL 5.0 上，但也欢迎版本之间的差异。

Answer 1

拥有大 table_cache 的最大原因是LOCK_open 互斥锁不热。当你试图打开/关闭表时，5.5 之前的 MySQL 有很多争用，所以你想尽可能地限制这样做，即有一个大的表缓存。

所以你不关心命中与未命中的任何特定比率（事实上你应该完全忽略比率 -这篇博文解释了原因）。您关心的是未命中率，因为每秒发生的次数越多，发生争用的可能性就越大（一个线程必须等待另一个线程释放锁。）

您如何发现未命中率？您在一天中最繁忙的时段间隔几秒钟获取 Opened_Tables 的几个样本，如果每个样本都有增加，那么看看是否可以增加 table_cache 可能是个好主意。

注意：我特别不建议与正常运行时间进行比较。

Answer 2

首先，让我们考虑这些状态变量：

打开的表：打开的表的数量。

Opened_tables：已打开的表数。如果 Opened_tables 很大，则 table_open_cache 值可能太小。

令人惊讶的是，您的问题的答案就在问题本身中。

如果您再将一个状态变量放入组合中，这两个变量只会更有意义：正常运行时间（或在FLUSH STATUS之后的新鲜平均值的Uptime_since_flush状态）。

您应该比较 Open_tables agsinst ( Opened_tables / Uptime)。如果 Open_tables 超过( Opened_tables / Uptime)，现在您有理由担心并且应该留意以下内容：

• 网络统计
• iostat
• 服务器负载
• 连接计数（当它接近max_connections 时）
• 中止的客户
• 中止连接
• 慢查询

更新 2011-08-31 12:18 EDT

请注意为什么我还建议使用Uptime_since_flush_status而不是Uptime来修复给定时期的Opened_tables增长模式。

例如，如果您FLUSH STATUS;每周一午夜运行，则可以生成一个 OpenTableFactor：

SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM
(SELECT variable_value Uptime FROM information_schema.global_status
WHERE variable_name = 'Uptime_since_flush_status') up,
(SELECT variable_value Open_tables FROM information_schema.global_status
WHERE variable_name = 'Open_tables') opn,
(SELECT IF(variable_value=0,1,variable_value) Opened_tables
FROM information_schema.global_status
WHERE variable_name = 'Opened_tables') opnd;

此打开表因子等于表示在任何给定时刻打开表的数量与整个给定期间内打开的表的平均数量之比的数字。对于FLUSH HOSTS;每周/天/主机，该平均值与周/天/小时相对。

这是我雇主的一位客户的样本：

mysql> SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM     (SELECT variable_value Uptime FROM information_sc    hema.global_status     WHERE variable_name = 'Uptime_since_flush_status') up,     (SELECT variable_value Open_tables FROM informat    ion_schema.global_status     WHERE variable_name = 'Open_tables') opn,     (SELECT IF(variable_value=0,1,variable_value) Opened_ta    bles     FROM information_schema.global_status     WHERE variable_name = 'Opened_tables') opnd;
+----------+-------------+---------------+-------------------+
| Uptime   | Open_tables | Opened_tables | OpenTableFactor   |
+----------+-------------+---------------+-------------------+
| 14385123 | 16326       | 30429078      | 7717.996519579068 |
+----------+-------------+---------------+-------------------+
1 row in set (0.00 sec)

该客户端通常最多保持大约 7745 OpenTableFactor。如果 OpenTableFactor 突然下降（即使是一点点），它可能表明较低的流量模式、较高的中止连接等。如果 OpenTableFactor 永远不会改变（即使是一点点），它可以为您提供更改这些设置的机会：

• open_files_limit
• innodb_open_files
• table_open_cache

一旦调整，OpenTableFactor 可能会不断变化或达到另一个上限或平台。因此，在状态变量中使用不同的单位对于这种调整变得至关重要。

更新 2011-08-31 12:42 EDT

我为 OpenTableFactor 运行的 SQL 查询不适用于 MySQL 5.0 及后面版本。如果您使用MySQL Administrator或MONyog，则可以使用查询和监视器中的公式自定义图形。MONyog 使用 SQLLite 收集历史以供以后绘制历史图表。这可以在任何版本的 MySQL 中完成。