文件首頁
MySQL 8.4 參考手冊
相關文件 下載本手冊
PDF (美國信件尺寸) - 39.9Mb
PDF (A4) - 40.0Mb
Man Pages (TGZ) - 258.5Kb
Man Pages (Zip) - 365.5Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 8.4 參考手冊  /  ...  /  優化資料大小

10.4.1 優化資料大小

設計您的表格,使其在磁碟上的空間最小化。這可以透過減少寫入和從磁碟讀取的資料量來大幅改進效能。較小的表格通常在查詢執行期間主動處理其內容時,需要較少的主記憶體。表格資料的任何空間減少也會導致可以更快處理的較小索引。

MySQL 支援許多不同的儲存引擎(表格類型)和列格式。對於每個表格,您可以決定要使用哪個儲存和索引方法。為您的應用程式選擇適當的表格格式可以為您帶來很大的效能提升。請參閱第 17 章,InnoDB 儲存引擎,以及第 18 章,替代儲存引擎

您可以透過使用此處列出的技術來獲得更好的表格效能並最小化儲存空間

表格欄位

  • 使用最有效率(最小)的資料類型。MySQL 有許多專門的類型可以節省磁碟空間和記憶體。例如,如果可能的話,請使用較小的整數類型來取得較小的表格。 MEDIUMINT 通常是比 INT 更好的選擇,因為 MEDIUMINT 欄位使用的空間少 25%。

  • 如果可能的話,請將欄位宣告為 NOT NULL。它可以透過更好地使用索引並消除測試每個值是否為 NULL 的額外負荷來加快 SQL 操作的速度。您還可以節省一些儲存空間,每個欄位一位元。如果您的表格中確實需要 NULL 值,請使用它們。只需避免在每個欄位中允許 NULL 值的預設設定即可。

列格式

  • InnoDB 表格預設是使用 DYNAMIC 列格式建立的。若要使用 DYNAMIC 以外的列格式,請設定 innodb_default_row_format,或在 CREATE TABLEALTER TABLE 陳述式中明確指定 ROW_FORMAT 選項。

    緊湊型列格式系列(包括 COMPACTDYNAMICCOMPRESSED)會減少列儲存空間,但代價是增加了某些操作的 CPU 使用率。如果您的工作負載是受快取命中率和磁碟速度限制的典型工作負載,則可能會更快。如果它是一個受 CPU 速度限制的罕見案例,則可能會較慢。

    當使用可變長度字元集(例如 utf8mb3utf8mb4)時,緊湊型列格式系列也優化了 CHAR 資料行的儲存。使用 ROW_FORMAT=REDUNDANT 時,CHAR(N) 佔用 N × 字元集的最大位元組長度。許多語言主要可以使用單位元組的 utf8mb3utf8mb4 字元來撰寫,因此固定的儲存長度通常會浪費空間。使用緊湊型列格式系列,InnoDB 會為這些資料行配置 NN × 字元集的最大位元組長度範圍內的可變儲存空間,方法是去除尾隨空格。最小儲存長度為 N 位元組,以便在典型情況下方便進行就地更新。如需更多資訊,請參閱第 17.10 節「InnoDB 列格式」

  • 為了透過以壓縮形式儲存表格資料來進一步縮小空間,在建立 InnoDB 表格時指定 ROW_FORMAT=COMPRESSED,或在現有的 MyISAM 表格上執行 myisampack 命令。(InnoDB 壓縮表格是可讀寫的,而 MyISAM 壓縮表格是唯讀的。)

  • 對於 MyISAM 表格,如果您沒有任何可變長度的資料行(VARCHARTEXTBLOB 資料行),則會使用固定大小的列格式。這樣速度更快,但可能會浪費一些空間。請參閱第 18.2.3 節「MyISAM 表格儲存格式」。您可以使用 CREATE TABLE 選項 ROW_FORMAT=FIXED 來提示您想要擁有固定長度的列,即使您有 VARCHAR 資料行。

索引

  • 表格的主索引應該盡可能短。這使得識別每個列變得容易且有效率。對於 InnoDB 表格,主索引鍵資料行會在每個次要索引項目中重複,因此如果您有很多次要索引,則短主索引鍵可以節省大量空間。

  • 僅建立您需要用於改進查詢效能的索引。索引對於擷取很有用,但會減慢插入和更新操作。如果您主要透過搜尋資料行的組合來存取表格,請在它們上建立單一的複合索引,而不是為每個資料行建立個別的索引。索引的第一部分應該是最常用的資料行。如果您在從表格中選取時總是使用許多資料行,則索引中的第一個資料行應該是重複次數最多的那個,以便獲得更好的索引壓縮。

  • 如果長字串資料行很可能在首幾個字元上具有唯一的前綴,則最好僅針對此前綴建立索引,使用 MySQL 對於在資料行的最左部分建立索引的支援(請參閱第 15.1.15 節「CREATE INDEX 陳述式」)。較短的索引速度更快,不僅是因為它們需要較少的磁碟空間,還因為它們可以在索引快取中提供更多命中次數,從而減少磁碟搜尋次數。請參閱第 7.1.1 節「配置伺服器」

聯結

  • 在某些情況下,將經常掃描的表格分成兩個表格可能會很有益處。如果它是動態格式的表格,並且可以透過使用較小的靜態格式表格來尋找掃描表格時的相關列,則情況尤其如此。

  • 以相同的資料類型宣告不同表格中具有相同資訊的資料行,以加速基於相應資料行的聯結。

  • 保持資料行名稱簡單,以便您可以在不同的表格中使用相同的名稱,並簡化聯結查詢。例如,在名為 customer 的表格中,使用 name 的資料行名稱,而不是 customer_name。為了使您的名稱可移植到其他 SQL 伺服器,請考慮將它們保持在 18 個字元以下。

正規化

  • 通常,請嘗試保持所有資料非冗餘(觀察資料庫理論中稱為第三正規形式的內容)。不要重複冗長的值,例如姓名和地址,而是為它們分配唯一 ID,在多個較小的表格中根據需要重複這些 ID,並透過在聯結子句中引用 ID 來聯結查詢中的表格。

  • 如果速度比磁碟空間和維護多個資料副本的成本更重要,例如在商業智慧情境中,您會分析來自大型表格的所有資料,則您可以放寬正規化規則,複製資訊或建立摘要表格以獲得更高的速度。