mysql table_open_cache 到底有什么影响

mysql table_open_cache有什么影响？针对这个问题，本文详细介绍了相应的分析和解决方法，希望能帮助更多想要解决这个问题的小伙伴找到更简单易行的方法。

腾讯云上一期问了这个问题，其实看起来是这个table_open_cache，没什么。

table_open_cache是什么样的存在？让我们来看看。

首先，让我们通过sysbench做一个压力测试。在相同数据的基础上，所有其他参数不变，只改变table_open_cache。然后我们将看到整体压力测试数据发生了哪些变化。

测试方法和环境。

1个经过测试的数据库8G，4核内存磁盘SSD每秒300MB。

Test table_open_cache值更改。

1 4096

2 8192

3 1024

4 96

1 4096

结果

transactions: 193526(每秒806.21。)

读/写请求： 3483840(每秒14513.26。)

事件执行花费的总时间： 72006.8461s

响应时间：

最小： 6.27毫米

avg: 372.08ms毫秒

max: 1866.33ms

近似的95% : 604.04毫秒

将table_open_cache修改为8192。

transactions: 188719(每秒786.11。)

读/写请求：

       3397113 (14150.74 per sec.)

total time taken by event execution: 72013.6051s

    response time:

         min:                                        6.57ms

         avg:                                        381.59ms

         max:                                       1534.00ms

         approx.  95 percentile:             630.08ms

 transactions:                            189366 (788.85 per sec.)

 read/write requests:                 3408744 (14199.90 per sec.)

 total time taken by event execution: 72006.3405s

    response time:

         min:                                  5.48ms

         avg:                                380.25ms

         max:                               1433.75ms

         approx.  95 percentile:             619.79ms

在使用同样的压测命令，系统直接报错

只好降低同时连接的线程，降低到 200

 transactions:                        174108 (725.36 per sec.)

 read/write requests:                 3134050 (13056.84 per sec.)

total time taken by event execution: 48001.7575s

  response time:

         min:                                  5.70ms

         avg:                                275.70ms

         max:                               1528.54ms

         approx.  95 percentile:             472.15ms

从上面的简单测试，我们可以得出一个最简单的结果

table_open_cache 与你的系统的性能，在他的大小变化的时候对你的系统是有影响的，并且较小的值会让你的系统的性能整体下降。而过大的设置，并没有让系统的性能有提升，甚至还有小幅度的下降 event execution。

到这里估计有人会问，怎么设置这个值，我从来没有动过他，也没出过问题。

其实官方给了一个设置这个值的方法，官方给出的建议是你系统的连接的threads * N = table_open_cache 这里，连接数已经可以通过平时连接得出，但N这个数据，就只能预估了，每次的连接的查询的表的数量，说实话这个不好控制和锁定，我哪里知道平均一个连接每次访问几个表，当然如果你有金规铁律，一个SQL 最多不能产生3次JOIN 那就比较好办了。

平均1000的连接 * 3 = 3000  所以默认的4096 还是富富裕裕。 大多数的使用MYSQL 的公司，有几个人能说清楚MYSQL 每次的连接访问几个表呢。

那到底有什么办法看看我的 table_open_cache 到底是不是够， 有一个通用的公式

Table cache hit rate = table_open_cache*100/Opened_tables

根据这个公式我们看看不同的 table_open_cache 的 hit rate

96*100/739812 = 0.0129

1024*100/739812 = 0.13

4096* 100/739812 = 0.55

8192*100/739812 = 1.1

从上面的数字可以看到如果将table_open_cache 设置为6140 可能会更好一些。当然估计性能差距和4096之间也不会有太多差距。

有人可能会跳出来，有那么麻烦我设置大些

结果导致压力测试无法进行，也就是说过大和过小的设置都会导致系统无法正常工作。

WHY ,官方已经给出了解释

当然还有一个对于table_open_cache 的参数联动的设置 open_file_limit 所以在调整你的table_open_cache 时也是需要调整你的open_file_limit 

open_files_limit= Table_open_cache*2

所以系统的参数之间是环环相关的，互相影响。

关于mysql  table_open_cache 到底有什么影响问题的解答就分享到这里了，希望