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目前主要的索引类型有下面几种:

与前面的普通索引类似,但是他的索引列的值必须是唯一的,所以叫唯一索引,但是这个索引字段如果是空值是可以的,具体创建方式如下:

主键索引是一种特殊的索引,一个表只能有一个主键,不允许有空值,一般是创建表的时候创建主键索引,而且一般习惯设置成自增的,因为对弈MySQL的底层B+树存储起来很方便

组合索引指多个字段上创建的索引,只有在查询时候,查询条件中使用了创建索引时的第一个字段,索引才会生效,他使用遵循最左前缀原则.

索引生效情况:

select * from table where name=1

select * from table where name=1 and city=2

select * from table where name=1 and city=2 and age=3

索引不生效情况:

select * from table where name=1 and age=3

select * from table where city=2 and age=3

select * from table where age=3

select * from table where city=2

这个遵循的是最左原则,具体MySQL底层对联合索引的存储以及为什么是最左原则,参考本人另外一篇文章最后一段就能看明白

https://www.jianshu.com/p/99aabf9611a3

全文索引主要是用来查找文本中的关键字,而不是直接与索引中的值相比较.fulltext索引跟其他索引大不相同,他更像是一个搜索引擎,而不是简单的where 语句的参数匹配,fulltext索引配合match(匹配)和against(反对) *** 作使用,而不是一般的where语句加上like,他可以在create table,alter table,create index使用

表button 

CREATE TABLE `button` (

  `id` bigint(20) NOT NULL AUTO_INCREMENT,  --主键索引

  `button_name` varchar(45) NOT NULL COMMENT '功能名称',

  `app_id` bigint(20) NOT NULL,

  `permission_id` bigint(20) DEFAULT NULL,  -- permission_id 和 app_id 联合索引。

  `api_id` bigint(20) NOT NULL, --api_id单独索引

  PRIMARY KEY (`id`),

  KEY `index_app_permission_lianhe` (`permission_id`,`app_id`) USING BTREE,

  KEY `index_api_id_dange` (`api_id`)

) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

主键索引，单独索引，组合索引使用场景及优化

表button 有3个索引，分别是：id主键，联合索引(permission_id,app_id)，api_id(单列索引)

button_name 无索引

查询where条件中：

主键索引：

1、主键索引与联合索引同时存在，使用主键索引

2、主键索引与单个索引同时存在，使用主键索引

结论：只要主键索引在，使用主键索引。

联合索引 ：

1、联合索引与单列索引列 同时存在，使用单列索引

2、联合索引中列顺序颠倒无影响。

3、联合索引实行最左侧原则，即：单独查询条件中只有permission_id可以使用联合索引，单独查询条件中只有app_id不实用联合索引。

4、如果查询条件中只有app_id，但是select 条件中有 permission_id，则也使用联合索引。

5、select id,app_id from button where app_id=1001使用联合索引

6、explain select id,app_id,button_name from button where app_id=1001不使用联合索引

结论：索引优先级：主键索引，单列索引，组合索引

    联合索引中遵从最左侧列原则。

    当查询条件和返回结果中仅仅包含联合索引中索引项，也使用联合索引。如第4条。

    当查询条件中出现联合索引中非最左侧索引列，返回结果中含义联合索引中的列或者主键则也使用联合索引。

单个索引：

1、查询条件中有单列索引，则使用，无不使用。

事例：

---