One thing that has to be taken into consideration is how MySQL uses buffers for its major storage engines: InnoDB and MyISAM.
What lies cached in memory differs greatly between these storage engines.
InnoDB caches both data and index pages. They are loaded into the InnoDB Buffer Pool, which is sized by innodb_buffer_pool_size.
MyISAM caches only index pages and they are loaded into the Key Cache (Key Buffer), which is sized by key_buffer_size.
You must use information_schema.tables to get the data and index sizes occupied on disk in order to size the InnoDB Buffer Pool and MyISAM Key Cache correctly.
Depending on on how much data you have and how much time you will allow, you can warm the caches as follows:
For every table TableT
- goto to each index NDX
- for each index NDX
- run SELECT every column in NDX,at least one column not indexed in TableT from TableT
By doing this you guarantee that every data and index page gets read at least once. They will sit in the cache. This concept is practiced, in part and in principle, by Percona. Percona built this concept into mk-slave-prefetch. What this program does is
- read relay logs on a slave ahead of the slave processing the SQL in it
- take an SQL statement from the relay log and convert it into a SELECT utilizing the WHERE, GROUP BY, and ORDER BY clauses as a guide to choosing indexes
- execute the SELECT statement that came from converted SQL
This forces the slave to have 99.99% of the data needed by the slave to process the SQL quickly. This also makes the slave prepared in the event you manually failover to the slave and promote it to a master WHOSE CACHES ARE JUST ABOUT THE SAME AS THE MASTER YOU FAILED OVER FROM.
CONCLUSION
Nothing beats having caches ready, willing, and able for you to use in an environment of heavy INSERTS, UPDATEs, and DELETEs.
Give it a Try !!!
CAVEAT
With the birth of products like memcached, some have gotten away from the need to perform proper tuning of MySQL. Granted, many sites benefit from the boost in data retrieval provided by controlling the caching behavior of data as developers have quickly seen with memcached. Many other sites, just by switching storages engines or correctly configuring MySQL, have realized the same performance benefits. Before giving up on the database and strictly using it as a repository, make the most of the your database. Follow through on the due diligence and you might be pleasantly surprised what MySQL will do for you.
Best Answer
The IT shop I work for "bleeds blue" (ie, sticks mostly to IBM tooling), so the performance software we use is IBM's Rational Performance Tester (RPT). IBM's stuff isn't (usually) free or cheap, but RPT has helped us to populate our databases through our applications (mostly because the relationships among the tables is too complex to do nicely via script).
That being said, we are also considering using a tool like the following data-generator, in order to better be able to mass insert data into our database for performance testing.