這篇文章為大家帶來了關於mysql的相關知識，其中主要整理了碎片整理方案的相關問題，也即解決delete大量資料後空間不釋放的問題，下面一起來看一下，希望對大家有幫助。
推薦學習：mysql影片教學
MySQL 中insert 與update 都可能導致頁分裂，這樣就存在碎片。
對於大量的UPDATE，也會產生檔案碎片化， Innodb的最小實體儲存分配單位是頁(page)，而UPDATE也可能導致頁分裂（page split），頻繁的頁分裂，頁會變得稀疏，並且被不規則的填充，所以最終資料會有碎片。
delete 語句其實只是給資料打個標記，並且記錄到一個鍊錶中，這樣就形成了留白空間。
在InnoDB中，刪除一些行，這些行只是被標記為“已刪除”，而不是真的從索引中物理刪除了，因而空間也沒有真的被釋放回收。 InnoDB的Purge執行緒會異步的來清理這些沒用的索引鍵和行。
當執行插入操作時，MySQL會嘗試使用空白空間，但如果某個空白空間一直沒有被大小合適的資料佔用，仍然無法將其徹底佔用，就形成了碎片；
總結：
表的增刪改操作，可能會造成資料空洞的，當資料表進行大量的增刪改操作後，數據空洞存在的可能性比較大。
MySQL刪除資料幾種情況以及是否釋放磁碟空間:
當MySQL掃描資料時，它掃描的物件實際上是列表的容量需求上限，也就是資料被寫入的區域中處於峰值位置的部分；
MySQL資料庫中的表在進行了多次delete、update和insert後，表空間會出現碎片。定期進行表空間整理，消除碎片可以提高存取表空間的效能。
這種碎片不僅額外增加了儲存代價，同時也因為資料碎片化降低了表格的掃描效率。
片段若不整理，那麼可能會長期佔據磁碟空間，導致磁碟使用率越來越高。
修復問題的前提是要先找到問題，這樣才能對症下藥。
查看資料庫中每個存在碎片的表
mysql> select concat('optimize table ',table_schema,'.',table_name,';'),data_free,engine from information_schema.tables where data_free>0 and engine !='MEMORY';
+-----------------------------------------------------------+-----------+--------+
| concat('optimize table ',table_schema,'.',table_name,';') | DATA_FREE | ENGINE |
+-----------------------------------------------------------+-----------+--------+
| optimize table abc.t_user_answer; | 2097152 | InnoDB |
| optimize table mysql.time_zone_transition; | 4194304 | InnoDB |
| optimize table mysql.time_zone_transition_type; | 4194304 | InnoDB |
| optimize table mysql.user; | 4194304 | InnoDB |
。。。。#查看指定表的碎片情況
mysql> show table status like 't_user'\G *************************** 1. row *************************** Name: t_user Engine: InnoDB Version: 10 Row_format: Dynamic Rows: 4333 Avg_row_length: 589 Data_length: 2555904 Max_data_length: 0 Index_length: 2719744 Data_free: 4194304 Auto_increment: NULL Create_time: 2021-11-19 10:13:31 Update_time: 2022-04-20 14:28:42 Check_time: NULL Collation: utf8mb4_general_ci Checksum: NULL Create_options: Comment: 1 row in set (0.00 sec)
Data_free: 4194304 就代表碎片的byte數。如果經常刪改資料表，會造成大量的Data_free 頻繁 刪除記錄 或修改有可變長度欄位的表。
找到碎片化最嚴重的表格
SELECT table_schema, TABLE_NAME, concat(data_free/1024/1024, 'M') as data_free FROM `information_schema`.tables WHERE data_free > 3 * 1024 * 1024 AND ENGINE = 'innodb' ORDER BY data_free DESC
官方文件參考
#
这其实是一个NULL操作,表面上看什么也不做,实际上重新整理碎片了.当执行优化操作时,实际执行的是一个空的 ALTER 命令,但是这个命令也会起到优化的作用,它会重建整个表,删掉未使用的空白空间.
Running ALTER TABLE tbl_name ENGINE=INNODB on an existing InnoDB table performs a “null” ALTER TABLE operation, which can be used to defragment an InnoDB table, as described in Section 15.11.4, “Defragmenting a Table”. Running ALTER TABLE tbl_name FORCE on an InnoDB table performs the same function.
MySQL5.6 开始采用 Inplace 方式重建表，Alter 期间，支持 DML 查询和更新操作，语句为 alter table t engine=innodb, ALGORITHM=inplace;之所以支持 DML 更新操作，是因为数据拷贝期间会将 DML 更新操作记录到 Row log 中。 重建过程中最耗时的就是拷贝数据的过程，这个过程中支持 DML 查询和更新操作，对于整个 DDL 来说，锁时间很短，就可以近似认为是 Online DDL。 执行过程： 1、获取 MDL（Meta Data Lock）写锁，innodb 内部创建与原表结构相同的临时文件 2、拷贝数据之前，MDL 写锁退化成 MDL 读锁，支持 DML 更新操作 3、根据主键递增顺序，将一行一行的数据读出并写入到临时文件，直至全部写入完成。并且，会将拷贝期间的 DML 更新操作记录到 Row log 中 4、上锁，再将 Row log 中的数据应用到临时文件 5、互换原表和临时表表名 6、删除临时表
OPTIMIZE TABLE语句可以重新组织表、索引的物理存储，减少存储空间，提高访问的I/O效率。类似于碎片整理功能。
MySQL可以通过optimize table语句释放表空间，重组表数据和索引的物理页，减少表所占空间和优化读写性能
使用语法
OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_n说ame [, tbl_name] …
注意：
需要有足够的空间才能进行OPTIMIZE TABLE。 (剩余空间必须 > 被 OPTIMIZE 的表的大小)
OPTIMIZE 只对独立表空间(innodb_file_per_table=1)才有用，对共享表空间不起作用。
对于共享表空间，如果需要瘦身： 必须将数据导出，删除ibdata1，然后将 innodb_file_per_table 设置为独立表空间， 然后将数据导入进来。
对于InnoDB的表，OPTIMIZE TABLE 的工作原理如下
对于InnoDB表， OPTIMIZE TABLE映射到ALTER TABLE … FORCE（或者这样翻译：在InnoDB表中等价 ALTER TABLE … FORCE），它重建表以更新索引统计信息并释放聚簇索引中未使用的空间。
当您在InnoDB表上运行时，它会显示在OPTIMIZE TABLE的输出中，如下所示： mysql> OPTIMIZE TABLE foo; +----------+----------+----------+---------------------------------------+ | Table | Op | Msg_type | Msg_text | +----------+----------+----------+---------------------------------------+ | test.foo | optimize | note | Table does not support optimize, doing recreate + analyze instead | | test.foo | optimize | status | OK | +----------+----------+----------+---------------------------------------+ # 但这个提示语可以忽略，从严格的意义讲，说InnoDB不支持optimize table，其实不太准确。 因为 MYSQL的文档说明了，当INNODB 的表，MYSQL会以 ALTER TABLE force + analyze 去执行这个命令(相当于做了recreate和analyze)。 所以最终还是会看到 OK 的状态。 # https://stackoverflow.com/questions/30635603/what-does-table-does-not-support-optimize-doing-recreate-analyze-instead-me
对于MYISAM表，OPTIMIZE TABLE 的工作原理：
1. 如果表已删除或分隔行，就修复该表。
2. 如果索引页没有排序，就排序它们。
3. 如果表的统计信息不是最新的(而且修复不能通过对索引进行排序)，就更新它们。
**执行时也可以发现报错： Temporary file write failure. **
建议参考这片文章：
Mysql optimize table 时报错 Temporary file write failure. 的解决方案
optimize 语句的官网介绍
如果您已经删除了表的一大部分，或者如果您已经对含有可变长度行的表（含有VARCHAR, BLOB或TEXT列的表）进行了很多更改，则应使用 OPTIMIZE TABLE。
被删除的记录被保持在链接清单中，后续的INSERT操作会重新使用旧的记录位置。您可以使用OPTIMIZE TABLE来重新利用未使用的空间，并整理数据文件的碎片。
在多数的设置中，您根本不需要运行OPTIMIZE TABLE。即使您对可变长度的行进行了大量的更新，您也不需要经常运行，每周一次或每月一次 即可，只对特定的表运行。
Mysql 5.6 之前 在OPTIMIZE TABLE运行过程中，MySQL会锁定表，5.6之后有了 Online DDL 则大大减少了锁表时间。
alter table tb_test engine = innodb；
analyze table tb_test ；
optimize table tb_test ；
MySQL官方建議不要經常(每小時或每天)進行碎片整理，一般根據實際情況，只需要每週或每月整理一次即可(我們現在是每月凌晨4點清理mysql所有實例下的表格碎片)
推薦學習：mysql影片教學
以上是MySQL的幾種碎片整理方案的詳細內容。更多資訊請關注PHP中文網其他相關文章！
