MYSQL 5.5.20 數(shù)據(jù)庫哪里壓縮數(shù)據(jù)庫 怎么壓縮數(shù)據(jù)庫

9月16日 13:31

創(chuàng)新互聯(lián)主要為客戶提供服務(wù)項(xiàng)目涵蓋了網(wǎng)頁視覺設(shè)計(jì)、VI標(biāo)志設(shè)計(jì)、營銷推廣、網(wǎng)站程序開發(fā)、HTML5響應(yīng)式成都網(wǎng)站建設(shè)、手機(jī)網(wǎng)站制作設(shè)計(jì)、微商城、網(wǎng)站托管及網(wǎng)站維護(hù)、WEB系統(tǒng)開發(fā)、域名注冊(cè)、國內(nèi)外服務(wù)器租用、視頻、平面設(shè)計(jì)、SEO優(yōu)化排名。設(shè)計(jì)、前端、后端三個(gè)建站步驟的完善服務(wù)體系。一人跟蹤測試的建站服務(wù)標(biāo)準(zhǔn)。已經(jīng)為效果圖設(shè)計(jì)行業(yè)客戶提供了網(wǎng)站開發(fā)服務(wù)。

一. 安裝DBI模塊

步驟1：

從TOOLS欄目中下載DBI.zip,下載完后用winzip解開到一個(gè)temp目錄,共有三個(gè)文件：

Readme

DBI.ppd

DBI.tar.gz

步驟2：

在DOS窗口下，temp目錄中運(yùn)行下面的DOS命令：

ppm install DBI.ppd

如果提示無效命令,可在perl/bin目錄下運(yùn)行

如何使用mysqldump進(jìn)行壓縮備份

通用規(guī)律只有使用 --all-databases (-A) 會(huì) ERROR 1356，那就看看他到底備份了什么東西。于是喊上同事一起 less 看了下，上下掃了兩眼。突然發(fā)現(xiàn)：1. 備份 SQL 文件里 DROP 掉了 mysql.proc；2. 后CREATE了一個(gè)新的 mysql.proc；3. LOCK TABLES 和 UNLOCK TABLES 中間居然沒有備份 CREATE ROUTINE 任何數(shù)據(jù)？這不就是相當(dāng)于每次導(dǎo)入全備都給我一個(gè)沒有任何 sys schema routines 的全新 mysql.proc 表？那這不就異常的尷尬？

---- Table structure for table `proc`--

---- Dumping data for table `proc`-

真相大白在官方文檔【sys-schema-usage】官方文檔明確的告訴我們不會(huì)備份 sys 庫。但在使用 mysqldump 在執(zhí)行 --all-databases 會(huì)清空 mysql.proc 導(dǎo)致 sys 無法正常使用；這是一個(gè) BUG，并且只存在于 MySQL 5.7.x ！

1、mysql_upgrade install or upgrade sys schema

這個(gè)方案適用于 sys 庫已經(jīng)因?yàn)?mysqldump 導(dǎo)入而損壞的情況下使用。

注意：mysql_upgrade 在修理 sys 庫的同時(shí)，還修理 mysql 庫和用戶庫表（期間加鎖且速度一般），有極小可能會(huì)誤傷；使用 mysql_upgrade 的時(shí)候要加上 --upgrade-system-tables，不然會(huì)掃描用戶庫表。

2、全備時(shí)同時(shí)備份 sys 庫

這個(gè)方案適用于需要還原的數(shù)據(jù)庫，sys 庫也不太正常的情況下使用；在全備后額外再備份一份 sys 庫用于修復(fù)。

注意：不適用于做主從時(shí)使用它。

3、使用 databases 全備

這個(gè)方案適用于所有場景的全備需求，100% 安全。

4、使用 mysql-sys 開源代碼

如果你的數(shù)據(jù)庫 sys 全部中招了，又是生產(chǎn)庫。那你只能用這個(gè)方法；

mysql-sys：

中記錄了 sys 庫的創(chuàng)建語句將文件下載到本地，然后根據(jù)數(shù)據(jù)庫版本，執(zhí)行以下命令即可。

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

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

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

表壓縮后從磁盤占用上看要比原始表要小很多。如果你熟悉列式數(shù)據(jù)庫，那對(duì)這個(gè)概念一定不陌生。比如，基于 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ù)損壞。這個(gè)時(shí)候就算通過 Redo Log 也恢復(fù)不了，因?yàn)閹缀跤兴械年P(guān)系數(shù)據(jù)庫采用的 Redo Log 都記錄了數(shù)據(jù)頁的偏移量，此時(shí)就算通過 Redo Log 恢復(fù)后，數(shù)據(jù)也是錯(cuò)誤的。所以 MySQL 在刷臟數(shù)據(jù)之前，會(huì)把這部分?jǐn)?shù)據(jù)先寫入共享表空間里的 DOUBLE WRITE BUFFER 區(qū)域來避免這種異常。此時(shí)如果 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)非常明顯，占用磁盤空間小！由于占用空間小，從磁盤置換到內(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ù)，比普通表多了解壓和再壓縮兩個(gè)步驟，壓縮和解壓縮需要消耗一定的 CPU 資源。所以需要選擇一個(gè)比較優(yōu)化的壓縮算法。

1.5 MySQL 支持的壓縮算法

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

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

怎么樣把mysql數(shù)據(jù)庫備份成.zip格式

為什么要備份成 zip 呢？是為了變成一個(gè)包攜帶方便嗎？ mysqldump 也可以將整個(gè)數(shù)據(jù)庫導(dǎo)出成單個(gè)文件的，如果要變成 zip ，你再用 winrar 對(duì)導(dǎo)出后的文件壓縮一下就行了。