MySQL Forums
Forum List  »  Optimizer & Parser

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.)

Options: ReplyQuote

Written By
November 23, 2010 11:58PM
Re: Optimized Indexing for a Schedule Table
November 27, 2010 01:31PM

Sorry, you can't reply to this topic. It has been closed.
This forum is currently read only. You can not log in or make any changes. This is a temporary situation.

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.