mysql调优技巧 增加线程缓存大小

增加线程缓存大小

连接管理器线程处理服务器监听的网络接口上的客户端连接请求。连接管理器线程将每个客户端连接与专用于它的线程关联，该线程负责处理该连接的身份验证和所有请求处理。因此，线程和当前连接的客户端之间是一对一的比例。确保线程缓存足够大以容纳所有传入请求是非常重要的。

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％越好。

如果这些指标的值等于或超过指定值，则可以将每一个指标配置为发出警告和/或严重警报

表对象缓存： 是将某个表对象的字典信息（定义内容）缓存到内存中，用来提高对表的访问效率。某个表被访问过一次后，只要服务器没有关闭且表定义没有被修改的条件下，访问该表，只需要从内存中找到这个已经缓存起来的对象做相应 *** 作即可。

用户访问表时，表对象在缓存时： 通过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)的总数

---