优化 | InnoDB表一定要用自增列做主键
2017-04-10 23:04
169 查看
0、导读
明白InnoDB表一定要用自增列做主键的理由我们先了解下InnoDB引擎表的一些关键特征:
InnoDB引擎表是基于B+树的索引组织表(IOT);
每个表都需要有一个聚集索引(clustered index);
所有的行记录都存储在B+树的叶子节点(leaf pages of the tree);
基于聚集索引的增、删、改、查的效率相对是最高的;
如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择其作为聚集索引;
如果没有显式定义主键,则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引;
如果也没有这样的唯一索引,则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增,这个ROWID不像ORACLE的ROWID那样可引用,是隐含的)。
综上总结,如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话,这时候存取效率是最高的,也就是下面这几种情况的存取效率最高:
使用自增列(INT/BIGINT类型)做主键,这时候写入顺序是自增的,和B+数叶子节点分裂顺序一致;
该表不指定自增列做主键,同时也没有可以被选为主键的唯一索引(上面的条件),这时候InnoDB会选择内置的ROWID作为主键,写入顺序和ROWID增长顺序一致;
除此以外,如果一个InnoDB表没有显式主键,但有可以被选择为主键的唯一索引,且该唯一索引可能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况),该表的存取效率就会特别差。
实际情况是如何呢?经过简单TPCC基准测试,修改为使用自增列作为主键与原始表结构分别进行TPCC测试,前者的TpmC结果比后者高9%倍,足见使用自增列做InnoDB表主键的明显好处,其他更多不同场景下使用自增列的性能提升可以自行对比测试下。
附图:
1、B+树典型结构
2、InnoDB主键逻辑结构
延伸阅读:
1、TPCC-MySQL使用手册
2、B+Tree
index structures in InnoDB
3、B+Tree
Indexes and InnoDB – Percona
4、MySQL官方手册: Clustered
and Secondary Indexes
老叶茶馆镇店之宝,扫码识别或访问 http://yejinrong.com 直达
相关文章推荐
- 优化 | InnoDB表一定要用自增列做主键
- [MySQL优化案例]系列 -- InnoDB主键设计
- InnoDB的主键选择与插入优化
- 面试宝典系列-InnoDB的主键选择与优化
- MySQL MyISAM/InnoDB高并发优化经验
- MySQL innoDB数据插入性能优化
- mysql联表查询优化(以下查询方法可借鉴,但一定要按自己的业务来进行相对应的优化)
- MySQL存储引擎MyISAM和InnoDB的区别及mysql优化
- InnoDB优化
- MySQL MyISAM/InnoDB高并发优化经验
- MySQL中select * for update锁表的问题 由于InnoDB预设是Row-Level Lock,所以只有「明确」的指定主键,MySQL才会执行Row lock (只锁住被选取的资料例
- InnoDB 存储引擎的特点及优化方法
- SQL数据库管理系统的优化方案(表的主键、外键、索引设计)
- Mysql Innodb 引擎优化 参数(innodb_buffer_pool_size)
- innodb使用大字段text,blob的一些优化建议
- Mysql5.5数据库的MyISAM和InnoDB引擎配置优化
- 【mysql优化】mysql count(*)、count(1)、count(主键字段)、count(非主键字段)哪个性能最佳
- 【优化】COUNT(1)、COUNT(*)、COUNT(常量)、COUNT(主键)、COUNT(ROWID)、COUNT(非空列)、COUNT(允许为空列)、COUNT(DISTINCT 列名)
- mysql-innodb引擎优化建议
- 不能使用UUID做MySQL innodb主键索引