The INSERT DELAYED table is one of the handful that use MyISAM, along with the session table and the ones that need Fulltext indexes.
Quote
query_cache_size | 536870912 -- this may be excessive. The reason? Some actions on the QC are take linear time, thereby run slower when the QC is bigger.
Most portions of the database - especially those that are read the most - are only updated a few times a week at most, in large bulks.
@ Linear complexity: Well if it's linear, it could be much worse. ;o) Will keep an eye on it, though. But the biggest portion of the queries stored there will still be retrieved much faster from the QC than live.
@ Inefficient QC: Restarted the server a few hours after my last post - the old data did not properly reflect the fact that I modified SQL_NO_CACHE handling drastically.
Status after 5 hours:
mysql> SHOW GLOBAL STATUS LIKE "%Qcache%";
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| Qcache_free_blocks | 1 |
| Qcache_free_memory | 302831920 |
| Qcache_hits | 5730396 |
| Qcache_inserts | 212007 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 27424058 |
| Qcache_queries_in_cache | 211763 |
| Qcache_total_blocks | 424020 |
+-------------------------+-----------+
Looks great to me.
@ Aborted connections: Yep, found those, too. Still leaves me puzzled because I can't see what would cause the need for such a huge timeout.