mysql索引

二叉搜索树、N叉树

页分裂：B+树的插入可能会引起数据页的分裂，删除可能会引起数据页的合并，二者都是比较重的IO消耗，所以比较好的方式是顺序插入数据，这也是我们一般使用自增主键的原因之一。

页分裂逆过程：页合并，当删除数据后，相邻的两个数据页利用率很低的时候会做数据页合并

主键索引：key：主键，value：数据页，存储每行数据

非主键索引：key：非主键索引，value：主键key，导致回表

最左匹配：优先将区分度高的列放到前面，这样可以高效索引，

最左匹配原则遇到范围查询就停止匹配，范围查询(>、<、between、like)为什么？因为出现范围匹配后，后面的索引字段无法保证有序，局部有序失去，顺序失去则无法提高查询效率

SELECT * FROM table WHERE a IN (1,2,3) and b >1

如何建立索引？

还是对(a，b)建立索引，因为IN在这里可以视为等值引用，不会中止索引匹配，所以还是(a,b)!

索引组织表

索引用页存储：key【10】-point【6】，通过调整key大小，当页大小固定的情况下，通过调整key大小，使得N叉树变化；

如key 10, point 6则单个索引16字节，页大小为16k，则页面总共可以存储1024个索引，即N大小

覆盖索引: 二级索引的信息已经存在想要的列，例如主键

如果现在有一个高频请求，要根据市民的身份z号查询他的姓名，这个联合索引就有意义了。它可以在这个高频请求上用到覆盖索引，不再需要回表查整行记录，减少语句的执行时间。

索引下推优化：可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。

整理索引碎片，重建表：alter table T engine=InnoDB

  首先是看key的大小，另外是数据页的大小，如果需要改变N，则需要从这两个方面做改动；

一个innoDB引擎的表，数据量非常大，根据二级索引搜索会比主键搜索快，文章阐述的原因是主键索引和数据行在一起，非常大搜索慢，我的疑惑是：通过普通索引找到主键ID后，同样要跑一边主键索引，对于使用覆盖索引的情况下，使用覆盖索引可以直接解决问题

https://blog.csdn.net/itworld123/article/details/115144202

https://time.geekbang.org/column/article/69236

https://zhuanlan.zhihu.com/p/334684710

https://www.cxyzjd.com/article/pyzhizhuren/88431380

https://www.jianshu.com/p/4277d9dd0a9f

https://www.cnblogs.com/rjzheng/p/12557314.html

https://mengkang.net/1302.html

https://note.cser.club/database/bi-xu-le-jie-de-mysql-san-da-ri-zhi-binlogredo-log-he-undo-log

https://cloud.tencent.com/developer/news/44861

引入一个面试问题:

看完以下以后再回顾，会发现迎刃而解

Mysql 可以为每一张表设置 存储引擎 这里我们只说 InnoDB 存储引擎.

由于实际情况，数据页只能按照一棵 B+树 进行排序， 因此每张表只能拥有一个 聚集索引（即 主键）。

栗子：

每个叶子节点的索引行中包含了一个书签（bookmark）. 该书签是用来告诉 InnoDB存储引擎哪里可以找到该索引对应的数据行或者说 行数据！ 由于InnoDB存储引擎表， 是按照主键来构建的， 所以 ，该书签内其实包含或者说指向了 数据行所对应的聚集索引键

也就是说 辅助索引的 叶结点保存了 指向对应数据的 聚集索引， 可以通过该聚集索引 找到对应的数据行

辅助索引的存在并不影响数据在聚集索引中的组织，因为每张表上可以有多个辅助索引。

当通过辅助索引来寻找数据时，InnoDB 存储引擎会遍历辅助索引并通过叶级别的指针获得指向主键索引(聚集索引)的主键，然后再通过聚集索引找到一个完整的数据行。

例如：

聚集索引辅助索引关系:

： 又叫做组合索引 ， 辅助索引的一种 ， 和普通创建索引的方式一样，不同的是 可以同时添加多列来作为索引项

从本质上来说，联合索引也是一课B+树

个人理解： 所谓最左原则， 是因为 存储引擎构建组合索引时 是根据最左边的那一列索引项进行排序的 ，所以使用组合索引，必须满足 条件中必须存在 最左边那一列的索引项，这样 才可以找到对应的索引，继而 去寻找对应的数据

： 又叫做 索引覆盖，InnoDB中支持覆盖索引，即 从辅助索引中就可以得到查询的记录，而不需要查询聚集索引中的记录。

比如 这里没有根据最左原则使用组合索引，但是 优化器依然进行选择

共勉，欢迎指导谢谢~

五 索引分类

直接创建索引和间接创建索引

直接创建索引 CREATE INDEX mycolumn_index ON mytable (myclumn)

间接创建索引 定义主键约束或者唯一性键约束 可以间接创建索引

普通索引和唯一性索引

普通索引 CREATE INDEX mycolumn_index ON mytable (myclumn)

唯一性索引 保证在索引列中的全部数据是唯一的 对聚簇索引和非聚簇索引都可以使用

CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable(mycolumn)

单个索引和复合索引

单个索引 即非复合索引

复合索引 又叫组合索引 在索引建立语句中同时包含多个字段名 最多 个字段

CREATE INDEX name_index ON username(firstname lastname)

聚簇索引和非聚簇索引(聚集索引 群集索引)

聚簇索引 物理索引 与基表的物理顺序相同 数据值的顺序总是按照顺序排列

CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn) WITH

ALLOW_DUP_ROW(允许有重复记录的聚簇索引)

非聚簇索引 CREATE UNCLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn)

六 索引的使用

当字段数据更新频率较低 查询使用频率较高并且存在大量重复值是建议使用聚簇索引

经常同时存取多列 且每列都含有重复值可考虑建立组合索引

复合索引的前导列一定好控制好 否则无法起到索引的效果 如果查询时前导列不在查询条件中则该复合索引不会被使用 前导列一定是使用最频繁的列

多表 *** 作在被实际执行前 查询优化器会根据连接条件 列出几组可能的连接方案并从中找出系统开销最小的最佳方案 连接条件要充份考虑带有索引的表 行数多的表内外表的选择可由公式 外层表中的匹配行数*内层表中每一次查找的次数确定 乘积最小为最佳方案

where子句中对列的任何 *** 作结果都是在sql运行时逐列计算得到的 因此它不得不进行表搜索 而没有使用该列上面的索引如果这些结果在查询编译时就能得到 那么就可以被sql优化器优化 使用索引 避免表搜索(例 select * from record where substring(card_no )=

&&select * from record where card_no like % )任何对列的 *** 作都将导致表扫描 它包括数据库函数 计算表达式等等 查询时要尽可能将 *** 作移至等号右边

where条件中的 in 在逻辑上相当于 or 所以语法分析器会将in ( ′ ′)转化为column= ′ or column= ′来执行 我们期望它会根据每个or子句分别查找 再将结果相加 这样可以利用column上的索引但实际上它却采用了 or策略 即先取出满足每个or子句的行 存入临时数据库的工作表中 再建立唯一索引以去掉重复行 最后从这个临时表中计算结果 因此 实际过程没有利用column上索引 并且完成时间还要受tempdb数据库性能的影响 in or子句常会使用工作表 使索引失效如果不产生大量重复值 可以考虑把子句拆开拆开的子句中应该包含索引

要善于使用存储过程 它使sql变得更加灵活和高效

lishixinzhi/Article/program/MySQL/201311/29603

---