Innodb parent table open时导致crash

case描述：

　　innodb中，父表和子表通过foreign constraint进行关联，因为在更新数据时需要check 外键constraint，如果父表被大量的子表reference，
那么在open的时候，需要open所有的child table和所有的foreign constraint，导致时间过长，产生long semaphore wait 。

分析过程：

　　case 用例：

CREATE TABLE `t1` (

  `f1` int() NOT NULL,

  PRIMARY KEY (`f1`)

) ENGINE=InnoDB

 CREATE TABLE `fk_1` (

  `f1` int() NOT NULL,

  PRIMARY KEY (`f1`),

  CONSTRAINT `pc1` FOREIGN KEY (`f1`) REFERENCES `t1` (`f1`) ON DELETE CASCADE ON UPDATE CASCADE

) ENGINE=InnoDB

......

这里建了fk_[-]张表。

1. 背景：innodb数据字典

　　innodb使用系统表空间保存表相关的数据字典，系统的数据字典包括：

SYS_TABLES
SYS_INDEXES
SYS_COLUMNS
SYS_FIELDS
SYS_FOREIGN
SYS_FOREIGN_COLS
SYS_STATS

　　在load某个表的时候，分别从这些表中把表相关的index,column, index_field, foreign, foreign_col数据保存到dictionary cache中。
对应的内存对象分别是：dict_col_struct，dict_field_struct，dict_index_struct，dict_table_struct，dict_foreign_struct。
这些对象全局唯一，在dictionary cache只保留一份，并使用dict_sys->mutex进行同步保护，所有open的handler引用到这些对象上。

注意：系统的数据字典同样是innodb的聚簇索引表，并受redo保护。

2. open过程

入口函数ha_innobase::open()
dict_load_table：

1. 通过sys_tables系统表，load table相关的定义
2. 通过sys_indexes系统表，根据table_id load 所有相关index
3. 通过sys_columns系统表，根据table_id load 所有的columns
4. 通过sys_fields系统表，根据index_id load 所有index的field
5. 通过sys_foreign系统表，load所有关联的表和foreign key

在load这些定义的时候，过程都是：
　　1. 通过某个字段，查找系统字典表
　　2. 根据查询的记录建立内存对象，并加入到全局cache中

但在load foreign的时候，会有一些不同，因为foreign key于两张表相关联。下面详细介绍下load foreign的过程。

3. load foreign的详细过程

　　如下图所示foreign的关联关系：

load的步骤：

3.1: 根据表名t1 查找sys_foreign. 而sys_foreign表上一共有三个索引：　　　　

　　　　index_1(id): cluster_index
　　　　index_2(for_name): secondary_index
　　　　index_3(ref_name): secondary_index

所以，根据for_name='t1', ref_name='t1'检索出来所有相关的foreign_id.

3.2: 根据3.1检索出来的foreign_id, load foreign对象，并打开相关fk_[1-10000]表。

3.3: 加入cache

　　因为没有专门的cache，foreign分别加入到for_name->foreign_list, ref_name->refence_list
问题的关键：因为foreign是全局唯一的，但foreign又与两个表关联，所以，有可能在open 其它表的时候
已经打开过，所以，create foreign对象后，需要判断以下四个list，是否已经存在，如果存在就直接使用。

dict_foreign_find：分别查询这四个list，如果已经存在，则free新建的foreign对象，引用已经存在的。
　　　　for_name->foreign_list
　　　　for_name->refence_list
　　　　ref_name->foreign_list
　　　　ref_name->refence_list

如果不存在，把新建的foreign加入到for_name->foreign_list，ref_name->refence_list链表中。

4. 问题的原因：

　　因为第一次load，所以find都没有找到，但这四个都是list，随着open的越来越多，检索的代价越来越大。
而整个过程中，都一直持有trx_sys->mutex，最终导致了long semaphore wait。

5. 问题改进方法：

　　在MySQL 5.5.39版本中，进行了修复，修复的方法就是，除了foreign_list，referenced_list。
另外又增加了两个red_black tree，如下源码所示：

struct dict_table_struct{

table_id_t    id;    　　/*!< id of the table */

mem_heap_t*    heap;    /*!< memory heap */

char*    name;    　　　　/*!< table name */

UT_LIST_BASE_NODE_T(dict_foreign_t)

foreign_list;　　　　　　　　　　/*!< list of foreign key constraints in the table; these refer to columns in other tables */

UT_LIST_BASE_NODE_T(dict_foreign_t)

referenced_list;/*!< list of foreign key constraints which refer to this table */

ib_rbt_t*    foreign_rbt;    /*!< a rb-tree of all foreign keys listed in foreign_list, sorted by foreign->id */

ib_rbt_t*    referenced_rbt;    /*!< a rb-tree of all foreign keys listed in referenced_list, sorted by foreign->id */

在初始化list的时候，初始化一份red_black tree. 在dict_foreign_find的过程中，直接查找rbt，这样查询的代价大大降低。