问题总结

1.参数影响RDS实例性能

分库分表实例，共5台rds 相同的配置，每个rds20个表， 在执行相同的脚本（串行执行alter table 来回收表空间），

发现其中一台数据库（rds1）实例执行的速度比其他4台足足慢了1天， 分库分表，数据量是差不多的， 表大小也差不多，为什么会有这么大的差异呢？

排查结果：发现rds1的其中一个参数和其他的rds设置的不一样，其他4台设置的是16 只有rds设置的是1

参数：table_open_cache_instances

rds2~rds5

 rds1

 原因：（目前还未验证完成修改参数后是否有效）

table_open_cache：所有线程打开的表的数量。增加这个值会增加mysqld需要的文件描述符的数量。可以通过检查Opened_tables状态变量来检查是否需要增加表缓存。

table_open_cache_instances：

打开的表缓存实例的数量。为了通过减少会话间的争用来提高可伸缩性，可以将打开的表缓存划分为几个大小为table_open_cache / table_open_cache_instances的较小缓存实例。一个会话只需要锁定一个实例就可以访问DML语句。写到这里就已经大致了解到 如下关系:

table_definition_cache > table_open_cache_instances > table_open_cache

扩展：
1.table相关的限制有哪些？

mysql是多线程，对于并发同一个文件，不同数据的情况下，会打开多个文件，会存在哪些限制呢？下面是源代码里逻辑是怎样

1)table_definition_cache

.frm文件其实最大值只能到2000,跟官网给得最大值没关系

2）open_files_limit
imit_1= 10 + max_connections + table_cache_size * 2;
limit_2= max_connections * 5;
limit_3= open_files_limit ? open_files_limit : 5000;
可以看出max_connections有关，需要借助于table open file 的信息

3）max_connections超出打开文件数量的伐值的时候，也跟table_open_cache有关

4）table_cache_size 计算方式

备注：TABLE_OPEN_CACHE_MIN=table_open_cache

5.定期查看open table 情况
通过 show global status like ‘%Open%_table%’; 确认是否调优这个参数

2.常见故障应对：
如：在运行数据库通过 show processlist 可看到大量的 Opening tables、closing tables状态，导致应用端访问操作。
需要确认 table_open_cache=最大并发数表数量（join里可能用到2张表），时候满足当前配置
如：但并发线程数达到1000，假设这些并发连接中有40%是访问2张表，其他都是单表，那么cache size就会达到（100040%2+100060%*1）=1400
建议定期监控值：
Open_tables / Opened_tables >= 0.85 表的重复使用率
Open_tables / table_open_cache <= 0.95 缓存里存在已打开的表

1）5.7版本已经支持在线动态改配置信息

set global table_definition_cache=2000;
set global table_open_cache=3000;
set global max_connection= 2000;
table_open_cache_instances参数修改需要重新启动服务

2）无法更改的时候，可通过flush操作，但存在问题

MySQL closes an unused table and removes it from the table cache under the following circumstances: When the cache is full and a thread tries to open a table that is not in the cache.When the cache contains more than table_open_cache entries and a table in the cache is no longer being used by any threads.When a table-flushing operation occurs. This happens when someone issues a FLUSH TABLES statement or executes a mysqladmin flush-tables or mysqladmin refresh command.
这里好奇FLUSH TABLE操作，有如下隐患：
关闭所有打开的表，强制关闭所有正在使用的表，并刷新查询缓存和准备好的语句缓存。FLUSH TABLES还会从查询缓存中删除所有查询结果，比如RESET查询缓存语句。

备注：
另外 table_definition_cache为每个表的表空间中可以同时打开的InnoDB文件的数量定义了一个软限制，这也是由innodb_open_files控制的。
如果设置了table_definition_cache和innodb_open_files，则使用最高设置。如果两个变量都没有设置，则使用默认值更高的table_definition_cache。

总结：
Table缓存关于的参数table_definition_cache，table_definition_cache，table_open_cache_instances 按照实际环境和需求进行设置外，还有跟max_connections也要设置合理。有些环境里发现max_connections过大，过小设置的问题，设置过大可能会存在等待的情况
这些参数控制不好，会给MySQL数据库系统带来性能上的瓶颈。如果把握不是很准，有个很保守的设置建议：把MySQL数据库放在生产环境中试运行一段时间，然后把参数的值调整得比Opened_tables的数值大一些，并且保证在比较高负载的极端条件下依然比Opened_tables略大