http://dev.mysql.com/doc/refman/5.5/en/innodb-consistent-read.html "Consistent read(即普通select) is the default mode in which InnoDB processes SELECT statements in READ COMMITTED and REPEATABLE READ isolation levels. " " A consistent read does not set any locks on the tables it accesses" 因此另一个事务可以随便改： " and therefore other sessions are free to modify those tables at the same time a consistent read …
本文读者须已经了解mysql的mvcc机制。 假定某行某字段值为100; 以下所有的查询和修改都针对这个字段。 事务甲 事务乙 ——————————————————————————- set commit = 0 set commit = 0 select … (值为100) update … = 200; selet … (值为200, 自已事务下的修改是立即可见的) update … = 300; select … (仍为200, 右边事务未提交，不关我的事) commit; select … ( 如果level=read commited, 值为300, 可以读到其它事务的已提交修改 如果level=read repeatable, 值仍为200, 其他事务即使提交了也不关我的事 ) commit; —- select … (值为300，这个不用解释)
一个事务跨了多个storage engine会怎么样？ 比如表A是innodb, 支持事务; 表B是MyISAM，不支持事务. 会怎么样？ 会出问题。 如果你要rollback这个事务，会导致A中的数据回滚，B中的数据未回滚，导致不一致性。
摘自”High Performance MySQL” storage engine只管storage, 不管query parsing之类的； 不过，它会应optimizer的请求告知自己的能力、执行一些操作的代价以及统计信息。
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 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 …
可以用这个语句确认一下： 引用 show variables like ‘autocommit’
一般来说，会做一个full dump, 然后周期性地进行incremental dump. incremental dump只记录那些改变过的数据。 数据恢复时，将full dump和若干incremental dump依次写回到数据库中。 问题是，在dump过程中数据仍会被改动，这些改动可能不会被记到dump中。要解决这个问题，可以在dump过程中记录undo log或redo log，恢复数据时，搞完dump后，再根据log做数据恢复。 这个log不能跟源数据放在同一个disk里。既然要用archiving机制做数据恢复，就意味着DB已经出现media failure, 如果log跟DB数据放在一起，那log很可能也已经丢了。
undo logging和 redo logging各有优缺点，一个需要频繁flush to disk, 一个需要较大的buffer. 如何同时避免这两种缺点？让buffer manager按最佳性能策略决定何时flush, 而不必考虑log的问题。 办法就是redo log + undo log一起上. 对于每个数据改动，记录 <Transaction T, 数据X, 旧值，新值>. 唯一的约束是，在将数据改动flush至disk之前，保证相应的log entry已经写至disk. 数据恢复时，把commited transaction全部redo一遍，再把incomplete transaction全部undo一遍。
根据redo log或undo log进行数据恢复时，是不是要扫描整个数据文件？ 那未免太重了。 如果我们可以确信在log的某一点之前，数据都是完整的，那么我们就只需要处理这一点之后的log. 这个点就叫做"checkpoint". 在log中定期地生成checkpoint, 进行数据恢复时再找到最后一个checkpoint, 即可像上面所说的那样节省工作量。 以undo logging为例。生成checkpoint的简单办法是： 引用 1. 禁止启动新的transaction 2. 待所有transaction已经commit或abort 3. 将log flush至disk 4. 在log中生成一个<checkpoint>标识并flush至disk 5. 允许新的transaction 当然这种办法过于粗暴，由于禁止新transaction, 它会导致DB一段时间不可用； 有其他的机制如nonquiscent checkpointing, 可以不影响可用性。 具体就不说了。