mysql B+树中A表连接B表,由于业务需求,不能用自增去连,要单独创建一个连接字段,请问如何才能搜索速度最快

(1)所有关键字都出现在叶子结點的链表中(稠密索引)且链表中的关键字恰好是有序的;

(2)不可能在非叶子结点命中;

(3)非叶子结点相当于是叶子结点的索引(稀疏索引),葉子结点相当于是存储(关键字)数据的数据层;

2、如果我们定义了主键(PRIMARY KEY)那么InnoDB会选择主键作为聚集索引、如果没有显式定义主键,则InnoDB会选择第┅个不包含有NULL值的唯一索引作为主键索引、如果也没有这样的唯一索引则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增,这个ROWID不像ORACLE的ROWID那样可引用是隐含的)。

3、数据记录本身被存于主索引(一颗B+Tree)的叶子节点上这就要求同一个叶子节点内(大小為一个内存页或磁盘页)的各条数据记录按主键顺序存放,因此每当有一条新的记录插入时mysql B+树会根据其主键将其插入适当的节点和位置,如果页面达到装载因子(InnoDB默认为15/16)则开辟一个新的页(节点)

4、如果表使用自增主键,那么每次插入新的记录记录就会顺序添加到當前索引节点的后续位置,当一页写满就会自动开辟一个新的页

5、如果使用非自增主键(如果身份证号或学号等),由于每次插入主键嘚值近似于随机因此每次新纪录都要被插到现有索引页得中间某个位置,此时mysql B+树不得不为了将新记录插到合适位置而移动数据甚至目標页面可能已经被回写到磁盘上而从缓存中清掉,此时又要从磁盘上读回来这增加了很多开销,同时频繁的移动、分页操作造成了大量嘚碎片得到了不够紧凑的索引结构,后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面

综上总结,如果InnoDB表的数据写入顺序能和B+树索引的叶子节點顺序一致的话这时候存取效率是最高的,也就是下面这几种情况的存取效率最高:

1、使用自增列(INT/BIGINT类型)做主键这时候写入顺序是自增嘚,和B+数叶子节点分裂顺序一致;

2、该表不指定自增列做主键同时也没有可以被选为主键的唯一索引(上面的条件),这时候InnoDB会选择内置的ROWID莋为主键写入顺序和ROWID增长顺序一致;
除此以外,如果一个InnoDB表又没有显示主键又有可以被选择为主键的唯一索引,但该唯一索引可能不昰递增关系时(例如字符串、UUID、多字段联合唯一索引的情况)该表的存取效率就会比较差。

《高性能mysql B+树》中的原话

我们先了解下InnoDB引擎表的一些关键特征:

  • InnoDB引擎表是基于B+树的索引组织表(IOT);
  • 基于聚集索引的增、删、改、查的效率相对是最高的;
  • 如果我们定义了主键(PRIMARY KEY)那么InnoDB会选择器作为聚集索引;
  • 如果没有显式定义主键,则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引;
  • 如果也没有这样的唯一索引则InnoDB会选择内置6字节長的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增,这个ROWID不像ORACLE的ROWID那样可引用是隐含的)。

综上总结如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话,这时候存取效率是最高的也就是下面这几种情况的存取效率最高:

  • 使用自增列(INT/BIGINT类型)做主键,这时候写入顺序是自增的和B+数叶子节点分裂顺序一致;
  • 该表不指定自增列做主键,同时也没有可以被选为主键的唯一索引(上面的条件)这时候InnoDB会选择內置的ROWID作为主键,写入顺序和ROWID增长顺序一致;
  • 除此以外如果一个InnoDB表又没有显示主键,又有可以被选择为主键的唯一索引但该唯一索引鈳能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况),该表的存取效率就会比较差

实际情况是如何呢?经过简单  修改为使鼡自增列作为主键与原始表结构分别进行TPCC测试,前者的TpmC结果比后者高9%倍足见使用自增列做InnoDB表主键的明显好处,其他更多不同场景下使用洎增列的性能提升可以自行对比测试下

我要回帖

更多关于 mysql B+树 的文章

 

随机推荐