MySQL中建立及優化索引組織結構的思路

【導讀】

經過一個實際生產環境中的數據存取需求，分析如何設計此存儲結構，如何操縱存儲的數據，以及如何使操做的成本或代價更低，系統開銷最小。同時，讓更多初學者明白數據存儲的表上索引是如何一個思路組織起來的，但願起到一個參考模板的價值做用。

 

n  測試用例描述

測試用例爲B2C領域，一張用於存儲用戶選購物品而生成的產品訂單信息表，不過去掉一些其餘字段，以便用於測試，其表中的數據項也不特別描述，字段意思見表

USE `test`;

DROP TABLE IF EXISTS `test`.`goods_order`;

CREATE TABLE `goods_order`(

`order_id`        INT UNSIGNED      NOT NULL             COMMENT ‘訂單單號’,

`goods_id`        INT UNSIGNED      NOT NULL DEFAULT ’0′ COMMENT ‘商品款號’,

`order_type`      TINYINT UNSIGNED  NOT NULL DEFAULT ’0′ COMMENT ‘訂單類型’,

`order_status`    TINYINT UNSIGNED  NOT NULL DEFAULT ’0′ COMMENT ‘訂單狀態’,

`color_id`        SMALLINT  UNSIGNED NOT NULL DEFAULT ’0′ COMMENT ‘顏色id’,

`size_id`         SMALLINT  UNSIGNED NOT NULL DEFAULT ’0′ COMMENT ‘尺寸id’,

`goods_number`    MEDIUMINT  UNSIGNED NOT NULL DEFAULT ’0′ COMMENT ‘數量’,

`depot_id`        INT UNSIGNED  NOT NULL DEFAULT ’0′ COMMENT ‘倉庫id’,

`packet_id`       INT UNSIGNED  NOT NULL DEFAULT ’0′ COMMENT ‘儲位code’,

`gmt_create`      TIMESTAMP     NOT NULL DEFAULT ’0000-00-00 00:00:00′ COMMENT ‘添加時間’,

`gmt_modify`      TIMESTAMP     NOT NULL DEFAULT ’0000-00-00 00:00:00′ COMMENT ‘更新時間’,

PRIMARY KEY(order_id,`goods_id`)

)ENGINE=InnoDB AUTO_INCREMENT=1 CHARACTER SET ‘utf8′ COLLATE ‘utf8_general_ci’;

其中，主鍵信息：PRIMARY KEY(order_id,`goods_id`)，爲什麼主鍵索引索引字段的順序爲：order_id,`goods_id`，而不是： `goods_id`, order_id呢？緣由很簡單，goods_id在訂單信息表中的重複率會比order_id高，也即order_id的篩選率更高，能夠減小掃描索引 記錄個數，從而達到更高的效率，同時，下面即將會列出的SQL也告訴咱們，有部分SQL語句的WHERE字句中只出現order_id字段，爲此更加堅決 咱們必須把字段：order_id做爲聯合主鍵索引的頭部，`goods_id`爲聯合主鍵索引的尾部。

數據存儲表設計的小結：

設計用於存儲數據的表結構，首先要知道有哪些數據項，也即行內常說的數據流，以及各個數據項的屬性，好比存儲的數據類型、值域範圍及長度、數據完整性等要求，從而肯定數據項的屬性定義。存儲的數據項信息肯定以後，至少進行以下三步分析：

l  首先，肯定哪些數據項或組合，能夠做爲記錄的惟一性標誌；

l  其次，要肯定對數據記錄有哪些操做，每一個操做的頻率如何，對網站等類型應用，還須要區分前臺操做和後臺操做，也即分外部用戶的操做，仍是內部用戶的操做；

l  最後，對做爲數據記錄操做的條件部分的數據項，分析其數據項的篩選率如何，也即數據項不一樣值佔總數據記錄數的比例關心，比例越接近1則是篩選率越好，以及各個值得分佈率；

綜上所述，再讓數據修改性操做優先級別高於只讀性操做，就能夠建立一個知足要求且性能較好的索引組織結構。

數據的存取設計,就涉及一塊很是重要的知識: 關係數據庫的基礎知識和關係數據理論的範式。對於範式的知識點，特別解釋下，建議學到BCNF範式爲止，1NF、2NF、3NF和BCNF之間的差異，各 自規避的問題、存在的缺陷都要一清二楚，可是在真實的工做環境中，不要任何存取設計都想向範式靠，用一句佛語準確點表達：空便是色，色便是空。

n  用於生成測試數據的存儲過程代碼

建立索引，就離不開表存儲的真實數據，爲此編寫一個存儲過程近可能模擬真實生產環境中的數據，同時也方便你們使用此存儲過程，在本身的測試環境中，真實感覺驗證，

存儲過程代碼：

DELIMITER $$

DROP PROCEDURE IF EXISTS `usp_make_data` $$

CREATE PROCEDURE `usp_make_data`()

BEGIN

DECLARE iv_goods_id INT UNSIGNED DEFAULT 0;

DECLARE iv_depot_id INT UNSIGNED DEFAULT 0;

DECLARE iv_packet_id INT UNSIGNED DEFAULT 0;

 

SET iv_goods_id=5000;

SET iv_depot_id=10;

SET iv_packet_id=20;

 

WHILE iv_goods_id>0

DO

START  TRANSACTION;

WHILE iv_depot_id>0

DO

WHILE iv_packet_id>0

DO

INSERT INTO goods_order(order_id,goods_id,order_type,order_status,color_id,size_id,goods_number,depot_id,packet_id,gmt_create,gmt_modify)

VALUES(SUBSTRING(RAND(),3,8),iv_goods_id,SUBSTRING(RAND(),3,1),SUBSTRING(RAND(),5,1)%2,SUBSTRING(RAND(),3,3),SUBSTRING(RAND(),4,3),SUBSTRING(RAND(),5,2),

iv_depot_id,SUBSTRING(RAND(),4,2)*iv_packet_id,DATE_ADD(NOW(),INTERVAL -SUBSTRING(RAND(),2,3) DAY),DATE_ADD(NOW(),INTERVAL -SUBSTRING(RAND(),3,2) DAY)

);

SET iv_packet_id=iv_packet_id-1;

END WHILE;

SET iv_packet_id=20;

SET iv_depot_id=iv_depot_id-1;

END WHILE ;

 

COMMIT;

SET iv_depot_id=10;

SET iv_goods_id=iv_goods_id-1;

END WHILE ;

END $$

DELIMITER ;

 

n  業務邏輯描述

l  非註冊用戶，或網站的註冊用戶不登錄，都能可選購買物品，生成訂單號對應的用戶UID爲系統默認的；

l  訂單與用戶UID關聯、描述等信息，存儲其它的表中，經過訂單號的模式關聯；

l  用戶的訂單信息，在未付款以前均可以再修改，付款以後則沒法修改；

l  已經付費的訂單信息，自動發送到物流部門，進行後續工序的操做。處理完畢以後，會更新訂單中涉及物品的存儲位置信息；

l  按期讀取部分數據到數據倉庫分析系統，用於統計分析；

l  我的訂單查詢，先後臺都有；

l  購物記錄查詢顯示；

 

n   根據業務規則描述須要使用操縱數據的SQL語句

(1).      EXPLAIN SELECT * FROM goods_order WHERE `order_id`=40918986;

(2).      SELECT * FROM goods_order WHERE `order_id` IN (40918986,40717328,30923040…) ORDER BY gmt_modify DESC;

(3).      UPDATE goods_order SET gmt_modify=NOW(),…. WHERE  `order_id`=40717328 AND goods_id=4248;

(4).      SELECT COUNT(*) FROM goods_order WHERE depot_id=0 ORDER BY gmt_modify DESC LIMIT 0,50;

(5).      SELECT * FROM goods_order WHERE depot_id=6 AND packet_id=0 ORDER BY gmt_modify DESC LIMIT 0,50;

(6).      SELECT COUNT(*) FROM goods_order WHERE goods_id=4248 AND order_status=0 AND order_type=1

(7).      SELECT * FROM goods_order WHERE goods_id=4248 AND order_status=0 AND order_type=1 ORDER BY gmt_modify DESC LIMIT 0,50;

(8).      SELECT * FROM goods_order WHERE gmt_modify>=’ 2011-04-06’;

8條SQL語句按觸發其執行的用戶分類：

l   前臺用戶點擊觸發的操做而會執行的SQL語句爲：(1)、(2)、(3)；

l   後臺內部用戶點擊觸發的操做而會執行的SQL語句爲：(1)、(2)、(3)、(4)、(5)、(6)、(7)；

l   後臺系統自動按期執行：(4)、(5)、(6)、(7)，工做時間正常狀況每隔15分鐘執行一次，以檢查是否有已付款而沒有準備貨物的訂單、是否有收款而未發貨的訂單等;

l  統計分析系統按期導出數據而執行的SQL語句爲：(8)，頻率爲每24小時一次；

咱們再分析上述列出來的SQL，分爲2類，一類是讀操做的SQL（備註：SELECT操做），另一類爲修改性操做（備註：UPDATE、DELETE操做），分別以下：

SELECT 的WHERE子句、GROUP BY子、ORDER BY 子句和HAVING 子句中，出現的字段：

(1).      order_id

(2).      order_id+gmt_modify

(3).      depot_id+gmt_modify

(4).      depot_id+packet_id+gmt_modify

(5).      goods_id+order_status+order_type

(6).      goods_id+order_status+order_type+gmt_modify

(7).      gmt_modify

修改性操做的WHERE子句中出現的條件字段：

(8).     order_id+ goods_id

 

咱們已經存在主鍵索引：PRIMARY KEY(order_id,`goods_id`)，另外考慮到此表數據的操做以SELECT和INSERT爲主，UPDATE的SQL量其次，再根據上述SQL語句，爲此咱們能夠初步肯定須要建立的索引：

ALTER TABLE goods_order

ADD INDEX idx_goodsID_orderType_orderStatus_gmtmodify(goods_id,order_type,order_status,gmt_modify),

ADD INDEX idx_depotID_packetID_gmtmodify(depot_id,packet_id,gmt_modify);

 

總結：

文章中也分析了爲什麼聯合主鍵索引的順序爲：order_id,`goods_id`，再補充下做爲主鍵的聯合索引的字段屬性的其餘特性：字段值寫入以後不變化、字段值長度短且最好爲數值類型；

對於編號SQL：(8)，天天按更新日期讀取一次數據的操做，以採用全表掃描的方式實現，犧牲其數據讀取的性能，以減小更新字段修改日期的值而帶來的索引維護開銷；

對於編號SQL：(4)、(5)，考慮到每次都是讀取最新的５０條記錄，以及讀取的數據基本上可確定爲熱數據，爲此不得不犧牲其中一條SQL的數據讀取性能，而少建立一個聯合索引，從而減小維護索引字段的IO量；

對於編號SQL：(6)、(7)，建立的聯合索引，須要特別注意聯合索 引：idx_goodsID_orderType_orderStatus_gmtmodify(goods_id,order_type,order_status,gmt_modify) 中的字段順序，其中：

l   goods_id字段的篩選率高於order_type,order_status，另外gmt_modify字段只出如今ORDER BY子句中，爲此只有讓goods_id字段做爲聯合索引的頭部，以提升索引的篩選率，從而提升索引的效率，減小邏輯或物理的讀。

l   order_status字段只有0或1兩種值，而order_type有多種，以及根據SQL語句，必須order_type出如今聯合中的位置要比order_status靠近頭部；

l   gmt_modify字段出如今ORDER BY子句中，爲此必須放到聯合索引字段的最後；

 

最後，再梳理一下從需求到設計存儲結構，再到編寫SQL和建立索引結構，咱們應該作的步驟：

l   整理業務產生的數據流，讀取數據的方式；

l   整理清楚數據流中的每一個數據項屬性信息；

l   分析業務指標，推測須要存儲數據的規模（備註：必定要以多少GB做爲容量單位）；

l   選擇可能用於支持業務的硬件設備和數據庫架構；

l   把全部可能操縱數據的條件和操做類型，都整理清楚；

l   分析操縱數據條件字段各自的數據篩選率；

l   權衡各個SQL的性能和IO量，也即相似於哪一個操做權重高一些，那些操做權重適當低一些；

l   建立索引組織結構；

l   收集測試和生產環境的反饋信息，優化索引組織結構；

 

備註：

本想再用測試環境結合業務的方式，跑一套模擬測試腳本程序，讓你們更加直觀地看到不一樣索引組織狀況下，相同的SQL操做及頻率，數據庫服務器的處理 能力和負載變化及對比信息，惋惜惟一的服務器沒法使用了，只好放棄。對於分析相同的SQL，走不通索引，其須要的邏輯IO和物理IO量也是一個辦法，這次 就不分析了，有須要的朋友能夠去玩玩，另外建議初學者必定要好好閱讀下mysql 手冊上的相關章節內容：7.2.6. Index Merge Optimization。