Memcached + MySQL

Brian Aker brian at
Wed Oct 31 22:29:13 UTC 2007


On Oct 31, 2007, at 3:57 AM, Alexander Zaitsev wrote:

> MySQL itself has a bunch of optimization options that effectively  
> turn disk reads into memory reads . In your case I would guess that  
> following tuning would help:
> 1. Increase MySQL query cache size
> 2. increase key_buffer_size (normal value is 512K).

This really isn't the right mailing list for this, but the above is  
not quite right. The query cache is purged pretty constantly with  
Innodb (and its very accurate except in the most recent versions).   
For MyISAM it is better but I've rarely seen the query cache make any  
difference outside of benchmarks.

MyISAM relies on the OS'es ability to cache files. With Innodb it is  
a bit better, but on current versions of MySQL the buffer pool, which  
you need to really scale, is not really well threaded. This has been  
fixed and there are additional fixes in the 5.1 tree around the  
autoincrement issues that come up with multi-concurrency.

> MyISAM is also faster than InnoDB, if your application logic  
> permits non-transactional DB. MEMORY engine is probably not a good  
> idea since you can loose all your data.

Not really. MyISAM is at the mercy of the file system cache. It can  
sometimes be faster, but a well tuned Innodb is normally faster for  
reads (though not writes...). Write concurrency performance is very  
dependent on tuning and the application design. If all you need is a  
fast writer use Archive :)

If the user has no need for durability, then memory for many  
operations is quite fast. You can do backstore with triggers to  
persistent engines if you need it.


Brian "Krow" Aker, brian at
Seattle, Washington                     <-- Me                <-- Software    <-- Fun
You can't grep a dead tree.

More information about the memcached mailing list