Download: (svn checkout) http://code.google.com/p/shard-query/source/checkout
Maintainer: Justin Swanhart
More info: http://code.google.com/p/shard-query/
Essential MySQL tool No. 9: mk-archiver
As tables become larger, queries against them can become slower. Many factors influence response times, but if you have optimized everything else and the only remaining suspect is a very large table, then archiving rows from that table can restore fast query-response times.
Unless the table is unimportant, you should not brazenly delete rows. Archiving requires finesse to ensure that data is not lost, that the table isn't excessively locked, and that the archiving process does not overload MySQL or the sever. The goal is an archiving process that is reliable and unnoticeable except for the beneficial effect of reducing query times. mk-archiver achieves all this.
mk-archiver has two fundamental requirements, the first of which is that archivable rows must be identifiable. For example, if the table has a date column and you know that only the last N years of data are needed, then rows with dates older than N years ago can be archived. Moreover, a unique index must exist to help mk-archiver identify archivable rows without scanning the entire table. Scanning a large table is costly, so an index and specific SELECT statements are used to avoid table scans.
In practice, mk-archiver automatically handles the technical details. All you have to do is tell it what table to archive, how to identify archivable rows, and where to archive those rows. These rows can be purged, copied to another table, or written to a dump file for future restoration if needed. Once you're comfortable with the tool, there are many options to fine-tune the archiving process. Also, mk-archiver is pluggable, so it can be used to solve complex archiving needs without patching the code.
Essential MySQL tool No. 10: oak-security-audit
When was the last time you audited the security of your MySQL servers? You're not alone if "never" is the answer. There are many companies that provide security audits, but unless nothing ever changes after those audits, then the security of your MySQL environment should be checked regularly.
External threats are one obvious reason to enforce MySQL security, but internal threats like current or former employees are often more dangerous because they are (or were) trusted. Security is also important for enforcing privacy (medical/HIPAA regulations), preventing accidental access (for example, logging into the production server instead of the development server), or enabling third-party programs to interact with your systems.