MySQL  table_open_cache 到底有什么影响，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都网站建设、成都网站制作、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的秭归网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

之前腾讯云有一期问过这个问题，其实看似这个table_open_cache,没有什么。

到底table_open_cache 到底是一个什么存在感，我们的来看看。

首先我们先来一个测试通过sysbench 来进行一个压力测试，我们在同样的数据的基础上，其他所有的参数都不变，仅仅变化 table_open_cache，然后我们看看整体的压测数据有什么变化。

测试方式以及环境

1 测试的数据库 8G , 4 core 内存 磁盘SSD 每秒300MB

测试 table_open_cache 值变化

1  4096

2  8192

3  1024

4   96   

1 4096

结果

    transactions:                             193526 (806.21 per sec.)

    read/write requests:                 3483840 (14513.26 per sec.)

    total time taken by event execution: 72006.8461s

    response time:

         min:                                  6.27ms

         avg:                                372.08ms

         max:                               1866.33ms

         approx.  95 percentile:             604.04ms

修改table_open_cache 为8192

transactions:                             188719 (786.11 per sec.)

 read/write requests:                 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 到底有什么影响问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。

本文题目：mysqltable_open_cache到底有什么影响
链接分享：http://scyanting.com/article/jjcopi.html