本篇文章主要介绍了"索引原理与表设计"，主要涉及到方面的内容，对于其他数据库感兴趣的同学可以参考一下：
作者：黄湘龙架构师交流群(312254004)欢迎非商业转载，商业使用请联系我索引是有效使用数据库的基础，但你的数据量很小的时候，或许通过扫描整表来存取数据的性...
# Filesort: No Filesort_on_disk: No Merge_passes: 0
# InnoDB_IO_r_ops: 0 InnoDB_IO_r_bytes: 0 InnoDB_IO_r_wait: 0.000000
# InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000
# InnoDB_pages_distinct: 2
SET timestamp=1451104535;
select * from UP_User where userId = 10000094;
我们可以看到，数据库读从磁盘取了两个Page就把809Bytes的数据提取出来返回给客户端。
下面我们试一下，如果试一下选取条件没有包含主键和索引的情况：
select * from `UP_User` where bigPortrait = '5F29E883BFA8903B';
# Query_time: 0.002869 Lock_time: 0.000094 Rows_sent: 1 Rows_examined: 1816 Rows_affected: 0
# Bytes_sent: 792 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: No Tmp_table_on_disk: No
# InnoDB_pages_distinct: 25
可以看到如果使用主键作为检索条件，检索时间花了0.3ms，只读取了两个Page，而不使用主键作为检索条件，检索时间花了2.8ms，读取了25个Page，全局扫描才把这条记录给找出来。这还是一个只有1000多行的表，如果更大的数据量，对比更加强烈。
对于这两个Page，一个是主键B+Tree的数据，一个是10000094这条数据所在的数据页。
2.2普通索引
我们用普通索引作为检索条件来搜索数据需要检索两遍索引：首先检索普通索引获得主键，然后用主键到主索引中检索获得记录。如上图红色线条的流向。
下面我用一个例子来看看数据库的表现：
select * from UP_User where userName = 'fred';
# Query_time: 0.000400 Lock_time: 0.000101 Rows_sent: 1 Rows_examined: 1 Rows_affected: 0
# Bytes_sent: 803 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# QC_Hit: No Full_scan: No Full_join: No Tmp_table: No Tmp_table_on_disk: No
# InnoDB_pages_distinct: 4
我们可以看到数据库用了0.4ms来检索这条数据，读取了4个page，比用主键作为检索条件多用了0.1ms，多读取了两个Page，而这两个Page就是userName这个普通索引的B+Tree所在的数据页。
2.3复合索引
聚集索引和普通索引都有可能由多个字段组成，多个字段组成的索引的叶节点的Key由多个字段的值按照顺序拼接而成。这种索引的存储结构是这样的，首先按照第一个字段建立一棵B+Tree，叶节点的Key是第一个字段的值，叶节点的value又是一棵小的B+Tree，逐级递减。对于这样的索引，用排在第一的字段作为检索条件才有效提高检索效率。排在后面的字段只能在排在他前面的字段都在检索条件中的时候才能起辅助效果。下面我们用例子来说明这种情况。
我们在UP_User表上建立一个用来测试的复合索引，建立在 (`nickname`,`regTime`)两个字段上，下面我们测试下检索性能：
