MySQL索引碎片整理

查看碎片信息：

Index_length 代表索引的总量

Data_free 代表碎片数量

从information_schema中获取信息：

碎片整理：

过程时间长短取决于表大小和碎片多少，

返回结果optimize status OK则整理完成；

碎片整理过程会添加表级排他锁，需要找非繁忙期进行 *** 作。

删除数据必然会在数据文件中造成不连续的空白空间,而当插入数据时,这些空白空间则会被利用起来.于是造成了数据的存储位置不连续,以及物理存储顺序与理论上的排序顺序不同,这种是数据碎片.实际上数据碎片分为两种,一种是单行数据碎片,另一种是多行数据碎片.前者的意思就是一行数据,被分成N个片段,存储在N个位置.后者的就是多行数据并未按照逻辑上的顺序排列.当有大量的删除和插入 *** 作时,必然会产生很多未使用的空白空间,这些空间就是多出来的额外空间.索引也是文件数据,所以也会产生索引碎片,理由同上,大概就是顺序紊乱的问题.Engine 不同,OPTIMIZE 的 *** 作也不一样的,MyISAM 因为索引和数据是分开的,所以 OPTIMIZE 可以整理数据文件,并重排索引。这样不但会浪费空间，并且查询速度也更慢。

查看碎片信息：

Index_length 代表索引的总量

Data_free 代表碎片数量

从information_schema中获取信息：

碎片整理：

过程时间长短取决于表大小和碎片多少，

返回结果optimize status OK则整理完成；

二叉搜索树、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

---