（5）MySQL進階篇SQL優化（優化資料庫對象）

2021 年 4 月 8 日
筆記
MySQL進階篇

1.概述

在資料庫設計過程中，用戶可能會經常遇到這種問題：是否應該把所有表都按照第三範式來設計？表裡面的欄位到底改設置為多大長度合適？這些問題雖然很小，但是如果設計不當則可能會給將來的應用帶來很多的性能問題。本章中將介紹MySQL中一些資料庫對象的優化方法，其中一些方法不僅僅適用於MySQL，也適用於其他類型的資料庫管理系統。

2.優化表的數據類型

表需要使用任何的數據類型，是需要根據應用程式來判斷的。雖然應用程式設計的時候需要考慮欄位的長度留有一定的冗餘，但是不推薦讓很多欄位都留有大量的冗餘，這樣即浪費磁碟存儲空間,同時在應用程式操作時也浪費物理記憶體。在MySQL中，可以使用函數PROCEDURE ANALYSE()對當前應用的表進行分析，該函數可以對數據表中列的數據類型提出優化建議，用戶可以根據應用的實際情況酌情考慮是否實施優化。以下是函數PROCEDURE ANALYSE()的使用方法：

SELECT * FROM tbl_name PROCEDURE ANALYSE();
SELECT * FROM tbl_name PROCEDURE ANALYSE(16,256);

但是我在8.0以上版本的MySQL上執行這條語句是報錯的，具體是8.0版本不支援還是改變語法，這邊就暫時不深究了，有空再查官網資料了解下。

3.通過拆分提高表的訪問效率

這裡所說的「拆分」，是指對數據表進行拆分。如果針對MyISAM類型的表進行，那麼有兩種拆分方法。
●第一種方法是垂直拆分，即把主鍵和一些列放到一個表，然後把主鍵和另外的列放到另一個表中。
優點：如果一個表中某些列常用，而另外一些列不常用，則可以採用垂直拆分，另外垂直拆分可以使得數據行變小，一個數據頁就能存放更多的數據，在查詢時就會減少I/O次數。
缺點：需要管理冗餘列，查詢所有數據需要聯合（JOIN）操作。
●第二種方法是水平拆分，即根據一列或多列數據的值把數據行放到兩個獨立的表中。水平拆分通常在以下幾種情況下使用：
◎表很大，分割後可以降低在查詢時需要讀的數據和索引的頁數，同時也降低了索引的層數，提高查詢速度。
◎表中的數據本來就有獨立性，例如，表中分別記錄各個地區的數據或不同時期的數據，特別是有些數據常用，而另外一些數據不常用。
◎需要把數據存放到多個介質上。例如，行動電話的賬單表就可以分成兩個表或多個表。最近3個月的賬單數據存在一個表中，3個月前的歷史賬單存放在另外一個表中，超過1年的歷史賬單可以存儲到單獨的存儲介質上，這種拆分是最常使用的水平拆分方法。
註：水平拆分會給應用系統增加複雜度，它通常在查詢時需要多個表名，查詢所有數據需要UNION操作。在許多資料庫應用中，這種複雜性會超過它帶來的優點，因為只要索引關鍵字不大，則在索引用於查詢時，表中增加2至3倍數據量，查詢時也就增加讀一個索引層的磁碟次數，所以水平拆分要考慮數據量的增長速度，根據實際情況決定是否需要對錶進行水平拆分。

4.逆規範化

●資料庫設計時要滿足規範化這個道理大家都非常清楚，但是否數據的規範化程度越高越好呢？這還是由實際需求來決定。因為規範化越高，那麼產生的關係就越多，關係過多的直接結果就是導致表之間的連接操作越頻繁，而表之間的連接操作是性能較低的操作，直接影響到查詢的速度，所以對於查詢較多的應用程式就需要根據實際情況運用逆規範化對數據進行設計，通過逆規範化來提高查詢的性能。
例如，一般電商平台後台的庫存列表都會包含商家名稱等資訊，方便管理人員查看，假設商家ID、名字和其他屬性都存放在一個商家資訊表A中，而庫存型號、品牌、庫存量、商家ID和其他屬性都存放在一個庫存資訊表B中，那麼我們在庫存列表中要顯示商家名稱等資訊時，就必須要在資料庫中進行表連接，因為庫存資訊表B中並不包含商家資訊表A的商家名稱等資訊，所以必須通過關聯A表把數據取過來，如果在資料庫設計時就考慮到這一點，就可以在B表增加一個冗餘欄位存放商家名字數據，這樣在查詢庫存列表時就不用再做表關聯了，這樣也可以使查詢有更好的性能。
●反規範的好處是降低連接操作的需求、降低外鍵和索引的數目，還可能減少表的數目，相應帶來的問題是可能出現數據的完整性問題。加快查詢速度，但會降低修改速度。因此決定做反規範時，一定要權衡利弊，仔細分析應用程式的數據存取需求和實際的性能特點，好的索引和其他方法經常能夠解決性能問題，而不必採用反規範這種方法。
●在進行反規範操作之前，要充分考慮數據的存取需求、常用表的大小、一些特殊的計算（例如合計）、數據的物理存儲位置等。常用的反規範技術有增加冗餘列、增加派生列、重新組表和分割表。
◎增加冗餘列：指在多個表中具有相同的列，它常用來在查詢時避免連接操作。
◎增加派生列：指增加的列來自其他表中的數據，由其他表中的數據經過計算生成。增加的派生列其作用是在查詢時減少連接操作，避免使用集函數。
◎重新組表：指如果許多用戶需要查看兩個表連接出來的結果數據，則把這兩個表重新組成一個表來減少連接而提高性能。
◎分割表：可以參見3小節「通過拆分提高表的訪問效率」的內容。
●另外，逆規範技術需要維護數據的完整性。無論使用何種反規範技術，都需要一定的管理來維護數據的完整性，常用的方法是批處理維護、應用程式邏輯和觸發器。
◎批處理維護是指對複製列或派生列的修改積累一定的時間後，運行一批處理作業或存儲過程對複製或派生列進行修改，這隻能在對實時性要求不高的情況下使用。
◎數據的完整性也可由應用程式邏輯來實現，這就要求必須在同一事務中對所有涉及的表進行增、刪、改操作。用應用程式邏輯來實現數據的完整性風險較大，因為同一邏輯必須在所有的應用程式中使用和維護，容易遺漏，特別是在需求變化時，不易於維護。
◎另一種方式就是使用觸發器，對數據的任何修改立即觸發對複製列或派生列的相應修改。觸發器是實時的，而且相應的處理邏輯只在一個地方出現，易於維護。一般來說，是解決這類問題比較好的辦法。

5.使用中間表提高統計查詢速度

對於數據量較大的表，在其上進行統計查詢通常會效率很低，並且還要考慮統計查詢是否會對在線的應用程式產生負面影響。通常在這種情況下，使用中間表可以提高統計查詢的效率，下面通過對goods_stock庫存表的統計來介紹中間表的使用，goods_stock表記錄了每天庫存導入記錄，表結構如下：

DESC goods_stock;

由於每天都會產生大量的庫存導入記錄，所以goods_stock表的數據量很大，導致分頁查詢庫存導入數據很慢：

現在業務部門有一具體的需求：希望了解最近30天入庫總庫存量。針對這一需求我們通過兩種方法來得出業務部門想要的結果。
方法1：在goods_stock表上直接進行統計，得出想要的結果：

SELECT SUM(StockQty) AS TotalStockQty FROM goods_stock WHERE CreateTime>ADDDATE(NOW(),-30);

方法2：創建中間表tmp_goods_stock，表結構和源表結構完全相同：

CREATE TABLE `tmp_goods_stock`  (
  `ID` bigint NOT NULL AUTO_INCREMENT COMMENT '供應商庫存ID',
  `StockGUID` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '用於與子表對應',
  `Model` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '型號',
  `Brand` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT '' COMMENT '品牌,標準名稱',
  `LotNO` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT '' COMMENT '批次，一般用四位年份+兩位周，如：202024',
  `MinPackageQty` int NOT NULL DEFAULT 0 COMMENT '最小包裝量',
  `PackageUnit` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT '' COMMENT '包裝單位,包裝類型',
  `StockQty` int NOT NULL DEFAULT 0 COMMENT '庫存量，數量單位：PCS',
  `MinOrderQty` int NOT NULL DEFAULT 0 COMMENT '最小起訂量',
  `IncQty` int NOT NULL DEFAULT 0 COMMENT '增量',
  `StockType` smallint NOT NULL COMMENT '物料類型 10:供應商現貨 20供應商排單 30 雲倉現貨',
  `CreateTime` datetime(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0),
  `UpdateTime` datetime(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0),
  PRIMARY KEY (`ID`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 424449 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci COMMENT = '商品庫存資訊，供應商物料庫存' ROW_FORMAT = Dynamic;

轉移要統計的數據到中間表，然後在中間表上進行統計，得出想要的結果：

INSERT INTO tmp_goods_stock SELECT * FROM goods_stock WHERE CreateTime>ADDDATE(NOW(),-30);

SELECT SUM(StockQty) AS TotalStockQty FROM tmp_goods_stock;

從上面的兩種實現方法上看，在中間表中做統計花費的時間很少（這裡不計算轉移數據花費的時間），另外，針對業務部門想了解「希望了解最近30天入庫總庫存量」這一需求，在中間表上給出統計結果更為合適，原因是源數據表（goods_stock表）CreateTime欄位並沒有索引並且源表的數據量較大，所以在按時間進行分時段統計時效率很低，這時可以在中間表上對CreateTime欄位創建單獨的索引來提高統計查詢的速度。中間表在統計查詢中經常會用到，其優點如下：
●中間表複製源表部分數據，並且與源表相「隔離」，在中間表上做統計查詢不會對在線應用程式產生負面影響。
●中間表上可以靈活的添加索引或增加臨時用的新欄位，從而達到提高統計查詢效率和輔助統計查詢作用。

6.總結

本章節介紹了對資料庫對象的優化，資料庫對象設計的好壞是一個資料庫設計的基礎，而且一旦資料庫對象設計完畢並投入使用，將來再進行修改就比較麻煩，因此在進行資料庫設計的時候一定要儘可能地考慮周到。

參考文獻：
深入淺出MySQL大全

Tags: MySQL進階篇