我正在尝试使用 InnoDB 存储引擎优化运行 MySQL 的应用程序。
在实时环境中运行 innotop 时，我得到以下输出:
When Load QPS Slow QCacheHit KCacheHit BpsIn BpsOut
Now 0.00 87.80 0 41.21% 100.00% 11.51k 836.42k
Total 0.00 105.50 190 15.04% 99.34% 13.23k 692.85k
When、Load、QPS 和 Slow 是不言自明的。
但是 QCacheHit、KCacheHit、BpsIn 和 BpsOut 呢？一般来说，哪些值被认为是“好的”值，我应该什么时候开始担心？
最佳答案
比率是无用的。严重地。别理他们。 http://www.mysqlperformanceblog.com/2010/02/28/why-you-should-ignore-mysqls-key-cache-hit-ratio/
是的，我是 innotop 的作者。我加入了这些功能，这样人们就不会再要求我这样做了。
来自文章:
Summary
Major points in this article:
- Counter ratios are meaningless as a performance analysis metric because they are a) ratios of b) counters.
- You need to look at absolute magnitude, not ratios.
- For performance analysis, you need to measure elapsed time, not just the number of times something happens.
- In the absence of timing information, and if you trust the cache’s creator and assume that misses are more expensive than hits, then you care about cache misses, not cache hits.
- A Key_read is not guaranteed to be a random physical I/O, but it might be. Gather Key_reads/Uptime over 10-second or 60-second intervals and compare the results to your IO system’s capabilities.
- MySQL doesn’t have good instrumentation for scientifically choosing a key_buffer_size setting, but there are many unscientific approaches that are better than ratio-based tuning.
- Counter ratios suck for everything, not just for MyISAM tuning.
I’ve had some heated arguments over these points, so I don’t expect the above to pass without controversy. But really, it’s time to stop with the bad advice about counter ratios. The sooner we do that, the sooner we can move on to better things.
关于mysql - 您如何解释以下 innotop 输出？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4450568/