最近发现，当模拟并发的100-500个线程请求时，我的MySQL服务器的CPU利用率高达90％
默认设置加上以下my.cnf
max_connections = 500 max_allowed_packet = 16M
我注意到max_connection可以达到500，threads_created也可以高到200-500，我认为这实际上导致了exception高的CPU
因此，而不是使用我调整的默认设置
innodb_buffer_pool_size = 2G＃32位的linux服务器 innodb_log_file_size = 256M innodb_log_buffer_size = 8M innodb_thread_concurrency = 16 innodb_flush_method = O_DIRECT innodb_additional_mem_pool_size = 20M table_cache = 1028 thread_cache_size = 16 的key_buffer_size = 32M query_cache_sizevariables= 32M join_buffer_size = 1M
在相同的负载testing中，CPU下降到10％以下…但是我注意到max_connection从来没有再次达到500。 现在还不到50
这是由thread_cache_size我调整了吗？ 在默认情况下，它是0.还是有什么地方错了…我想知道在这种情况下，如果MySQL服务器正确testing与最大连接。 我想testing一下，如果并发线程可以达到max_connections，但不知怎么的，它从来没有用我之前testing过的相同数量命中。 自改变以来，它现在从未超过50。
任何想法？
这是由thread_cache_size我调整了吗？
我不相信。 您改进了许多设置，以便您的查询将更快地完成，从而减less线程数量。 thread_cache_size应该在连接突发时启动，并根据http://dev.mysql.com/doc/refman/5.1/en/miscellaneous-optimization-tips.html减less相关的开销
使用数据库的持久连接来避免连接开销。 如果不能使用持续连接，并且正在启动许多到数据库的新连接，则可能需要更改thread_cache_sizevariables的值。
我会说是的。 每次连接closures时，MySQL都会将线程caching中闲置的线程数与thread_cache_size的值进行比较。 如果caching中已经有很multithreading，则用于断开会话的线程被销毁。 如果不是，则线程被放入caching。
每次build立新的连接时，服务器都会检查线程caching，看看caching中是否有可用的服务来连接新的连接。 如果是这样，它将从caching中删除并分配给新的连接。 如果不是，则会产生一个新的线程。
显然，重用一个线程是一个比创build和销毁更less的CPU密集型操作，所以是的，有一个非零的线程caching是特别有用的，尤其是当你连接和频繁断开…在可能的成本增加内存利用有点，因为高速caching中的线程（从我所知道的）不会释放任何分配给自己的内存，即使该内存高于分配给每个新线程的基线。
threads_created计数器告诉你有多less连接不能从线程caching中提供。