讲讲MySQL的删除

若有收获，请记得分享和转发哦

删除并不是真正的删除

熟悉mysql的同学都应该知道，当我们执行delete的时候，数据并没有被真正的删除，只是对应数据的删除标识deleteMark被打开了，这样每次执行查询的时候，如果发现数据存在但是deleteMark是开启的话，那么依然返回空，因为这个细节，所以经常会出现“我明明删除了数据，为什么空间没释放”的现象。

15M  7  6 18:46 user_info.ibd #删除前
15M 10  4 16:47 user_info.ibd #删除后

为什么不直接删除，而是打个标记

只是打个标记的话，岂不是很浪费空间

mysql里面有个purge线程，它的工作中有一项任务就是专门检查这些有deleteMark的数据，当有deleteMark的数据如果没有被其他事务引用时，那么会被标记成可复用，因为叶子节点数据是有序的原因，这样当下次有同样位置的数据插入时，可以直接复用这块磁盘空间。当整个页都可以复用的时候，也不会把它还回去，会把可复用的页留下来，当下次需要新页时可以直接使用，从而减少频繁的页申请。

通过上面我们知道检索一条数据的快慢，主要受树的高度影响的，这和你的数据表的大小并没有太大的关系，现实中有人可能在数据表达到百万级别的时就考虑分表，个人认为这有点低估B+树的能力了。还是以bigint类型的主键索引为例，假设一行数据占用1K（理论上已经足够大了），那么一页可以存下 16K/1K=16 条数据，对于一颗高度为3的B+树来说，它可以存下 1170*1170*16=21902400 的数据，将近2千万，如果你的数据行占用的空间更小，就可以存下更多的数据，所以只是简单的根据数据行数来判断是否需要分表不是那么的合理。

可复用的空间一直没有被利用咋办

有合并也有分裂

合并页是提升页的利用率的方式，但是有时候我们又不得不分裂页，我们知道叶子节点的页之间是用双向链表串接起来的，并且页与页之间的数据是有序的。

以上图为例，当我们要插入5这条数据，按道理应该尝试放在pageA里面，但是pageA目前没有足够的空间来存放一条数据，于是尝试找到pageA的相邻页pageB，但是此时很不幸的是pageB也没有足够的空间来存放一条数据，由于要求数据的连续性，数据5必须在数据4和数据6之间，那么只能新建一个页，新建一个页后，会尝试从pageA中移动一部分数据到新的页上，并且会重新组织页与页之间的关系，即在pageA和pageB之间会隔一道新页pageC。

页分裂会造成页的利用率降低，造成页分裂的原因有很多，比如：

1. 比如离散的插入，导致数据不连续。

2. 把记录更新成一个更大记录，导致空间不够用

还有一点需要知道的是：不管是页的合并还是页的分裂，都是相对耗时的操作，除了移动数据的开销外，InnoDB也会在索引树上加锁。

手动重建表

重建表不一定会收缩空间

在重建表的过程中，有一点需要知道：InnoDB不会让重建后的页充满数据，会预留个「1/16」的空间，这个意图很明显，如果不预留，选择占满整个页，这时候去更新一条需要更大空间的老数据，就会需要新的页，写入新的页后，往往又会造成碎片，所以提前预留一点空间是有用的。

但是因为这个预留操作，某些情况下会导致重建后的表空间反而会变大。

1. 如果你的表本身就很紧凑，因为预留1/16会变大。

2. 在第一次重建表后，因为新的插入导致用掉了预留空间的一部分（这里需要注意的是预留空间没用完，还剩一部分），但是没有用到新的页，所以整体的空间没有变化，这时候如果再次重建表，就会因为要预留1/16，导致申请的新的页，那么空间就会变大。