November 2015

procedure analyse() 随手记

Procedure Analyze: http://dev.mysql.com/doc/refman/5.6/en/procedure-analyse.html Procedure Analyze是MySQL提供的一个分析结果集的接口,以帮助提供数据类型优化建议。其语法格式如下: SELECT … FROM … WHERE … PROCEDURE ANALYSE([max_elements,[max_memory]]) max_elements(默认256)表示最多使用这么多个不同的列值来进行分析,是否可以使用ENUM类型,如果有超过这么多个不同的值,enum就不会纳入到考虑中。 max_memory(默认8192),是Analyze()为每个列分配的最大内存,用于尝试找到所有不同的列值。 例如,我们在一个普通的表上执行: mysql> select k from sbtest99 procedure analyse()\G *************************** 1. row *************************** Field_name: sb1.sbtest99.k Min_value: 12992 Max_value: 85008 Min_length: 5 Max_length: 5 Empties_or_zeros: 0 Nulls: 0 Avg_value_or_avg_length: 49996.6047 Std: 43159.4545 Optimal_fieldtype: MEDIUMINT(5) UNSIGNED NOT NULL 1 row in set (0.03 sec) […]

InnoDB 存储引擎系列文章

以下是我发布在我们团队的(Aliyun RDS MySQL 开发组)每月内核月报上关于InnoDB的几篇文章,不断更新中….. 如下是传送门: MySQL · 引擎特性 · InnoDB undo log 漫游 MySQL · 引擎特性 · InnoDB redo log漫游 MySQL · 引擎特性 · InnoDB 崩溃恢复过程 MySQL · 引擎特性 · Innodb change buffer介绍 MySQL · 引擎特性 · InnoDB Adaptive hash index介绍 MySQL · 引擎特性 · InnoDB 全文索引简介 MySQL · 引擎特性 · InnoDB 事务子系统介绍 MySQL · […]

MySQL5.6.27 Release Note解读(innodb及复制模块)

新功能 问题描述(Bug #18871046, Bug #72811): 主要为了解决一个比较“古老”的MySQL在NUMA架构下的“swap insanity”问题,其表现为尽管为InnoDB buffer pool分配了足够多的内存,但依然会产生swap。而swap对数据库系统性能而言是比较致命的。 当我们配置的buffer pool超过单个node的内存时,例如总共64GB内存,每个节点32GB,分配buffer pool为40GB,默认情况下,会先用满node 0,再在node1上分配8GB内存。如果绑定到node 0上的线程需要申请新的内存时,不是从node1上申请(还有24GB空余),而是swap node0的内存,再做申请。 这个问题在社区讨论了很久,大神Jeremy Cole 对该问题有写博客做过详细的介绍(http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/) 解决: 增加了一个只读的新参数innodb_numa_interleave选项,当开启该选项,可以允许在NUMA架构下采取交叉分配内存的方式。 在启动MySQL时,采用MPOL_INTERLEAVE方式分配内存,如上例,在启动时每个node上分配20GB内存,保证每个node依然有空闲内存可用;在完成InnoDB buffer pool内存分配后,再将内存分配策略设置为MPOL_DEFAULT,之后的线程申请内存,都在各自的节点完成。 补丁: https://github.com/mysql/mysql-server/commit/242fa2c92de304637e794e531df1f1b86b8d1dee https://github.com/mysql/mysql-server/commit/d2578b57ba7d90a00281ae124a1cd6c83193f62a InnoDB bugfix 问题描述: 当一个表被驱逐并重新导入时,如果表的内容是空的(例如先插入大量数据,再一次全删除时,auto_increment不为0),就会导致AUTO_INCREMENT的值被重置。(Bug #21454472, Bug #77743) 这是因为每次打开表时,总是通过计算表上记录最大自增列值的方式来重新设置,当表被打开时,如果没有数据,AUTO_INCREMENT就会被重置成最小值。 解决: 在驱逐表时,将这个表的AUTO_INCREMENT值存储在内存中(dict_sys->autoinc_map),当表重新读入时,再恢复其AUTO_INCREMENT值。 这个Fix并不算一个完整的修复,当实例重启时,AUTO_INCREMENT依然会被重置(参阅bug#199), RDS MYSQ已经Fix了这个bug,能够持久化自增列到物理文件中,在重启后不会丢失。 补丁: https://github.com/mysql/mysql-server/commit/d404923aad4693dc152d02461f858d7ef218c336 问题描述: Memcached的一段开启事务的代码在assert中调用,而根据assert的文档定义( http://man7.org/linux/man-pages/man3/assert.3.html ),他的行为是未知的,受NDEBUG控制,可能assert会被定义成空函数,导致assert中的函数调用被忽略掉。这个bug在某些平台下可能极易触发。使用memcached的同学需要注意下。 (Bug #21239299, Bug #75199) 解决: 将函数调用从assert中移出来,只assert函数返回值。 补丁: https://github.com/mysql/mysql-server/commit/db5dc6fd3abe855685a554bc3c555b1b63914b60 问题描述: 在ARM64平台上, GCC的内建的TAS操作函数__sync_lock_test_and_set 可能不准确,这和平台内存模型有关,锁的行为错误,导致进一步的数据损坏。(Bug […]