Re: Optimized Indexing for a Schedule Table
Posted by:
Rick James
Date: November 27, 2010 01:31PM
"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.)
Subject
Views
Written By
Posted
3851
November 23, 2010 11:58PM
1281
November 25, 2010 02:35PM
1911
November 25, 2010 10:47PM
1349
November 25, 2010 11:05PM
1790
November 26, 2010 01:42PM
1419
November 26, 2010 11:36PM
Re: Optimized Indexing for a Schedule Table
1513
November 27, 2010 01:31PM
1416
November 27, 2010 02:44PM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.