Month: September 2014

mysql 在线alter table要小心

mysql 5.6之前, alter table操作对可用性有巨大的冲击(除了纯改表名、不影响任何数据的alter table)。它的原理是, 0. alter table语句开始 1. 等待当前所有操作结束 2. 施加shared table lock,  能读不能写 3. 创建临时表,执行table alteration并将所有数据复制到临时表中 4. 抛弃旧表并把新表改名,完成操作; 在这个点上会对表施加exclusive table lock, 也就是说连读都不行了。 如果表很大,这个过程会导致比较严重的不可用(分钟级或以上).  在5.6之前,有一个针对innodb index的优化:MySQL 5.5, and MySQL 5.1 with the InnoDB Plugin, optimized CREATE INDEX and DROP INDEX to avoid the table-copying behavior 到5.6时,innodb上了一个特性叫做"online ddl", 对于很多alter table操作,可以避免表复制、或/和  dml blocking等。 具体避免哪些,要看具体使用的是哪种alter table操作。请参见: http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html …

mysql 在线alter table要小心 Read More »

mysql: row-level locking 的overhead 更大,兼论myisam的适用场景

row-level locking 的overhead 比table-level locking的overhead更大:  更慢,需要消耗更多内存。 至于为什么?我没读过源码,在网上也没搜到具体的原因。只看到一句勉强可以接受的解释:Row locking is more complex than table locking, and so it’s slower and takes more memory. 不管为什么,这个结论让人有点吃惊,对不对? 另外要注意的是,myisam中shared table lock并不会阻止对表的插入操作,一边读一边插入,MyISAM还是挺快的。 结合以上两点:1.table lock更轻; 2. table lock不阻止插入,如果你的业务不需要事务,又以insert和select为主的话,那么MyISAM是比InnoDB更好的选择。

mysql逻辑架构图

摘自”High Performance MySQL” storage engine只管storage, 不管query parsing之类的; 不过,它会应optimizer的请求告知自己的能力、执行一些操作的代价以及统计信息。