189 8069 5689
表对象缓存： 是将某个表对象的字典信息（定义内容）缓存到内存中，用来提高对表的访问效率。某个表被访问过一次后，只要服务器没有关闭且表定义没有被修改的条件下，访问该表，只需要从内存中找到这个已经缓存起来的对象做相应操作即可。
创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：网站设计制作、成都网站设计、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的泽库网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！
用户访问表时，表对象在缓存时： 通过HASH算法找到TABLE_SHARE，然后每个线程构造各自的实例化TABLE即可。
用户访问表时，当表没有被缓存的情况下： 第一需要打开表，首先需要从系统表中将这个表的所有信息都读入内存中，这些信息包括表名、库名、所有列信息、列的默认值、表的字符集、对应的frm文件路径、所属存储引擎、主键等，将这些信息构造一个TABLE_SHARE结构体，这个结构体是表对象缓存的第一层，所有用户共享访问且为静态不允许修改，它是缓存在table_def_cache（由参数table_definition_cache控制）中的。
而真正与用户打交道的是TABLE_SHARE的衍生品，它对应结构体为TABLE，在被使用前需要将TABLE_SHARE结构体实例化TABLE才能被使用，由每个线程构造各自的实例化TABLE即可。（实例化的TABLE由table_open_cache及table_open_cache_instance控制）
注意1： DDL操作时会将所有instance锁住，而DML操作时instance之间互不干扰。
(DDL statements still require a lock on the entire cache, but such statements are much less frequent than DML statements.)
注意2： 一个线程中如果打开表过多，超过一个instance限制的大小时，是不能跨instance缓存的
(instance大小：table_open_cache / table_open_cache_instances)
表缓存涉及其他参数： 通过下面参数判断table_open_cache参数设置是否合理
table_open_cache_hit：能够从table open cache的free list中找到table则为命中，+1
table_open_cache_misses：与table_open_cache_hit相反，如果找不到则需要重新实例化则+1，通常发生在初始化第一次加载表或超过table_open_cache的设置被淘汰后需要重新实例化。
table_open_cache_overflow：table cache淘汰的数量，每次淘汰+1
opened_tables:已经打开的表数。如果Opened_tables很大，那么table_open_cache的值可能太小了。
open_tables：总的instance (table cache)的总数
增加线程缓存大小
连接管理器线程处理服务器监听的网络接口上的客户端连接请求。连接管理器线程将每个客户端连接与专用于它的线程关联，该线程负责处理该连接的身份验证和所有请求处理。因此，线程和当前连接的客户端之间是一对一的比例。确保线程缓存足够大以容纳所有传入请求是非常重要的。
MySQL提供了许多与连接线程相关的服务器变量：
线程缓存大小由thread_cache_size系统变量决定。默认值为0（无缓存），这将导致为每个新连接设置一个线程，并在连接终止时需要处理该线程。如果希望服务器每秒接收数百个连接请求，那么应该将thread_cache_size设置的足够高，以便大多数新连接可以使用缓存线程。可以在服务器启动或运行时设置max_connections的值。
还应该监视缓存中的线程数（Threads_cached）以及创建了多少个线程，因为无法从缓存中获取线程（Threads_created）。关于后者，如果Threads_created继续以每分钟多于几个线程的增加，请考虑增加thread_cache_size的值。
使用MySQL show status命令显示MySQL的变量和状态信息。这里有几个例子：
Monyog线程缓存监测
Monyog提供了一个监控线程缓存的屏幕，名为“线程”。与MySQL线程相关的服务器变量映射到以下Monyog指标：
Monyog线程屏幕还包括“线程缓存命中率”指标。这是一个提示线程缓存命中率的指标。如果值较低，则应该考虑增加线程缓存。在状态栏以百分比形式显示该值；它的值越接近100％越好。
如果这些指标的值等于或超过指定值，则可以将每一个指标配置为发出警告和/或严重警报
我们都知道 MySQL 的 Table Cache 是表定义的缓存，江湖上流传着各种对这个参数的调优方法。
table cache 的作用，就是节约读取表结构文件的开销。对于table cache 是否命中，其实table cache 是针对于线程的，每个线程有自己的缓存，只缓存本线程的表结构定义。不过我们发现，strace 中没有关于表结构文件的 open 操作（只有 stat 操作，定位表结构文件是否存在），也就是说 table cache 不命中，不一定需要读取表结构文件。这种感觉好像是：在不命中 table cache 时，命中了另外一个表结构缓存。
运维建议：
我们读一下 MySQL 的文档，关于 table_open_cache 的建议值公式：建议值 = 最大并发数 * join 语句涉及的表的最大个数。
通过实验我们容易理解：table_cache 是针对于线程的，所以需要最大并发数个缓存。另外，一个语句 join 涉及的表，需要同时在缓存中存在。所以最小的缓存大小，等于语句 join 涉及的表的最大个数。将这两个数相乘，就得到了 MySQL 的建议值公式。