我正在使用MySQLTuner.pl来优化我的网站....虽然我不完全确定如何解决其中一些问题，但我想知道是否有人可以帮助我。
如果需要MySQL，我可以使用以下MySQL设置大约4GB ram：
key_buffer = 100M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 800
myisam-recover = BACKUP
max_connections = 750
table_cache = 125000
thread_concurrency = 500
query_cache_type=1
query_cache_limit = 128M
query_cache_size = 128M
tmp_table_size = 300M
max_heap_table_size = 300M
innodb_buffer_pool_size = 2G
innodb_file_per_table = 0
innodb_flush_log_at_trx_commit = 2
这是调谐器的输出
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.24-0ubuntu0.12.04.1
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 7K (Tables: 10)
[--] Data in InnoDB tables: 27M (Tables: 5)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 5
-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned
-------- Performance Metrics -------------------------------------------------
[--] Up for: 15d 5h 4m 19s (1B q [1K qps], 208M conn, TX: 172B, RX: 98B)
[--] Reads / Writes: 71% / 29%
[--] Total buffers: 2.5G global + 2.7M per thread (750 max threads)
[OK] Maximum possible memory usage: 4.5G (57% of installed RAM)
[OK] Slow queries: 0% (0/1B)
[OK] Highest usage of available connections: 15% (118/750)
[OK] Key buffer size / total MyISAM indexes: 100.0M/119.0K
[OK] Key buffer hit rate: 100.0% (22M cached / 0 reads)
[!!] Query cache efficiency: 0.1% (703K cached / 519M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (13 temp sorts / 13M sorts)
[OK] Temporary tables created on disk: 25% (4M on disk / 18M total)
[OK] Thread cache hit rate: 99% (752 created / 208M connections)
[OK] Table cache hit rate: 74% (992 open / 1K opened)
[OK] Open file limit used: 0% (68/250K)
[OK] Table locks acquired immediately: 100% (216M immediate / 216M locks)
[OK] InnoDB data size / buffer pool: 27.8M/2.0G
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
Variables to adjust:
query_cache_limit (> 128M, or use smaller result sets)
SHOW STATUS LIKE '%cache%'的输出是
Binlog_cache_disk_use 0
Binlog_cache_use 0
Binlog_stmt_cache_disk_use 0
Binlog_stmt_cache_use 0
Com_assign_to_keycache 0
Qcache_free_blocks 19
Qcache_free_memory 134026728
Qcache_hits 704192
Qcache_inserts 143569852
Qcache_lowmem_prunes 0
Qcache_not_cached 11043040
Qcache_queries_in_cache 94
Qcache_total_blocks 217
Ssl_callback_cache_hits 0
Ssl_session_cache_hits 0
Ssl_session_cache_misses 0
Ssl_session_cache_mode NONE
Ssl_session_cache_overflows 0
Ssl_session_cache_size 0
Ssl_session_cache_timeouts 0
Ssl_used_session_cache_entries 0
Threads_cached 748
为了获得更好的表现，还有什么我可以提高的吗？
谢谢
答案 0 :(得分：1)
“查询缓存效率：0.1％（703K缓存/ 519M选择）”表示您在缓存生命周期内没有重复查询。
这可能是由于三个因素：缓存生命周期太小而无法显示重复，或者您的查询太大或不同而无法缓存。
例如，某些框架将运行一个大的SELECT，然后“过滤”它的服务器端（甚至可能缓存它的服务器端）。 MySQL看到的是一个可能被认为最好不被缓存的大型查询，并且 MySQL 效率下降，而整体效率保持不变。
或者您可能拥有许多不同的客户端，并且每个客户端都会使用自定义数据（例如，其消息表内容）运行某些查询。如果你有一千个客户，每个客户占用一兆字节，并且每个客户每分钟检查一次消息，如果你有一千兆字节专门用于这类查询，你将看到一千个未命中和五十九千次点击每小时。但是如果你只有999兆，那么最后一个客户端会将第一个客户端从缓存中刷新，然后第一个客户端再次出现并得到一个未命中并刷新第二个客户端，依此类推;在同一个小时内你会看到六万未命中，效率从98％下降到0％。
首先，您需要仔细查看正在运行的查询。也许其中一些可以优化缓存：一个大查询运行两次，两个改进而不是两个大查询，第一个得到缓存。但请记住，您可能会以牺牲效率为代价来做这件事。
从您的其他结果来看，情况似乎如此。你有很多插入，大量的免费查询缓存，但很少有点击。显然，您的所有查询都是不同的：在此情况下，您希望减少查询缓存内存以释放内存用于任何其他目的。即使命中率进一步下降，Amdahl定律也会确保与查询相关的表现不会如此相关（你失去50％的0.01％，你真的总体损失了0.005％;不要让那个“百分之五十的损失！“吓唬你。”
Qcache_free_memory 134,026,728
Qcache_hits 704,192
Qcache_inserts 143,569,852
肯定不会受到影响的是检查哪些查询可能不值得，并且可以使用SQL_NO_CACHE进行升级。它们仍将成为缓存未命中，但不会降低其他查询的性能，这可能会找到更多内存并提高其性能。无论如何，这是零成本，所以总是可以做到（对于足够大的查询，当然它们值得麻烦！）。
完成此操作后，您可以试用query_cache_size参数。检查其他组件正在使用的内存量以及文件系统缓存的性能。您不希望加快查询速度并查看页面出现两次的时间，因为视图和控制器组件检索已经完成了。
您可能想要关注的另一件事是索引。您可以降低慢查询限制并检查是否有比其他查询运行速度慢得多的查询，并通过查看其查询计划来检查原因。