（5）MySQL進階篇SQL優化（優化數據庫對象）

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大全