我們在工作中時常會遇到一些客戶的tps\qps都不太高,但磁碟占用非常大,一旦單例項空間太大，像記憶體、網路、cpu以及備份都將增加相應的開銷。可能僅僅是由於空間不滿足使得我們不得不進行擴容，下面的方法提供給大家參考。有則改之無則加勉。
1、表結構設計上
1) 字符集是否遵循了最小化原則?(能用lati程式設計客棧n的就不用gbk。能用gbk的就不用utf8)
2) 索引上是否有濫用？(根本不使用的字段建索引、不適合建索引的字段建索引、重複建索引或者不能很好的利用字首索引等)
3) 冗餘字段是否太多？(各表中不用的或者字段冗餘太多)
4) 不正確的字段型別？(能用1個位元組非要用幾個位元組，像列舉類、狀態模擬較常見)
5) 將較長的字段或者幾個字段組合做為主鍵？（主鍵最好用mysql自增）
具體事例如下：
create table `class_meta` (
`class_name` varchar(128) not null comment '類名',
`class_desc` varchar(2048) default '' comment '類的描述',
`class_status` char(20) default 'test1' comment 'test1,test程式設計客棧2',
primary key (`class_name`),
unique key `cm_cn_uk` (`class_name`),
key `cm_cd_ind` (`class_desc`(767)),
key `cm_cs_ind` (`class_status`),
key `cm_cdcn_ind` (`class_desc`(767),`class_name`)
) engine=innodb default charset=latin1 comment='meta資訊';
通過上面的表結構能看到如下地方不合適
1、主鍵與唯一索引明顯重複,索引cm_cd_ind與索引cm_cdcn_ind索引重複（這種情況經常出現，大家留意下）
2、cm_cs_ind如果兩個狀態分布均勻也明顯不合適建索引
3、class_desc由於是描述性質的，也不合適建索引
4、最好以自增做為主鍵，可以減少整表的空間
5、class_status列明顯可以用tinyint來存，可以省下19個位元組
2、儲存內容上
1) 是否將、**、**等大資料儲存在表中？(表裡最好只保留路徑而不是實際的檔案內容)
3、資料保留上
1)是否有已過期而未刪除的資料?(對於無效資料及時清理或者進行歷史歸檔)
4、後期維護上
1)是否對經常刪除的表進行維護(optimize table)
建議:1、在效能要求不高的case中(併發不太高)，可以考慮使用壓縮表。一般壓縮率在30%-70%之間，收益非常可觀。
2、對於刪除非常頻繁的表要定期進行優化，使表中碎片減少。提高查詢、寫入的效能。
3、在表結構設計上，一定要發揚「斤斤計較」的精神，能用1個位元組表示的堅決不用2個位元組。
4、儘量減少大字段的使用。
ps:經常在跟開發評審表結構的時候，時常會被笑話說dba太摳門，一點都不大氣。當資料量小的時候可能大家不覺得，但當你的資料級到t或者p的時候，哪怕多省幾個位元組都是非常可觀的，給大家簡程式設計客棧單算筆賬，如果我們將一張5億條記錄的表，欄位從100個位元組降到60個位元組(應該程式設計客棧很容易做到吧)，那麼不算上索引將節約大約18g的空間。
本文標題: 幾個縮減mysql以節省磁碟空間的建議
本文位址: /shujuku/mysql/124261.html
MySQL中查詢磁碟空間
查詢所有資料庫占用磁碟空間大小的sql語句 select table schema,concat truncate sum data length 1024 1024,2 mb as data size,concat truncate sum index length 1024 1024,2 mb ...
檢視mysql占用磁碟空間
查詢所有資料庫占用磁碟空間大小的sql語句 select table schema,concat truncate sum data length 1024 1024,2 mb as data size,concat truncate sum index length 1024 1024,2 mb ...
系統目錄WINDOWS下幾個占用磁碟空間較大的目錄
1 c windows servicepackfiles servicepackfiles 資料夾中包含由 service pack 安裝的 windows xp 系統檔案的更新版本。在安裝了其他元件時，為確保使用最新的檔案版本，需要用到此資料夾。windows 檔案保護系統也使用此資料夾來還原損壞...