产品中心
利用索引中的附加列，可以缩小搜索的范围，但使用一个具有两列的索引不同于使用两个单独的索引。
联合索引的结构与电话簿类似，人名由姓和名构成，电话簿首先按姓氏进行排序，然后按名字对有相同姓氏的人进行排序。如果您知道姓，电话簿将非常有用，如果您知道姓和名，电话簿则更为有用，但如果您只知道名不知道姓，电话簿将没有用处。
所以说创建联合索引时，应该仔细考虑列的顺序。对索引中的所有列执行搜索或仅对前几列执行搜索时，联合索引非常有用；仅对后面的任意列执行搜索时，联合索引则没有用处。
多个单列索引在多条件查询时优化器会优先选择最优索引策略，可能只用一个索引，也可能将多个索引全用上。但多个单列索引底层会创建多个B+索引树，比较占用空间，也会浪费一定搜索效率，故如果只有多条件联合查询时最好建联合索引。
顾名思义是最左优先，以最左边的为起点任何连续的索引都能匹配上，如果第一个字段是范围查询需要单独建一个索引，在创建联合索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。这样的话扩展性比较好，比如username经常需要作为查询条件，而age不常使用，则需要把username放在联合索引的第一位置，即最左边。
1、创建复合索引
通常在B+Tree上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。因此可以对B+Tree进行两种查找运算：一种是对于主键的范围查找和分页查找，另一种是从根节点开始，进行随机查找。
可能上面例子中只有22条数据记录，看不出B+Tree的优点，下面做一个推算：
InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT（占用4个字节）或BIGINT（占用8个字节），指针类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储16KB/(8B+8B)=1K个键值（因为是估值，为方便计算，这里的K取值为〖10〗^3）。
也就是说一个深度为3的B+Tree索引可以维护10^3 * 10^3 * 10^3 = 10亿条记录。
实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree的高度一般都在2-4层。MySQL的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要1~3次磁盘I/O操作。
数据库中的B+Tree索引可以分为聚集索引（clustered index）和辅助索引（secondary index）。上面的B+Tree示例图在数据库中的实现即为聚集索引，聚集索引的B+Tree中的叶子节点存放的是整张表的行记录数据。辅助索引与聚集索引的区别在于辅助索引的叶子节点并不包含行记录的全部数据，而是存储相应行数据的聚集索引键，即主键。当通过辅助索引来查询数据时，InnoDB存储引擎会遍历辅助索引找到主键，然后再通过主键在聚集索引中找到完整的行记录数据。
到此这篇关于MySQL单列索引和联合索引的文章就介绍到这了,更多相关MySQL单列索引和联合索引内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
