Re: Optimized Indexing for a Schedule Table

[Rick James]

"RAM = 640MB" -- OMG! Reminds me of the famous quote from the early 80's: "No one will ever need more than 640MB". (It was referring to the hardware constrained limit of 640MB on the IBM-PC, released in 1981.)

What version of MySQL? 4.1? 5.0? 32-bit version, I assume.

| Innodb_buffer_pool_read_requests | 1308144552 |
| Innodb_buffer_pool_reads | 259664812 |
implies that you would be better off with more than 8MB for innodb_buffer_pool_size. But I have no feel for how big you can make it in such a tiny machine. Try 20M.

Over 100 queries/sec.

| Qcache_hits | 24053554 |
| Qcache_inserts | 7093485 |
Not very effective. You would probably be better off turning it off (thereby releasing some RAM):
query_cache_type = 0
(This may make things worse.)

If your system is new enough, do SHOW GLOBAL STATUS instead of SHOW STATUS. (The former will include Com_* values for all sessions, not just the current session.)