聚簇索引

文章目录 mysql——B+树索引 何谓索引 索引类型 聚簇索引 非聚簇索引 创建索引 创建语句 创建原则 索引覆盖 最左前缀原则 索引失效 不使用索引 参考资料 mysql——B+树索引 何谓索引 索引是一种高效的数据结构，可以帮助数据库快速搜索数据，给某个字段建立索引，就会生成一棵以该字段排序的B+树，如果你不懂B+树，可以想一想为什么排序后二分查找会这么快。索引也不可以过度使用，否则会消耗很多磁盘空间，并且DML操作的时候维护索引也会很消耗性能。 索引类型 聚簇索引 聚簇索引又叫聚集索引或主键索引 聚簇索引有以下两个特点： 特点1： 按主键值的大小进行记录和页的排序，数据页(叶子节点)之间是按照主键值从小到大排序的一个双向链表 特点2： B+树的叶子节点存储的是完整的用户记录，就是指这个记录中存储了所有列的值（包括隐藏列） InnoDB存储引擎会自动的为我们主键创建聚簇索引，因此只有在搜索添加是主键才能发挥作用 非聚簇索引 别名非聚集索引，二级索引，复制索引，辅助索引。 非聚簇索引按照指定的索引列排序生成B+树，并且叶子节点只存储了索引列的值和主键值，这肯定是为了节省磁盘空间，这使得我们非聚集索引查询时候只能查到主键值，如果你需要记录中除了索引列的其他列的数据，只能通过查到的主键再走一遍聚集索引，这叫做 回表 非聚簇索引又有 唯一索引，联合索引，前缀索引 唯一索引

索引 理解索引 前缀索引 索引关键字是表中关键字值的一部分 可以是字段值的组合 不可以跨表创建索引 主索引与聚簇索引 将主关键字作为索引。在 MyISAM 中，索引关键字的顺序与表中关键字的顺序不必完全相同，称为 主索引 。在 InnoDB 中，两者顺序必须完全相同，这种索引称为 聚簇索引 索引关键字的选取原则 离散度高 存储空间小 存储空间固定 where 子句经常使用 更新不频繁 最左前缀原则 e . g . 使用有firstname , lastname , address组成的复合索引 ( fname_lname_add ) 就不需要再使用 ( firstname ) , ( firstname , lastname ) , ( firstname , lastname , address ) 前缀索引 索引与约束 对于一个表而言，主键约束（主索引/聚簇索引），唯一性约束（唯一性索引），外键约束（普通索引）是基于索引实现的 创建索引 Mysql还支持全文索引（fulltext），当检索数据量大的字符串信息时，可以使用全文索引。 创建表的同时创建索引 create table table_name ( 字段 1 数据类型 [ 约束条件 ] . 字段 2 数据类型 [ 约束条件 ] . …… [ 其他约束条件 ] , [ 其他约束条件 ] , [ unique |

innoDB索引文件和数据文件是在一起的 frm：表结构；ibd：索引文件和数据文件 问：为什么InnoDB表必须有主键。并且推荐使用整型的自增主键： 1、如果设置了主键，那么InnoDB会选择主键作为聚集索引、如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引、如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增)。 2、如果表使用自增主键 那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，主键的顺序按照数据记录的插入顺序排列，自动有序。当一页写满，就会自动开辟一个新的页 3、如果使用非自增主键（如果身份证号或学号等） 由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置，此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。 问：为什么非主键索引结构叶子结点存储的是主键值： 减少了出现行移动或者数据页分裂时二级索引的维护工作（当数据需要更新的时候，二级索引不需要修改，只需要修改聚簇索引

概括： 这里说的聚集索引是聚簇索引 聚簇索引即建立在聚簇上的索引，创建聚簇索引时，需要对已有表数据重新进行排序（若表中已有数据），即删除原始的表数据后再将排序结果按物理顺序插回，故聚簇索引建立完毕后，建立聚簇索引的列中的数据已经全部按序排列。 一个表中只能包含一个聚簇索引，但该索引可以包含多个列。 B-树索引中，聚簇索引的叶层就是数据页。 非聚簇索引类似书本索引，索引与数据存放在不同的物理区域，建立非聚簇索引时数据本身不进行排序。一个表中科含多个非聚簇索引。 B-树索引中，非聚簇索引的叶层仍是索引页，其以指针指向数据页实际存储位置。 详解，列子： 非聚集索引与聚集索引具有相同的 B 树结构，它们之间的显著差别在于以下两点： 基础表的数据行不按非聚集键的顺序排序和存储。 非聚集索引的叶层是由索引页而不是由数据页组成。 非聚集索引既可以建在堆表结构上也可以建在聚集索引表上；非聚集索引中的每个索引行都包含非聚集键值和行定位符。此定位符指向聚集索引或堆中包含该键值的数据行。 如果表是堆则行定位器是指向行的指针。该指针由文件标识符 (ID) 、页码和页上的行数生成。整个指针称为行 ID (RID) 。 如果表包含有聚集索引，则行定位器是行的聚集索引键。如果聚集索引不是唯一的索引， SQL Server 将添加在内部生成的值（称为唯一值）以使所有重复键唯一。此四字节的值对于用户不可见

参考： http://blog.csdn.net/xluren/article/details/32746183 http://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html 关于MySQL索引的好处，如果正确合理设计并且使用索引的MySQL是一辆兰博基尼的话，那么没有设计和使用索引的MySQL就是一个人力三轮车。对于没有索引的表，单表查询可能几十万数据就是瓶颈，而通常大型网站单日就可能会产生几十万甚至几百万的数据，没有索引查询会变的非常缓慢。还是以WordPress来说，其多个数据表都会对经常被查询的字段添加索引，比如wp_comments表中针对5个字段设计了BTREE索引。 一个简单的对比测试 以我去年测试的数据作为一个简单示例，20多条数据源随机生成200万条数据，平均每条数据源都重复大概10万次，表结构比较简单，仅包含一个自增ID，一个char类型，一个text类型和一个int类型，单表2G大小，使用MyIASM引擎。开始测试未添加任何索引。 执行下面的SQL语句： 1 mysql> SELECT id,FROM_UNIXTIME( time ) FROM article WHERE a.title= '测试标题' 查询需要的时间非常恐怖的，如果加上联合查询和其他一些约束条件，数据库会疯狂的消耗内存

继续 上一篇文章 ，继续SQLServer索引调优实践。这次探讨一下索引覆盖 - SQL Server主要使用索引去查询你需要的数据，当索引包括所有的你请求查询的字段，SQL Server将不需要去在表中查询。这个概念称做“索引覆盖”。 SQLServer2005的Non-clustered INDEX增加了一个“ 包含列(included column) ”选项。在 SQL Server 2005 中，可以通过将非键列添加到非聚集索引的叶级别来扩展非聚集索引的功能。通过包含非键列，可以创建覆盖更多查询的非聚集索引。当查询中的所有列都作为键列或非键列包含在索引中时，带有包含性非键列的索引可以显著提高查询性能。这样可以实现性能提升，因为查询优化器可以在索引中找到所有列值；不访问表或聚集索引数据，从而减少磁盘 I/O 操作。 但应避免添加不必要的列。添加过多的索引列（键列或非键列）会对性能产生不良影响，应该合理使用。和Clustered INDEX，或者组合索引，结合使用，扩大索引覆盖，但不大可能所有列都有索引覆盖，磁盘开销和数据insert updat时索引的重新计算的时间开销是巨大的。总之，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来,才能产生最佳的优化方案。 继续实践，先建个实验表 Table1： 建两个索引： 1.

　　百万数据量SQL，在进行分页查询时会出现性能问题，例如我们使用PageHelper时，由于分页查询时，PageHelper会拦截查询的语句会进行两个步骤 　　1.添加 select count（*）from （原查询sql） ，用于统计查询的总数 　　2.拼接 limit startPage，number 用于分页 　　 　　此时有两个问题 　　　　第一个问题是： 　　　　　　用于统计的 select count（*）from （原查询sql）在数据量大时速度慢 　　　　第二个问题时： 　　　　　　limit startPage，number 在大数据量时效率低 　　 　　解决方案： 　　　　第一个问题： 　　　　　　在数据量过大时，不使用分页插件PageHelper，select count（*）from （原查询sql）固定返回一个固定值给到前端，例如千万级数据，固定返回1千万 　　　　第二个问题： 　　　　　　在数据量过大时，不使用分页插件PageHelper ，使用join或者子查询去优化 　　　　　　例如 id为主键，name为非唯一索引 　　　　　　　　优化前： 　　　　　　　　select id,name,brand from table where name=‘xxx’ limit 100000，10 　　　　　　　　优化后： 　　　　　　　　select aa

一、Mysql的逻辑架构 二、存储引擎 Mysql5.5之前，默认存储引擎是MyISAM，5.5之后默认存储引擎变成 InnoDB 。 MyISAM和InnoDB的区别： 1）MyISAM不支持事务、InnoDB支持事务 2）MyISAM只有表锁、InnoDB引入了行锁 3）MyISAM支持全文索引、InnoDB 5.5不支持，5.6以后支持 4）MyISAM的读写速度会优于InnoDB 三、MySQL优化（SQL优化） · 数据类型的优化（创建表的时候，选择合适的数据类型） · 索引优化（SQL优化成本最低并且最有效果的优化方式） · 查询优化（SQL自带的检测工具、SQL结构） · 库表结构优化（分库分表、读写分离） · 硬件优化（cpu、固态硬盘、内存） · 参数优化（系统运行参数）- DBA 四、数据类型的优化 数据类型的选择原则： · 选择最小的数据类型，同时需要保证能够放下所存储的数据 · 选择最合适的数据类型，比如使用int表示年龄，而是不是varchar表示年龄 · 尽量让需要添加索引的列为not null 五、索引优化 什么是索引？ 索引是一本书的目录，可以快速找到相应的内容。 索引是一个帮助我们快速查询内容的 数据结构 。 　 无索引的查询方式： 有索引的查询方式： 索引失效： 当写了一个索引后，开发者认为执行的sql会用上该索引

索引是一个比较复杂的模块，要学好需要多花点时间。索引是MySQL进行查询优化的一个很重要的手段，如果用得好，可以成为数据访问的有力而且灵活的工具，快速提高查询效率，所以多花点时间好好学习和思考这一块内容也是很值得的。下面，对MySQL中索引的内容做了一下归纳总结，有点零散。 01、索引基础 1、索引是存储引擎用于快速找到记录的一种数据结构。 2、索引是对查询性能优化最有效的手段。 3、B-树索引能够加快访问数据的速度，因为存储引擎不再需要进行全表扫描来获取需要的数据，取而代之的是索引的根节点开始进行搜索。根节点的槽中存放了指向子节点的指针，存储引擎根据这些指针向下层查找。通过比较节点页的值和要查找的值可以找到合适的指针进入下一层子节点，这些指针实际上定义了子节点页中值的上限和下限。最终存储引擎要么是找到对应的值，要么该记录不存在。 4、B-树对索引列是顺序组织存储的，所以很适合查找范围数据。 5、使用B-树索引适用于全键值、键值范围或键前缀查找。具体地： （1）全值匹配 （2）匹配最左前缀 （3）匹配列前缀 （4）匹配范围值 （5）精确匹配某一列并范围匹配另一列 （6）只访问索引的查询 6、如果不是按照索引的最左列开始查找，则无法使用索引。 7、不能跳过索引中的列。 8、如果查询中有某个列的范围查找，则其右边所有列都无法使用索引优化查找。 9、哈希索引：对于每一行数据

MySQL索引B+Tree优化实战 环境说明 Centos版本: CentOS Linux release 7.7.1908 (Core) Linux连接工具：SecureCRT MySQL Version: 5.7.28 MySQL连接工具：Navicate 知识扩展 Mysql中的UTF8是0-3个字节，Java中的UTF8是0-4个字节 ，在MySQL中设置字符集UTF8mb4才是0-4个字节 在MySQL4.0版本一下varchar代表的是字节 在MySQL4.0版本之后varchar代表的是字符 思考： char(10)能存储多少个中文？多少个英文？ varchar(10)能存储多少个中文？多少个英文？ 参考文档：https://dev.mysql.com/doc/refman/5.7/en/char.html 索引概念 索引是什么？ 索引是帮助MySQL高效获取数据的数据结构！ 官方解释：索引用于快速查找具有特定列值的行。没有索引，MySQL必须从第一行 开始，然后通 读整个表以找到相关的行。表越大，花费时间越长。如果表中有相关 列的索 引 MySQL可以快速确定要在数据文件中间查找的位置，而不必查看所有 数据。这比顺序读取每一行要快得多。 索引能干什么? 高数据查询的效率。 索引会影响where后面 的查找和order by 后面的排序。 索引的种类