最近一个日常实例在做DDL过程中，直接把数据库给干趴下了，问题还是比较严重的，于是赶紧排查问题，撸了下crash堆栈和alert日志，发现是在去除唯一约束的场景下，MyRocks存在一个严重的bug，于是紧急向官方提了一个bug。其实问题比较隐蔽，因为直接一条DDL语句，数据库是不会挂了，而是在特定情况下，并且对同一个索引操作多次才会发生，因此排查问题也费了一些时间，具体bug排查和复现过程不在此展开，有兴趣的童鞋可以直接看bug链接：https://github.com/facebook/mysql-5.6/issues/602。借着排查问题的机会，我梳理了MyRocks DDL的工作流程，下文主要包括3方面内容：MyRocks数据字典，DDL操作除了修改数据本身，很重要的一个工作是维护数据字典，第二部分是MyRocks DDL的流程，主要围绕增加/删除索引的场景展开，最后一部分是分析DDL异常处理逻辑。
数据字典
所谓数据字典，就是存储引擎元数据的地方。数据字典可以从两个维度来看，从用户角度来看，数据字典就是information_schema表中的
RocksDB相关的表，主要包括ROCKSDB_DDL，ROCKSDB_INDEX_FILE_MAP等。而从RockDB内部实现角度来看，所有元数据都以KV对的方式存储在system column family中。我们看到的information_schema中表的信息，其实都是通过system column family中的元数据构造出来的，同时在mysqld启动时，也会构造一份元数据存储在内存中，方便快速检索查询。下面我会列出RocksDB数据字典的几种类型，并列出每种类型KV对的形式。
// Data dictionary types
1). DDL_ENTRY_INDEX_START_NUMBER
表和索引之间的映射关系
key: Rdb_key_def::DDL_ENTRY_INDEX_START_NUMBER(0x1) + dbname.tablename
value: version + {global_index_id}*n_indexes_of_the_table
2). INDEX_INFO
索引id和索引属性的关系
key: Rdb_key_def::INDEX_INFO(0x2) + global_index_id
value: version, index_type, key_value_format_version
index_type:主键/二级索引/隐式主键
key_value_format_version: 记录存储格式的版本