起因：查看線上數據庫中Table Information時發現有一個日志表數據大小和索引大小有915M，但實際行數只有92行。該表需要頻繁插入并且會定時去刪掉舊的記錄。表類型為Myisam，已建立一個索引，所以應該是產生了大量碎片，使用 Optimize table 表名 優化后大小變為2.19M，少了很多， 同時可以看出該表上的索引建的多余，因為插入操作比查詢操作要多很多，而且查詢不多，查詢的數據量也一般比較小。

借此延伸下MYSQL中Myisam、InnoDB碎片優化方式：

Myisam清理碎片

OPTIMIZE TABLE table_name

InnoDB碎片優化

if you frequently delete rows (or update rows with variable-length data types), you can end up with a lot of wasted space in your data file(s), similar to filesystem fragmentation.

If you’re not using the innodb_file_per_table option, the only thing you can do about it is export and import the database, a time-and-disk-intensive procedure.

But if you are using innodb_file_per_table, you can identify and reclaim this space!

Prior to 5.1.21, the free space counter is available from the table_comment column of information_schema.tables. Here is some SQL to identify tables with at least 100M (actually 97.65M) of free space:

SELECT table_schema, table_name, table_comment FROM information_schema.tables WHERE engine LIKE ‘InnoDB’ AND table_comment RLIKE ‘InnoDB free: ([0-9]{6,}).*‘;

Starting with 5.1.21, this was moved to the data_free column (a much more appropriate place):

SELECT table_schema, table_name, data_free/1024/1024 AS data_free_MB FROM information_schema.tables WHERE engine LIKE ‘InnoDB’ AND data_free > 100*1024*1024;

You can reclaim the lost space by rebuilding the table. The best way to do this is using ‘alter table’ without actually changing anything:

ALTER TABLE foo ENGINE=InnoDB;

This is what MySQL does behind the scenes if you run ‘optimize table’ on an InnoDB table. It will result in a read lock, but not a full table lock. How long it takes is completely dependent on the amount of data in the table (but not the size of the data file). If you have a table with a high volume of deletes or updates, you may want to run this monthly, or even weekly.

什么是mysql碎片?怎樣知道表的碎片有多大呢?

簡單的說,刪除數據必然會在數據文件中造成不連續的空白空間,而當插入數據時,這些空白空間則會被利用起來.于是造成了數據的存儲位置不連續,以及物理存儲順序與理論上的排序順序不同,這種是數據碎片.實際上數據碎片分為兩種,

一種是單行數據碎片,

另一種是多行數據碎片.

前者的意思就是一行數據,被分成N個片段,存儲在N個位置.

后者的就是多行數據并未按照邏輯上的順序排列.

當有大量的刪除和插入操作時,必然會產生很多未使用的空白空間,

這些空間就是多出來的額外空間.索引也是文件數據,

所以也會產生索引碎片,理由同上,大概就是順序紊亂的問題.Engine 不同,OPTIMIZE 的操作也不一樣的,MyISAM 因為索引和數據是分開的,所以 OPTIMIZE 可以整理數據文件,并重排索引.

OPTIMIZE 操作會暫時鎖住表,而且數據量越大,耗費的時間也越長,它畢竟不是簡單查詢操作.所以把 Optimize 命令放在程序中是不妥當的,不管設置的命中率多低,當訪問量增大的時候,整體命中率也會上升,這樣肯定會對程序的運行效率造成很大影響.比較好的方式就是做個 Script,定期檢查mysql中information_schema.TABLES字段,查看 DATA_FREE 字段,大于0話,就表示有碎片.腳本多長時間運行一次,可以根據實際情況來定,比如每周跑一次.

總結

以上是生活随笔為你收集整理的MySQL中Myisam、InnoDB碎片优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。