以下是我发布在我们团队的(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 ·
[…]
Tags:
|
Del.icio.us |
Facebook … |
新功能 问题描述(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/） 解决： …
[获取更多]最近上游发布了MySQL 5.6.26版本，从release note来看，MySQL5.6版本已经相当成熟，fix的bug数越来越少了。本文主要分析releae note上fix的相关bug，去除performance scheama、mac及windows平台、企业版、package相关内容。 InnoDB storage engine 问题描述： 在类unix平台上，当innodb_flush_method设置为O_DIRECT时，函数os_file_create_simple_no_error_handling_func没有使用O_DIRECT方式打开数据文件。例如在函数fil_node_open_file中，可能先以函数os_file_create_simple_no_error_handling_func打开文件，确定文件的大小，然后关闭文件；再以os_file_create打开数据文件，前者使用Buffered IO，后者使用DIRECT IO。这种混合使用可能引发性能问题。 根据man手册建议： Applications should avoid mixing O_DIRECT and normal I/O to the same file, and especially to overlapping byte regions in handles the coherency issues in this situation, overall I/O the …
[获取更多]
最近Percona的研发人员report了一个uk
corruption的bug，这个Bug不同于之前发现的bug（见我的另外一篇博客http://mysqllover.com/?p=1041），而是影响从5.1
到5.8全系列MySQL版本，应该算是设计上的缺陷吧。 创建测试表 CREATE TABLE t1 ( a INT NOT
NULL, b INT NOT NULL, PRIMARY KEY(b), UNIQUE KEY(a))
ENGINE=INNODB; INSERT INTO t1 VALUES (1,1),(2,2); 0.
停止Purge操作：SET GLOBAL innodb_purge_stop_now = ON; 防止标记删除的记录被purge掉
删除表上的数据：DELETE FROM t1; //这时候表上物理记录还存在，只是被标记删除了。 1. SESSION
1: REPLACE INTO t1 VALUES (1,2); 由于有一条标记删除的记录，检查pk上duplicate
key，在聚集索引上加锁：mode=1027 (1024 +3 = LOCK_REC_NOT_GAP | LOCK_X) 堆栈：
row_ins_clust_index_entry […]
Tags:
|
Del.icio.us … |
本文是对Innodb外键实现代码路径的简单记录，对外键实现逻辑熟悉的同学直接忽略吧。。。。。 前言 外键代表两张表之间的引用约束关系：在子表上出现的列记录，必须在父表上已经存在。通过外键，我们可以确保业务上的逻辑一致性，同时还能实现一些级联操作；MySQL目前只有InnoDB引擎支持外键，类似MyISAM、Tokudb等引擎都不支持外键。 InnoDB支持建立多个列的外键，但被外键约束的父表上必须对这些列建立索引，并且子表上的外键列 和父表上索引上的顺序是一致的。默认情况下，当删除父表中被外键约束的记录时，会产生报错，但我们也可以通过在建外键索引时加上ON DELETE CASCADE 来级联的更新子表，更新同理。其他行为包括RESTRICT(限制父表的外键改动，默认值)、CASCADE（跟随父表的改动）、SET NULL(子表对应列设置为NULL)、SET …
[获取更多]本文我们来简单过一下InnoDB的IO子系统相关模块的代码逻辑。主要包括IO读写线程、预读逻辑、InnoDB读写Page以及社区的一些改进。 前言 InnoDB对page的磁盘操作分为读操作和写操作。 对于读操作，在将数据读入磁盘前，总是为其先预先分配好一个block，然后再去磁盘读取一个新的page，在使用这个page之前，还需要检查是否有change buffer项，并根据change buffer，进行数据变更。 读操作分为两种场景：普通的读page及预读操作，前者为同步读，后者为异步读 Page写操作也分为两种，一种是batch write，一种是single page write。写page默认受double write buffer保护，因此对double write buffer的写磁盘为同步写，而对数据文件的写入为异步写。 同步读写操作通常由用户线程来完成，而异步读写操作则需要后台线程的协同。 …
[获取更多]
测试版本：MySQL5.6.23测试表： create table t1 (a int auto_increm …
继续阅读MySQL:
并发replace into的死锁问题分析
Tags:
|
Del.icio.us |
Facebook |
TweetThis |
Digg … |
所谓MRR，简单的说就是当使用二级索引进行检索并且查询的列需要回表时，先根据检索到的PK值进行排序，然后再回表 […]
Tags:
|
Del.icio.us |
Facebook |
TweetThis |
Digg … |
最近在做一个小特性，让InnoDB支持repair table来重建corrupted的索引，本文描述的是实现 […]
Tags:
|
Del.icio.us |
Facebook |
TweetThis |
Digg … |
背景： 当数据库的建库字符集和表不一样时，在库下针对表创建存储过程可能导致全表扫描 如下例： drop dat […]
Tags:
|
Del.icio.us |
Facebook |
TweetThis … |