我有以下规格的专用服务器：
问题是，即使有这样的规格，MySQL仍然占用较高的CPU使用量。 它几乎一直保持在150％以上，大部分时间超过300％。 运行“top”命令后我才知道这个。 现在的事情是，只要我运行“看mysqladmin公关”看看发生了什么，那么我没有看到任何问题。 虽然有查询正在运行，但它们不像一些非常繁重的查询，除了可能是一个或两个。
我运行“mysqltunner.pl”，它显示了以下内容：
-------- Storage Engine Statistics ------------------------------------------- [--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 362M (Tables: 255) [--] Data in InnoDB tables: 880K (Tables: 55) [!!] Total fragmented tables: 2 -------- Performance Metrics ------------------------------------------------- [--] Up for: 3h 26m 51s (1M q [138.122 qps], 43K conn, TX: 3B, RX: 246M) [--] Reads / Writes: 93% / 7% [--] Total buffers: 830.0M global + 3.9M per thread (300 max threads) [OK] Maximum possible memory usage: 1.9G (50% of installed RAM) [OK] Slow queries: 0% (47/1M) [OK] Highest usage of available connections: 6% (18/300) [OK] Key buffer size / total MyISAM indexes: 256.0M/169.9M [OK] Key buffer hit rate: 100.0% (5B cached / 36K reads) [OK] Query cache efficiency: 84.2% (1M cached / 1M selects) [!!] Query cache prunes per day: 338346 [OK] Sorts requiring temporary tables: 0% (989 temp sorts / 242K sorts) [!!] Temporary tables created on disk: 38% (160K on disk / 420K total) [OK] Thread cache hit rate: 99% (18 created / 43K connections) [OK] Table cache hit rate: 98% (446 open / 452 opened) [OK] Open file limit used: 1% (663/65K) [OK] Table locks acquired immediately: 99% (684K immediate / 684K locks) [OK] InnoDB data size / buffer pool: 880.0K/8.0M -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Temporary table size is already large - reduce result set size Reduce your SELECT DISTINCT queries without LIMIT clauses Variables to adjust: query_cache_size (> 64M) ------------------------------------------------------------------------------ 正如你所看到的大部分参数是正确的，除了像2碎片整理表和小查询caching大小一些。 即使我解决这个问题，我也没有看到任何明显的性能提升。 所以现在我已经把注意力转移到了“在磁盘38％上创build的临时表”你认为这是因为这个MySQL占用了太多的CPU时间吗？ 我该如何改进呢？ 或者你看上面的结果后有什么别的吗？
目前我在MySQLconfiguration文件中关于临时表的设置是：
tmp_table_size = 1000M max_heap_table_size = 500M
即使我增加这些值，MySQL仍然在磁盘上创build临时表。 我如何解决它？ 我可以看到mysqltuner.pl也说我需要减less我的结果集，但是如果我给它足够的RAM来创build临时表不应该问题消失？
谢谢
你可能正在处理的症状，而不是问题。 开始的地方是看看是什么让你的负载如此之高。 它是内核模式的活动？ 是用户区活动吗？ 如果是内核模式，我猜测你有问题写入磁盘足够快，Io处于等待状态。 看顶部，iostat，vmstat等工具来开始缩小你的问题。
在负载很高的情况下，您可能会看到某种导致内核排队请求的等待。
请检查几件事情：
1）join_buffer_size
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_join_buffer_size
http://www.mysqlperformanceblog.com/2010/07/05/how-is-join_buffer_size-allocated/
2）sort_buffer_size
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_join_buffer_size
3）临时文件创build
http://dev.mysql.com/doc/refman/5.1/en/temporary-files.html
4）SELECT具有子SELECT的查询
您可能有许多查询执行速度慢，因为没有需要的列索引的表的存在。
如果给定数据库连接中的连接缓冲区/sorting缓冲区太小而无法保存临时结果，则连接缓冲区和/或sorting缓冲区将不得不作为临时表分页到磁盘。