MySQL InnoDB存储引擎的事务隔离级别
我们知道，在关系数据库标准中有四个事务隔离级别：
- 未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据
- 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别
- 可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读
- 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞
查看InnoDB系统级别的事务隔离级别：
mysql> SELECT @@global.tx_isolation;
+———————–+
| @@global.tx_isolation |
+———————–+
| REPEATABLE-READ |
+———————–+
1 row in set (0.00 sec)
查看InnoDB会话级别的事务隔离级别：
mysql> SELECT @@tx_isolation;
+—————–+
| @@tx_isolation |
+—————–+
| REPEATABLE-READ |
+—————–+
1 row in set (0.00 sec)
修改事务隔离级别：
mysql> set global transaction isolation level read committed;
Query OK, 0 rows affected (0.00 sec)
mysql> set session transaction isolation level read committed;
Query OK, 0 rows affected (0.00 sec)
MySQL InnoDB存储引擎的一些参数
InnoDB做为MySQL目前最广泛的事务存储引擎，很多地方的设计和Oracle都是共通的。对于Oracle DBA来说，学习的时候可以多和Oracle的一些特性进行类比，当然也要明白二者之间的区别。
innodb_additional_mem_pool_size
用于缓存InnoDB数据字典及其他内部结构的内存池大小，类似于Oracle的library cache。这不是一个强制参数，可以被突破。
innodb_buffer_pool_size
内存缓冲池大小，用于缓存表和索引数据等。类似于Oracle的buffer cache，如果可能，尽可能的设置大一点。
innodb_log_buffer_size
日志缓冲区大小，类似于Oracle的log buffer
innodb_log_file_size
日志文件大小。默认会创建2个5M大小的名为ib_logfile0和ib_logfile1的文件。日志文件的数目由参数innodb_log_files_in_group指定。存放位置由innodb_log_group_home_dir指定。
innodb_data_file_path
指定InnoDB表空间数据文件名，大小以及其他属性。所有文件的加起来不能少于10M。多个数据文件之间以逗号分割，属性之间以冒号分割。默认创建一个大小10MB名为ibdata1的可自动扩展的数据文件，一般在生产环境中都需要根据实际情况指定，由于往表空间中添加数据文件需要停机，尽量在规划的时候做好准备，如果可以的话最好开启最后一个数据文件的自动增长属性。数据文件的个数在规划的时候还需要考虑另外一个innodb_open_files参数。
innodb_file_per_table
取值为ON或者OFF。是否为每个table使用单独的数据文件保存。如果系统中表的个数不多，并且没有超大表，使用该参数可以使得各个表之间的维护相对独立，有一定的好处。
innodb_autoextend_increment
当自动扩展表空间被填满之时，每次扩展空间的大小，默认值是8(单位MB)。该参数可以动态修改：
mysql> set global innodb_autoextend_increment=10;
Query OK, 0 rows affected (0.01 sec)
innodb_status_file
定期将show inndb status的结果输出保存到文件中，建议开启以便分析性能。
Sun收购MySQL?
在Planet MySQL上看到大量的文章在讨论Sun收购MySQL的事情，还真是有点吃惊。
Sun这几年市场萎缩得厉害，Solaris操作系统虽然不错，可是主机实在是拖了后腿。Java占据企业开发大半壁江山，可是估计Sun从中赚得不多，至少不如IBM多。记得去年ITPUB香山年会上，Sun全球副总裁王星耀先生的演进《开源与创新》，说Sun在开源社区贡献了最多的代码，却没有得到应有的地位，颇有点怨妇的味道。而从我们买的Sun代理的一个存储设备的情况来看，Sun的服务也确实让人寒心，这样一家公司，自身诸多问题就够让人头痛的了，今天居然花10亿刀收购MySQL，看来确实想在开源和数据库领域重新崛起，只是效果如何，还有待观望。
MySQL这两年的发展势头相当不错，对于Oracle等商业数据库的市场有一定的冲击，所以Oracle为了压制连续收购了其存储引擎InnoDB和Berkeley DB，逼得MySQl不得不从6.0开始开发自己的存储引擎Falcon，应该说打了MySQL一个措手不及。但是MySQL在web2.0公司中是相当受欢迎的，前景看好。这次被Sun收入囊中，还真不知是祸是福呢。淘宝网今年也打算将部分系统迁移到MySQL中，希望MySQL一路走好^_^
顺便提一句，Oracle最终还是宣布收购BEA了，85亿刀，好像比上次传闻的67亿美元贵了不少，NND，看来学BEA耍耍脾气还是必要的。
Sun公司简介
- 成立于1982年，创始人Andreas von Bechtolsheim、Vinod Khosla、Bill Joy和Scott McNealy
- 全球雇员34200人，2007财年营收139亿刀，市值也是139亿刀
- 崛起于web时代，也受创于web泡沫，直到去年才开始再次盈利（换了老大的结果？）
- 2006年之前老大是创始人Scott McNealy，现在则是Jonathan Schwartz（也是一个著名的Blogger，其博客居然还有中文版本的，牛）
- 开源的最大贡献者（王先生在2007年初就这么宣传了），目前开源产品有Open Office、Java (已经基于GPL)、GlassFish和NetBeans
- 企业文化轻松友好，很多雇员可以在家工作
- 公司总部位于加州的Santa Clara，在MySQL北美总部Cupertino的南方
- 公司曾经和现在的雇员为世界奉献了许多天才般的创新
说说MySQL的在线备份
从接触MySQL的那天起，就对MySQL的备份相当头大，不同的引擎有不同的备份方式（InnoDB hot backup, mysqlhotcopy），要么需要加读锁（mysqldump），要么需要额外的硬件成本（mysql replication），不像商业数据库都有统一而成熟的在线备份方案。这可能是开源的一个弱点，想法太多，选择太多，结果就是用户不知所措。当然，对于开源狂热者来说，这也许是开源的魅力和优点所在。
或许是MySQL也越来越商业化的结果，MySQL终于有计划引入新的联机备份机制了。在MySQL6.0中，将实现存储引擎独立的，无需阻塞DML（但还是会阻塞DDL）的online backup API，并且将实现简洁明了的备份恢复语法：
备份：BACKUP DATABASE databasename1, databasename2 TO “filename.backup”;
恢复：RESTORE FROM “filename.backup”;
再结合二进制日志，还能实现联机备份基于时间点的恢复，对于要求高可用的企业级应用来说，这是个好消息。新的存储引擎，新的联机备份方式，MySQL6.0看来值得期待。
