我有一个具有以下规格的专用服务器：
问题是，即使有这样的规格，MySQL 仍然需要很高的 CPU 使用率。它几乎一直保持在 150% 以上，大部分时间都在 300% 以上。我在运行“top”命令后才知道这一点。现在，只要我运行“watch mysqladmin pr”来查看发生了什么，我就看不到任何问题。虽然有查询在运行，但它们不像一些非常繁重的查询，除了可能是一两个。
我运行了“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 个碎片整理表和小的查询缓存大小。即使我解决了这个问题，我也看不到任何明显的性能提升。所以现在我把注意力转向了这个“在磁盘 38% 上创建的临时表”你认为是因为这个 MySQL 占用了太多的 CPU 时间吗？我该如何改进？或者您在查看上述结果后是否认为还有其他事情？
目前我关于 MySQL 配置文件中临时表的设置是：
tmp_table_size=1000M max_heap_table_size=500M
即使我增加这些值，MySQL 仍会在磁盘上创建临时表。我如何解决它？我可以看到 mysqltuner.pl 也说我需要减少我的结果集，但是如果我给它足够的 RAM 来创建临时表，问题不应该消失吗？
谢谢
您可能正在解决症状而不是问题。开始的地方是查看是什么使您的负载如此之高。它是内核模式活动吗？是用户空间活动吗？如果是内核模式，我的猜测是您在足够快地写入磁盘时遇到问题，并且 io 处于等待状态。查看 top、iostat、vmstat 等工具以开始缩小问题范围。
由于负载如此之高，您可能会看到某种导致内核对请求进行排队的等待。