[MySQL5.6] MySQL5.6.16的主要修改

春节期间Oracle relase了最新的MySQL社区版本MySQL5.6.16,总的来说,和上个版本类似,包含的基本上是一些Bugfix;下面列出一些比较有意思的bug及对应的Rev连接
 
 
Innodb
 
1.首先要提的是Percona的哥们提的bug#68079,在一台多核机器上,执行只读join操作,在并发线程数还没到达CPU CORE数时,就发生了性能下降,有兴趣的同学可以阅读下这个bug report,比较长,信息量还是蛮大的。Oracle针对其中一个问题(即block->mutex 等待时间较高)将所有对buf_fix_count修改成gcc buidin的原子操作,以减少block mutex的开销;代码的修改主要在Rev:5677 , Rev:5685, 对于访问比较随机的负载,这个改进可能没有明显效果;
——很快Inaam又据此提出一个新的bug:http://bugs.mysql.com/bug.php?id=71727
 
2.之前通过创建/删除特定Monitor表的方式,innodb会去自动输出内部信息,现在可以通过新的变量 innodb_status_output和 innodb_status_output_locks  来控制
 
3.bug#70087是一个值得关注的bug,根据Bug描述,如果是第一个page corruption了,可能无法从double write buffer中恢复,这是因为
在crash recovery时,是先调用的recv_init_crash_recovery->fil_load_single_table_tablespaces, 这里可能需要打开ibd文件的第一个page,在完成recv_init_crash_recovery后才会去扫描double write buffer;
为什么要先读第一个page呢? 官方给出的解释是由于double write buffer中的page包含了space id,我们还需要扫描data目录下的所有ibd,读取ibd的第一个page,以确定dbwrite buffer中的page归属。
Patch见Rev:5703  ,在函数recv_init_crash_recovery中,确保先调用buf_dblwr_init_or_load_pages , 将page先load到recv_sys->dblwr中,再调用fil_load_single_table_tablespaces读入第一个page(或者多个page,来确认该ibd的space id,并使用刚刚读取到的double write buffer来恢复page 0),如果有corruption的page,随后调用buf_dblwr_process来进行恢复。
 
4.几个小的性能优化点:
Percona的Laurynas在bug#70417指出在函数rw_lock_x_lock_func_nowait中,只有当获取锁失败时,才需要去读取当前线程id (Rev:5655
bug#70768描述了这样一种情况:state线程持有表的stats_latch做磁盘读; 某个用户线程持有LOCK_open尝试获取stats_latch,其他线程拿不到LOCK_open被完全阻塞住, bugfix见Rev://5682 ,不过laurynas又提出了该fix引入的倒退:http://bugs.mysql.com/bug.php?id=71708
5.在创建事务时,没有初始化事务的开始时间,导致active时间错误(bug#69438Rev:5679)
 
 
Server层
 
1. FORCE INDEX [FOR ORDER BY] (index_name) 无法用于join操作(Rev:5691);
2.  UNIX_TIMESTAMP()可能返回NULL(应该返回0)(Rev:5649);
3. filesort操作可能由内存问题导致crash(Rev:5637); 
4. Index merge使用的cache只有成功获得所有行记录后才释放,中断或失败会导致文件描述符leak(Rev:5635);
5.创建试图view导致server crash(Rev:5639); 
6. JOIN_BUFFER_SIZE大于4G时,某些情况下会导致crash或不正确的结果(Rev:5686); 
7. Rev:5636 fix了一个semi-join场景下的crash bug; 
8. Rev:5595:优化器把固定长度myisam临时表写入磁盘(而不是可变长度。。。没看明白,TODO);
9.utf8_bin的字符集在order by时可能产生不正确的顺序(Rev:5598); 
10.执行COUNT(DISTINCT)时可能产生不正确的数据结果(MySQL5.5,  bug#71028,  Rev:4557);
11.在子查询中使用IF()函数联合OUTER JOIN,转换成semi-join后,可能产生错误的数据,test case见bug#70608, Patch见Rev:5681
 
DDL
 
1. 假如表之前是在5.5创建的,随后in-place升级到5.6,如果增加了新的列,还是按照5.5的格式存储(典型的是datetime类型),现在对于特定的DDL操作(见 Rev:5625),旧的列格式将升级到5.6的存储形式;
2.在ALTER TABLE之后随后调用RENAME TABLE 可能导致无法做crash recovery  (Rev:5656); 
3. ALTER TABLE操作无法重置auto_increment(bug#69882Rev:5593); 
4.在同一条SQL中ALTER TABLE…ADD/DROP/RENAME COLUMN可能导致错误(Rev:5654); 
5. ONLINE DDL消耗内存过多的问题,在有大量分区表的时候比较突出(bug#69325, Rev:5702
 
Memcached plugin相关bug
早期的memcached plugin存在很多bug,但很高兴的看到其仍然在不断修复中,例如最近fb的yafusumi提的一个bug#70172, 指出在每次GET操作时都会去调用trx_create和trx_free,大家都知道MySQL的事务创建开销是很大的,Rev:5532 fix了这个问题,相信会带来比较明显的性能提升;Rev:5632 和 Rev:5725 fix了两个内存问题;Rev:5634  fix了truncate操作导致的实例crash.
 
 
全文索引
 
从change log来看,和全文索引相关的bug都属于比较严重的,大多会导致实例crash,这部分没玩过,先记录下,感觉Innodb全文索引似乎还不太稳定。。。。
Rev:5714Rev:5642, Rev:5614(discard tablespace 导致的crash) 
Rev:5708(WHERE字句存在衍生表,例如子查询,导致查询全文索引表crash)
 
 
 
分区表
 
关于分区表,fix了两个bug,一个和优化器index_merge相关,可能导致数据错误(bug#70588Rev:5592); 另外一个则会导致实例crash(Rev:5640
 
 
复制
 
1.当写入的事务binlog大小正好为32768字节时,可能会导致写入corruption,理论上概率很低,主要是io cache的临界点没处理好,具体可以看bzr log(Rev:5721); 
2.大量创建/删除临时表导致大量的内存占用(Rev:5646),但看日志,跟change log描述有出入,需要仔细看看
 
 
Performance Schema
 
1. Rev:5648 fix了一个并发访问PS表可能导致crash的bug;
2.包含复杂语句,例如JOIN或者子查询的UPDATE,在更新PS表时,可能无法更新全部行(bug#70025Rev:5647

原创文章,转载请注明: 转载自Simple Life

本文链接地址: [MySQL5.6] MySQL5.6.16的主要修改

Post Footer automatically generated by wp-posturl plugin for wordpress.


Comments

Leave a Reply

Your email address will not be published. Name and email are required


Current month ye@r day *