Mark Callaghan discusses the implications of using FLUSH TABLES WITH READ LOCK and what this command actually does.

"There's a change of behaviour in MySQL 5.1.31 for Row Based Replication, if you have InnoDB transactions that also write to a MyISAM (or other non-transactional engine) table." "the moral of the story. Don't use non-transactional tables in the middle of a transaction. Ever. You will only cause yourself more pain than you can possibly imagine. Instead, move the writes to the non-transactional tables outside of the transaction."

So, how does one gather statistics on indexes? With InnoDB it's one thing, with MyISAM it's another thing. This post however, will focus on MyISAM. There are various ways, each having their own drawbacks and positive sides.What about "ANALYZE TABLE"? It's great -- very fast in InnoDB. But with MyISAM a lock occurs while scanning the table. "OPTIMIZE TABLE"? Still relatively quick with MyISAM, unless the table in question is huge. InnoDB requires an "ALTER TABLE" -- it might take forever, depending on the server configuration, as "OPTIMIZE TABLE" for InnoDB maps to a "ALTER TABLE tableName ENGINE=InnoDB"We all know how "ANALYZE TABLE", "REPAIR TABLE", and "OPTIMIZE TABLE" work with MyISAM. However, there's a less explored way, for MyISAM -- the "myisam_stats_method".

Or, There is a Use for GUI Tools!Recently I was working on a problem for a customer. They are converting a server with two InnoDB data files to "innodb_file_per_table":$ ls -l ibdata*-rwxr-xr-x   1 mysql    mysql       2.0G Oct 14 13:10 ibdata1-rwxr-xr-x   1 mysql    mysql       350G Oct 14 13:10 ibdata2I honestly don't recall ever seeing (or hearing about) so large a data file.The method chosen for conversion boils down to this:\tstop and start the server to enable "innodb_file_per_table"\talter all tables to myisam\tstop server and delete ibdata file\trestart server\tconvert tables back to InnoDB\tadd foreign keysThis post isn't about how we did it, or about whether or not it was the best way, or anything like that. This post is really about the the last two steps.There were over 500 InnoDB tables and something like 375 foreign keys. So I needed to somehow create the "ALTER TABLE" statements for  []

MySQL Full Text Search LimitationsSuppose you have a MyISAM table containing a column with a full text index. This table starts to grow to a significant size (millions of rows) and gets updated fairly frequently. Chances are that you'll start to see some bottlenecks when accessing this table, since without row level locking, the reading and writing operations will be blocking each other.A solution that many people would suggest right away is to use the master for writes and a slave for reads, but this only masks the problem, and it won't take long before enough read traffic on the slave starts causing slave lags.Why Sphinx?

It felt like the right time for us to look back at some useful commands for table maintenance that some of us may not have mastered as much as we might like to think.In my post about gathering index statistics, I referred to "OPTIMIZE TABLE", "ANALYZE TABLE", and "REPAIR TABLE" -- but I never explained in depth what the different commands do, and what the differences between them are. That is what I thought I would do with this post, focusing on InnoDB and MyISAM, and the differences in how they treat those commands. I will also look at different cases and see which one is right for in each case.

An example showing how to use Sphinx when MySQL Full Text Search limitations show up.