linux下mysql的drop table命令不能把表和相關(guān)存儲信息都刪除干凈，怎么弄

使用OPTIMIZE TABLE語句可以。

成都創(chuàng)新互聯(lián)公司主營武陵網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,APP應(yīng)用開發(fā),武陵h5小程序開發(fā)搭建,武陵網(wǎng)站營銷推廣歡迎武陵等地區(qū)企業(yè)咨詢

OPTIMIZE TABLE語法

OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

如果您已經(jīng)刪除了表的一大部分，或者如果您已經(jīng)對含有可變長度行的表（含有VARCHAR, BLOB或TEXT列的表）進(jìn)行了很多更改，則應(yīng)使用OPTIMIZE TABLE。被刪除的記錄被保持在鏈接清單中，后續(xù)的INSERT操作會重新使用舊的記錄位置。您可以使用OPTIMIZE TABLE來重新利用未使用的空間，并整理數(shù)據(jù)文件的碎片。

在多數(shù)的設(shè)置中，您根本不需要運(yùn)行OPTIMIZE TABLE。即使您對可變長度的行進(jìn)行了大量的更新，您也不需要經(jīng)常運(yùn)行，每周一次或每月一次即可，只對特定的表運(yùn)行。

OPTIMIZE TABLE只對MyISAM, BDB和InnoDB表起作用。

對于MyISAM表，OPTIMIZE TABLE按如下方式操作：

1. 如果表已經(jīng)刪除或分解了行，則修復(fù)表。

2. 如果未對索引頁進(jìn)行分類，則進(jìn)行分類。

3. 如果表的統(tǒng)計(jì)數(shù)據(jù)沒有更新（并且通過對索引進(jìn)行分類不能實(shí)現(xiàn)修復(fù)），則進(jìn)行更新。

對于BDB表，OPTIMIZE TABLE目前被映射到ANALYZE TABLE上。對于InnoDB表，OPTIMIZE TABLE被映射到ALTER TABLE上，這會重建表。重建操作能更新索引統(tǒng)計(jì)數(shù)據(jù)并釋放成簇索引中的未使用的空間。

要重新使用未使用的空間并減小文件的尺寸，則使用OPTIMIZE TABLE語句或myisamchk應(yīng)用程序重新編排表。OPTIMIZE TABLE更簡便，但是myisamchk速度更快。

如何壓縮Mysql數(shù)據(jù)庫

壓縮表從名字上來看，簡單理解為壓縮后的表，也就是把原始表根據(jù)一定的壓縮算法按照一定的壓縮比率壓縮后生成的表。

1.1 壓縮能力強(qiáng)的產(chǎn)品

表壓縮后從磁盤占用上看要比原始表要小很多。如果你熟悉列式數(shù)據(jù)庫，那對這個概念一定不陌生。比如，基于 PostgreSQL 的列式數(shù)據(jù)庫 Greenplum；早期基于 MySQL 的列式數(shù)據(jù)庫 inforbright；或者 Percona 的產(chǎn)品 tokudb 等，都是有壓縮能力非常強(qiáng)的數(shù)據(jù)庫產(chǎn)品。

1.2 為什么要用壓縮表？

情景一：磁盤大小為 1T，不算其他的空間占用，只能存放 10 張 100G 大小的表。如果這些表以一定的比率壓縮后，比如每張表從 100G 壓縮到 10G，那同樣的磁盤可以存放 100 張表，表的容量是原來的 10 倍。情景二：默認(rèn) MySQL 頁大小 16K，而 OS 文件系統(tǒng)一般塊大小為 4K，所以在 MySQL 在刷臟頁的過程中，有一定的概率出現(xiàn)頁沒寫全而導(dǎo)致數(shù)據(jù)壞掉的情形。比如 16K 的頁寫了 12K，剩下 4K 沒寫成功，導(dǎo)致 MySQL 頁數(shù)據(jù)損壞。這個時候就算通過 Redo Log 也恢復(fù)不了，因?yàn)閹缀跤兴械年P(guān)系數(shù)據(jù)庫采用的 Redo Log 都記錄了數(shù)據(jù)頁的偏移量，此時就算通過 Redo Log 恢復(fù)后，數(shù)據(jù)也是錯誤的。所以 MySQL 在刷臟數(shù)據(jù)之前，會把這部分?jǐn)?shù)據(jù)先寫入共享表空間里的 DOUBLE WRITE BUFFER 區(qū)域來避免這種異常。此時如果 MySQL 采用壓縮表，并且每張表頁大小和磁盤塊大小一致，比如也是 4K，那 DOUBLE WRITE BUFFER 就可以不需要，這部分開銷就可以規(guī)避掉了。查看文件系統(tǒng)的塊大?。?/p>

root@ytt-pc:/home/ytt#??tune2fs?-l?/dev/mapper/ytt--pc--vg-root??|?grep?-i?'block?size'Block size: ? ? ? ? ? ? ? 4096

1.3 壓縮表的優(yōu)勢

壓縮表的優(yōu)點(diǎn)非常明顯，占用磁盤空間?。∮捎谡加每臻g小，從磁盤置換到內(nèi)存以及之后經(jīng)過網(wǎng)絡(luò)傳輸都非常節(jié)省資源。

簡單來講：節(jié)省磁盤 IO，減少網(wǎng)絡(luò) IO。

1.4 壓縮表的缺陷

當(dāng)然壓縮表也有缺點(diǎn)，壓縮表的寫入（INSERT,UPDATE,DELETE）比普通表要消耗更多的 CPU 資源。

壓縮表的寫入涉及到解壓數(shù)據(jù)，更新數(shù)據(jù)，再壓縮數(shù)據(jù)，比普通表多了解壓和再壓縮兩個步驟，壓縮和解壓縮需要消耗一定的 CPU 資源。所以需要選擇一個比較優(yōu)化的壓縮算法。

1.5 MySQL 支持的壓縮算法

這塊是 MySQL 所有涉及到壓縮的基礎(chǔ)，不僅僅用于壓縮表，也用于其它地方。比如客戶端請求到 MySQL 服務(wù)端的數(shù)據(jù)壓縮；主從之間的壓縮傳輸；利用克隆插件來復(fù)制數(shù)據(jù)庫操作的壓縮傳輸?shù)鹊取?/p>

從下面結(jié)果可以看到 MySQL 支持的壓縮算法為 zlib 和 zstd，MySQL 默認(rèn)壓縮算法為 zlib，當(dāng)然你也可以選擇非 zlib 算法，比如 zstd。至于哪種壓縮算法最優(yōu)，暫時沒辦法簡單量化，依賴表中的數(shù)據(jù)分布或者業(yè)務(wù)請求。

mysql數(shù)據(jù)庫存儲空間與數(shù)據(jù)大小不一致

阿里云RDS服務(wù)器報(bào)硬盤磁盤空間不足（100G的磁盤空間），登錄后臺查看，使用了130G，使用 SELECT file_name, concat(TOTAL_EXTENTS,'M') as 'FIle_size' FROM INFORMATION_SCHEMA.FILES order by TOTAL_EXTENTS DESC 查看，只使用了60G左右。那么還有70G是怎么用了呢？

查看問題：

查詢 information_schema.innodb_trx ，看是哪些語句導(dǎo)致的。

原因：

ibdata文件很大，MySQL實(shí)例可能會 由于長時間不結(jié)束的查詢導(dǎo)致 ibdata1 文件過大且無法收縮，導(dǎo)致實(shí)例空間滿 ，為避免數(shù)據(jù)丟失，RDS會對實(shí)例進(jìn)行自動鎖定，磁盤鎖定之后，將無法進(jìn)行寫入操作

解決方案：

重啟實(shí)例即可

mysql刪除數(shù)據(jù)備份再還原會縮小嗎

以前的小應(yīng)用沒有注意這個問題，現(xiàn)在遇到了mysql表中刪除了100W數(shù)據(jù)，但是體檢只有一點(diǎn)點(diǎn)變小，刪除前是4.7G，刪除后是4.6G。優(yōu)化以后2.2G，哼哼哼哼。。。

查資料知道原因是mysql默認(rèn)是不自動收縮的，所以刪除數(shù)據(jù)體積不會變小。

我們需要手動優(yōu)化來收縮數(shù)據(jù)。

方法一：使用Navicat的最優(yōu)化功能

因?yàn)槲沂鞘褂肗avicat作為工具，所以推薦使用這個功能。選中需要優(yōu)化的表，最優(yōu)化即可。

方法二：運(yùn)行命令優(yōu)化

optimizetable數(shù)據(jù)表名稱

方法三：自動批處理。說白了，還是運(yùn)行命令

建議一個自動運(yùn)行任務(wù)，每隔一段時間自動運(yùn)行一下。