当禁用查询缓存时，为什么MySQL线程经常显示“正在释放项目”状态？

当我运行时SHOW PROCESSLIST，通常在“正在释放项目”状态下有大量的INSERT / UPDATE线程。

MySQL手册建议线程处于这种状态的原因至少有一部分涉及查询缓存-大概由于数据更改，它会使缓存的查询无效。

但是，将my query_cache_size设置为0会完全禁用查询缓存。

在这种状态下会有这么多线程还有什么其他原因？

相关表使用InnoDB存储引擎。

检查innodb_thread_concurrency的值。

对于我的系统，按照MySql文档中的准则，将值从8增加到32，导致同时报告“正在释放项目”状态的线程数明显减少。同样，平均查询时间下降了一个数量级。

尽管这在整体服务器性能上产生了很大的差异，但这并不是“释放项目”的灵丹妙药。我的硬件生态系统使我假设这种状态通常在具有“慢”磁盘（2x10k磁盘RAID 1）的系统上看到，而在具有更快存储（12x15k磁盘RAID 10）的系统上较不普遍。因此，也可能需要检查磁盘性能。

祝好运！

也：

值得注意的是，根据使用的是5.0版本，innodb_thread_concurrency的默认值完全不同。

默认值已更改了几次：在MySQL 5.0.8之前为8，从5.0.8到5.0.18为20（无限），从5.0.19到5.0.20为0（无限），以及从5.0.21为8（无限）。上。- 来源

这意味着从5.0.20到5.0.21的一次看似无害的升级将默认值从infinite更改为8，并带来了性能方面的影响。

释放项目是查询执行阶段，其中临时结构，缓冲区等被释放。在此阶段中完成了一些查询缓存工作，但这并不是那里唯一发生的事情。我建议使用SHOW PROFILES来查看此阶段相对于其他阶段要花费多长时间，如果花费的时间最终成为一个问题，请使用可怜的探查器和oprofile等工具进行故障排除。

关于此问题的错误报告涉及“释放项目”和查询缓存。尽管该错误已关闭，但没有提及innodb_thread_concurrency。

巧合的是，我在五月的Percona Live NYC与Ronald Bradford进行了交谈。我告诉他，由于MySQL 5.5的多个InnoDB缓冲池产生了大量线程锁定，因此我对innodb_thread_concurrency进行了周处理，并且我怀疑我最需要的缓存数据已经散布在多个缓冲池中。

他明确地告诉我，我永远不要为innodb_thread_concurrency设置值。使其始终为默认值，现在为零（0）。这样，您可以让InnoDB存储决定自己生成多少个innodb_concurrency_tickets。这就是无限并发性。

当我们对innodb_thread_concurrency施加限制时，“释放项目”最有可能发生。该值应始终为零（0）。我冒风险，提出了innodb_concurrency_tickets，看看是否有帮助。

我们有一个症状完全相同的问题。原来，包含InnoDB日志文件的磁盘已装满。值得检查。

另一个提示：可能是innodb fsync（）。尝试设定

innodb_flush_log_at_trx_commit = 2

在my.cnf中

然后，每1-2秒将innodb日志文件刷新到磁盘，而不是在每次提交时将ob刷新到磁盘。轻微影响数据完整性，提高速度。