If you are still seeing on-disk temporary tables with your max_heap_table_size and tmp_table_size set that high, then chances are you have a handful of queries with GROUP BY/ORDER BY (or a complex join) that are not using indexes effectively and are generating an enormous amount of intermediate data or you have TEXT/BLOB columns somewhere. Since you said you don't have the latter, I'm guessing it's the former.
You have a few options
- Find the queries causing the problem. You can use pt-query-digest to help summarize the slow query log and make it easier to track down which queries are going to disk.
- Ignore it. This represents less than 1% of your queries. Unless it's causing you an actual problem, don't worry about it.
- If you can't ignore it, keep bumping up max_heap_table_size and tmp_table_size until the problem goes away. I wouldn't recommend this.
Keep in mind that MySQL pushes large temporary tables to disk for good reason. Eventually, you risk pushing other data out of memory (or worse, running the server out of memory) in order to process a handful of queries with very large data sets. Those settings are per table, so if you have any level of concurrency, you could get into trouble very quickly. I run in production with tmp_table_size/max_heap_table_size at 768MB, but I have 140GB of RAM to work with. Your headroom is much smaller with only 12GB.
Coming at this from the DB point of view, rather than WordPress.
Executive Summary
For each recommendation your optimiser script has generated, check out the appropriate MySQL documentation to see if it will impact your setup. Then tweak your my.conf little by little.
Your overall objective is for MySQL to load as much as it can into memory and not hit the disk. So increasing various caches will probably help. As long as you don't exceed the physical memory in your server (you need to take into account other processes running on the server). Then, make sure your tables are indexed appropriately.
Your Specific Issues
But to address each of the items you've listed:
Query cache is supported but not enabled; Perhaps you should set the query_cache_size
The query cache is like a big hash table of Select-Statement -> Result-Table. MySQL checks to see if the same query exists in the cache and returns the cached result without re-running the query. If you enable it, run SHOW VARIABLES to see how well utilised it is (having a huge cache which isn't used is just a waste of memory). My experience of the query cache is that it seems really good in theory, but didn't provide much help in practice.
You have had 11025 queries where a join could not use an index properly; You should enable "log-queries-not-using-indexes" then look for non indexed joins in the slow query log.
Indexes are what makes or breaks a database. Enable the slow query log and use EXPLAIN to see what queries are not using indexes. Fix the slow ones first.
You have a total of 834 tables; You have 528 open tables; Current table_cache hit rate is 8%, while 132% of your table cache is in use; You should probably increase your table_cache
MySQL ISAM databases exist as pairs (I think) of files on disk, but MySQL doesn't keep them open all the time, only ones used recently. The table_cache setting controls how many files it will keep open. This appears to be related to the number of connections, so be careful setting this too high, but it seems you have stacks of memory available so increase this until all tables are cached.
Current Lock Wait ratio = 1 : 529; You may benefit from selective use of InnoDB.
MyISAM tables are great for reading, but whenever you UPDATE, INSERT or DELETE from them MySQL locks the whole table. So if, for example, you have a Page table with a HitCount field which is incremented whenever the page is loaded, the entire Page table is locked and no other connections can read from it. I've seen some particular nasty combinations of read / write queries which would lock tables for minutes or even hours! Effectively killing the site.
InnoDB isn't as fast at reading, but supports more granular write operations (only locking the one record being updated). So is a better fit for tables which are written to more frequently. Converting tables with large numbers of UPDATE, INSERT and DELETE operations to InnoDB may decrease locking and increase performance. Many apps which use MySQL default to InnoDB across the board for this very reason.
I think you need to drop the old MyISAM tables and re-create them as InnoDB, so there will be downtime involved.
Apparently an ALTER TABLE statement is all you require to change the engine type. Although full table locks will be required, so you'll have some time when you can't run queries.
I don't know if WordPress assumes InnoDB or MyISAM tables. Please check WordPress before altering the tables' engine.
Current max_heap_table_size = 16 M; Current tmp_table_size = 16 M; Of 107071 temp tables, 25% were created on disk; Perhaps you should increase your tmp_table_size and/or max_heap_table_size to reduce the number of disk-based temporary tables
MySQL requires memory to do sorting (ORDER BY), JOINs and other operations involving large chunks of data, but only up to a certain limit, after that limit the operation spills out onto disk (so that one giant ORDER BY doesn't use up gigabytes of memory which could better be spent doing other things). Increasing max_heap_table_size and tmp_table_size means less operations run on the slow disk and more in fast memory (a discussion about these variables). 64M should be large enough for most cases, and making these too big means you're just wasting memory.
You have 1290 out of 1145245 that take longer than 2.000000 sec. to complete
Use the slow query log to figure out what these slow queries are. Although that ratio (0.11%) is pretty low, there may be a few really slow queries which are causing bigger problems.
Current max_connections = 500; Current threads_connected = 501; You should raise max_connections
Once you have more threads_connected than max_connections new connections are rejected. Increase max_connections (as you already have done).
As you can see, its not always obvious what to do without knowing what sorts of queries WordPress is generating.
Best Answer
Forget about mysqltuner and check for human advice. This tool tells you general recommendations that may be useless and even hurtful in some cases. Optimize table is probably going to be useless, but it locks your tables for writes. A consultant may save you time and money in the long run.
Swapping should be a no-go for MySQL. Make sure to tune your innodb_buffer_pool_size to maximize memory usage without swapping. Please make sure you understand that there may be other things using memory: filesystem cache, needed for logging and other operations, and per-client used memory, like the join buffer and sort buffers. All together should be less than the available physical memory, as MySQL/InnoDB does its own way of buffering, and if it uses virtual memory that in reality it is on disk, you are going to have a bad time.
It is difficult to provide foolproof "general advice" without a full review of your server. But in my experience, 90% of the problems are with the queries and the database design, not with the server configuration.
However, here you have a good introduction to MySQL/Innodb configuration optimization by a good human (Peter Zaitsev). Hope it helps.