一、聚集索引介绍

1.什么是聚集索引?

InnoDB’s clustered indexes actually store a B-Tree index and the rows together in the same structure.

2.为什么一张表只能一个聚集索引?

When a table has a clustered index, its rows are actually stored in the index’s leaf pages.The term “clustered” refers to the fact that rows with adjacent key values are stored close to each other.  You can have only one clustered index per table, because you can’t store the rows in two places at once. (However, covering indexes let you emulate mul-
tiple clustered indexes; more on this later.)

3.聚集索引的优点

• You can keep related data close together. For example, when implementing a mailbox, you can cluster by user_id , so you can retrieve all of a single user’s messages by fetching only a few pages from disk. If you didn’t use clustering, each message might require its own disk I/O.
• Data access is fast. A clustered index holds both the index and the data together in one B-Tree, so retrieving rows from a clustered index is normally faster than a comparable lookup in a nonclustered index.
• Queries that use covering indexes can use the primary key values contained at the leaf node.

4.聚集索引的缺点

• Clustering gives the largest improvement for I/O-bound workloads. If the data fits in memory the order in which it’s accessed doesn’t really matter, so clustering doesn’t give much benefit.
• Insert speeds depend heavily on insertion order. Inserting rows in primary key order is the fastest way to load data into an InnoDB table. It might be a good idea to reorganize the table with OPTIMIZE TABLE after loading a lot of data if you didn’t load the rows in primary key order.
• Updating the clustered index columns is expensive, because it forces InnoDB to move each updated row to a new location.
• Tables built upon clustered indexes are subject to page splits when new rows are inserted, or when a row’s primary key is updated such that the row must be moved.A page split happens when a row’s key value dictates that the row must be placed into a page that is full of data. The storage engine must split the page into two to
accommodate the row. Page splits can cause a table to use more space on disk.
• Clustered tables can be slower for full table scans, especially if rows are less densely packed or stored nonsequentially because of page splits.
• Secondary (nonclustered) indexes can be larger than you might expect, because their leaf nodes contain the primary key columns of the referenced rows.

• Secondary index accesses require two index lookups instead of one.

二、聚集索引(用innodb)与非聚集索引(用MyISAM)的区别

表结构

 CREATE TABLE layout_test (
col1 int NOT NULL,
col2 int NOT NULL,
PRIMARY KEY(col1),
KEY(col2)
);

1.MyISAM的结构

In fact, in MyISAM, there is no structural difference between a primary key and any other index. A primary key is simply a unique, nonnullable index named PRIMARY .

2.Innodb的结构

At first glance, that might not look very different from Figure 5-5. But look again, and notice that this illustration shows the whole table, not just the index. Because the clustered index “is” the table in InnoDB, there’s no separate row storage as there is for MyISAM.

Each leaf node in the clustered index contains the primary key value, the transaction ID, and rollback pointer InnoDB uses for transactional and MVCC purposes, and the rest of the columns (in this case, col2 ). If the primary key is on a column prefix, InnoDB includes the full column value with the rest of the columns.

Also in contrast to MyISAM, secondary indexes are very different from clustered indexes in InnoDB. Instead of storing “row pointers,” InnoDB’s secondary index leaf nodes contain the primary key values, which serve as the “pointers” to the rows. This strategy reduces the work needed to maintain secondary indexes when rows move or
when there’s a data page split. Using the row’s primary key values as the pointer makes the index larger, but it means InnoDB can move a row without updating pointers to it.

区别总结:

(1)第一个重大区别是InnoDB的数据文件本身就是索引文件。从上文知道,MyISAM索引文件和数据文件是分离的,索引文件仅保存数据记录的地址。而在InnoDB中,表数据文件本身就是按B+Tree组织的一个索引结构,这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键,因此InnoDB表数据文件本身就是主索引。

(2)第二个与MyISAM索引的不同是InnoDB的辅助索引data域存储相应记录主键的值而不是地址。换句话说,InnoDB的所有辅助索引都引用主键作为data域。所以辅助索引搜索需要检索两遍索引:首先检索辅助索引获得主键,然后用主键到主索引中检索获得记录。

(3)聚集索引一个表只能有一个,而非聚集索引一个表可以存在多个(因为前者的叶子结点就包含数据,而后者是指针)

(4)聚集索引存储记录是物理上连续存在,而非聚集索引是逻辑上的连续,物理存储并不连续(不知道对不对)

三、用聚集索引时,primary key是否连续的影响

1.

Notice that not only does it take longer to insert the rows with the UUID primary key,but the resulting indexes are quite a bit bigger. Some of that is due to the larger primary key, but some of it is undoubtedly due to page splits and resultant fragmentation as well.

2.主键是否连续为什么会有差别?

连续主键的插入

不连续主键的插入

插入不连续主键的缺点:

• The destination page might have been flushed to disk and removed from the caches,or might not have ever been placed into the caches, in which case InnoDB will have to find it and read it from the disk before it can insert the new row. This causes a lot of random I/O.
• When insertions are done out of order, InnoDB has to split pages frequently to make room for new rows. This requires moving around a lot of data, and modifying at least three pages instead of one.
• Pages become sparsely and irregularly filled because of splitting, so the final data is fragmented.

高性能MySQL笔记-第5章Indexing for High Performance-005聚集索引的更多相关文章

  1. 高性能MySQL笔记-第5章Indexing for High Performance-004怎样用索引才高效

    一.怎样用索引才高效 1.隔离索引列 MySQL generally can’t use indexes on columns unless the columns are isolated in t ...

  2. 高性能MySQL笔记-第5章Indexing for High Performance-001B-Tree indexes(B+Tree)

    一. 1.什么是B-Tree indexes? The general idea of a B-Tree is that all the values are stored in order, and ...

  3. 高性能MySQL笔记-第5章Indexing for High Performance-002Hash indexes

    一. 1.什么是hash index A hash index is built on a hash table and is useful only for exact lookups that u ...

  4. 高性能MySQL笔记-第5章Indexing for High Performance-003索引的作用

    一. 1. 1). Indexes reduce the amount of data the server has to examine.2). Indexes help the server av ...

  5. 高性能MySQL笔记 第5章 创建高性能的索引

    索引(index),在MySQL中也被叫做键(key),是存储引擎用于快速找到记录的一种数据结构.索引优化是对查询性能优化最有效的手段.   5.1 索引基础   索引的类型   索引是在存储引擎层而 ...

  6. 高性能MySQL笔记 第6章 查询性能优化

    6.1 为什么查询速度会慢   查询的生命周期大致可按照顺序来看:从客户端,到服务器,然后在服务器上进行解析,生成执行计划,执行,并返回结果给客户端.其中“执行”可以认为是整个生命周期中最重要的阶段. ...

  7. 高性能MySQL笔记 第4章 Schema与数据类型优化

    4.1 选择优化的数据类型   通用原则   更小的通常更好   前提是要确保没有低估需要存储的值范围:因为它占用更少的磁盘.内存.CPU缓存,并且处理时需要的CPU周期也更少.   简单就好   简 ...

  8. 高性能MySQL笔记-第1章MySQL Architecture and History-001

    1.MySQL架构图 2.事务的隔离性 事务的隔离性是specific rules for which changes are and aren’t visible inside and outsid ...

  9. 高性能MySQL笔记-第4章Optimizing Schema and Data Types

    1.Good schema design is pretty universal, but of course MySQL has special implementation details to ...

随机推荐

  1. (转)android头像设置:从本地照片库或拍照获取并剪裁

    本文转载于:http://blog.csdn.net/sheeprunning/article/details/9184021 功能介绍 制作android应用时,用户注册的功能必不可少,往往还需要具 ...

  2. 20180403_调bug_大地保险_jar包冲突

    一.异常现象 他们程序在本地通过java形式直接跑起来的时候,是正常的. 但是测试服务器上,程序跑到一半就不继续往下走了,而且,也不报错,日志里面没有任何信息. 二.异常解决 1.核心思想 抽丝剥茧, ...

  3. storm 学习教程

    转自:http://blog.csdn.net/hrn1216/article/details/51538962 翻译太累了,再也不想去翻译了,真的太累了: 在这个教程中, 你将学到如何创建一个Sto ...

  4. 五、python沉淀之路--字典

    一. 1.根据序列,创建字典,并指定统一的值 v = dict.fromkeys(["],222) print(v) {': 222} 2.根据key 获取值,key不存在时,报错:get方 ...

  5. 基于Python语言使用RabbitMQ消息队列(五)

    Topics 在前面教程中我们改进了日志系统,相比较于使用fanout类型交易所只能傻瓜一样地广播,我们用direct获得了选择性接收日志的能力. 虽然使用direct类型交易所改进了我们的系统,但它 ...

  6. Inception-Resnet-V2

    零.Inception-Resnet-V2的网络模型 整体结构如下,整体设计简洁直观: 其中的stem部分网络结构如下,inception设计,并且conv也使用了7*1+1*7这种优化形式: inc ...

  7. untra edit 自动补全

    选择“高级-配置-编辑器-自动完成”,勾选“自动显示‘自动完成’对话框”,并在其中定义好“当输入x个字符”时,自动补全.

  8. loj 2542 随机游走 —— 最值反演+树上期望DP+fmt

    题目:https://loj.ac/problem/2542 因为走到所有点的期望就是所有点期望的最大值,所以先最值反演一下,问题变成从根走到一个点集任意一点就停止的期望值: 设 \( f[x] \) ...

  9. Azure上批量创建OS Disk大于30G的Linux VM

    Azure上VM的OS盘的大小在创建时是固定的.Windows是127G,Linux是30G.如果需要批量创建的VM的OS Disk有更大的容量.可以考虑用下面的方法实现. 1 创建一台有Data-d ...

  10. (转)AppCan中调用系统浏览器打开网页

    <!DOCTYPE html> <html> <head> <style>body{ background:#fff; font-size:30px;} ...