MySQL查询缓存效率

Question

我正在使用MySQLTuner.pl来优化我的网站...。尽管我不确定如何解决其中一些问题，并且想知道是否有人可以帮助我。

如果使用以下MySQL设置，MySQL大约需要4GB可用内存：

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

我还有什么可以改善以获得更好的性能的吗？

谢谢

Answer 1

“查询缓存效率：0.1％（703K缓存/ 519M选择）”表示您在缓存生命周期内没有重复查询。

这可能是由于三个因素造成的：缓存寿命太短而无法显示重复，或者查询太大或不同而无法缓存。

例如，某些框架将运行大型SELECT ，然后在服务器端“过滤”（甚至在服务器端缓存 ）。 MySQL看到的是一个大型查询，最好将其视为不缓存，并且MySQL效率下降，而总体效率保持不变。

或者，您可能有很多不同的客户端，并且每个客户端都使用自定义数据（例如，它们的消息表内容）运行一些查询。 如果您有一千个客户，每个客户占据一兆字节，并且每个客户每分钟检查一次消息，那么如果您有一个千兆字节专用于此类查询，则每小时将看到一千次未命中和五万九千次点击。 但是，如果只有999个兆字节，则最后一个客户端将从缓存中清除第一个客户端，然后第一个客户端再次出现并丢失，并清除第二个客户端，依此类推； 在同一小时内，您会看到6万次未击中 ，效率从98％下降到0％。

因此，首先，您需要仔细查看正在运行的查询 。 也许其中的一些可以优化，例如缓存：一个大查询运行两次，两次优化而不是两次大查询，并且第一个被缓存。 但是请记住，您这样做可能会牺牲效率。

从您的其他结果来看，情况似乎是这样。 您有很多插入内容，有很多免费的查询缓存，而命中次数却很少。 因此，显然您的所有查询都彼此不同：在这种情况下，您希望减少查询缓存的内存以释放内存以用于任何其他目的。 即使命中率进一步降低，阿姆达尔定律也将确保与查询相关的性能不会如此相关（您损失了0.01％的50％，实际上您实际上损失了0.005％；不要让“ 百分之五十的损失！ ”吓到了。您）。

Qcache_free_memory  134,026,728
Qcache_hits             704,192
Qcache_inserts      143,569,852

肯定不会受伤的是检查哪些查询可能不值得 ，并且可以使用SQL_NO_CACHE进行升级。 它们仍将成为高速缓存未命中的对象，但不会降低其他查询的性能，从而可能会发现更多内存并提高其性能。 无论如何，这都是零成本的，所以总是可以做到的（对于足够大的查询，他们值得为此付出麻烦！）。

完成此操作后，您可以尝试使用query_cache_size参数。 检查其他组件正在使用多少内存，以及文件系统缓存的性能。 您不想加快查询速度并看到页面两次翻阅，因为视图和控制器组件的检索已使它陷入困境。

您可能要看的另一件事是索引。 您可以降低慢查询的限制，并检查是否有查询的运行速度明显慢于其他查询，并通过查看查询计划来检查原因。