您好,登錄后才能下訂單哦!
這篇文章主要講解了“怎么合理的使用MySQL索引結構和查詢”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“怎么合理的使用MySQL索引結構和查詢”吧!
在MySQL使用的過程中,所謂的性能問題,在大部分的場景下都是指查詢的性能,導致查詢緩慢的根本原因是數據量的不斷變大,解決查詢性能的最常見手段是:針對查詢的業務場景,設計合理的索引結構。
索引的使用并不是越多越好,而是針對業務下的查詢場景,不斷的改進和優化,例如電商系統中用戶訂單的場景,假設存在如下表結構:
CREATE TABLE `ds_user` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵id', `user_name` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶表'; CREATE TABLE `ds_order` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵id', `user_id` int(11) NOT NULL COMMENT '用戶ID', `order_no` varchar(60) NOT NULL COMMENT '訂單號', `product_name` varchar(50) DEFAULT NULL COMMENT '產品名稱', `number` int(11) DEFAULT '1' COMMENT '個數', `unit_price` decimal(10,2) DEFAULT '0.00' COMMENT '單價', `total_price` decimal(10,2) DEFAULT '0.00' COMMENT '總價', `order_state` int(2) DEFAULT '1' COMMENT '1待支付,2已支付,3已發貨,4已簽收', `order_remark` varchar(50) DEFAULT NULL COMMENT '訂單備注', `create_time` datetime DEFAULT NULL COMMENT '創建時間', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='訂單表';
用戶和訂單的管理表,在電商的業務中很常見,可以通過對該業務分析,看看常用的索引結構:
用戶方:
基于用戶的查詢,多數是基于用戶ID(user_id);
基于訂單號(order_no),查看物流的信息;
運營方:
基于時間段的流水明細(create_time)或排序;
基于訂單狀態的篩選(order_state)和統計;
基于產品(product_name)的數據統計分析;
這樣一個流程分析走下來,即可以在開發初期,確定哪些結構是查詢必須用到的,預先做好索引結構,避免數據量龐大到影響性能時再去考慮使用索引。
有些時候會考慮放棄一些查詢條件,例如基于產品名稱的數據統計,走定時任務的方式,用來緩解表的查詢壓力,處理的方式是多樣的。
優秀的索引設計,都是建立在對業務數據的理解上,考慮業務數據的查詢方式,提高查詢效率。
單列索引,即索引建立在表的一個字段上,一個表可以有多個單列索引,使用起來相對比較簡單:
CREATE INDEX user_id_index ON ds_order(user_id) USING BTREE;
主鍵索引,或者上述的user_id_index都是單列索引。
業務場景:基于用戶自己對訂單查詢,和管理系統,訂單和用戶的關聯查詢,所以訂單表的user_id需要一個索引。
組合索引包含兩個或兩個以上的列,組合索引相比單列索引復雜很多,如何建立組合索引,和業務關聯度非常高,在使用組合索引時,還需要考慮查詢條件的順序。
CREATE INDEX state_create_time_index ON `ds_order`(`create_time`,`order_state`);
如上就是組合索引,實際包含的是2個索引 (create_time) (create_time,order_state),這樣查詢就涉及到最左前綴的原則,必須按照順序來查詢,這里下面詳說。
業務場景:首先單說這里組合索引,在業務開發中,常見訂單狀態的統計,基于統計結果做運營分析,另外就是在運營系統中,基于創建時間段的篩選條件是默認存在的,避免全部數據實時掃描;一些其他的常見查詢也都是條件加時間段的查詢模式。
如果需要加索引的列是很長的字符串,那么索引會變的龐大臃腫,起到的效果可能并不是很明顯。這時候可以截取列的前面一部分,創建索引,節省空間,這樣可能會出現索引的選擇性下降,即基于前綴索引查詢出的相似數據可能很多:
ALTER TABLE ds_order ADD KEY (order_no(30)) ;
這里由于訂單號太長,所以選擇前面30位作為前綴索引,用作訂單號的查詢,當然這里涉及到一個非常經典的業務場景,訂單號機制。
業務場景:前綴索引一個典型的應用場景就是處理訂單號,一個看似很長的訂單號,其實包含的信息非常多:
時間點:就是訂單生成的時間,年月日時分秒;
標識位:即一個唯一的UID,保證訂全單號唯一;
埋點一:在很多業務中,在訂單號記錄產品類目;
埋點二:通常會標識產品屬性,例如顏色,口味等;
錯位符:防止訂單號被分析,會隨機一段錯位符號;
如此一段分析下來,實際訂單號是非常長的,所以需要引入前綴索引機制,前綴索引期望使用的索引長度可以篩選整個列的基數,例如上面的訂單號:
大部分業務基于時間節點篩選足夠,即索引長度14位;
如果是并發業務,很多時間節點相同,則索引長度是時間點+標識位;
注意:如果業務允許的情況下,一般要求前綴索引的長度有唯一性,例如上面的時間和標示位。
例如全文索引等,這些用到的場景不多,如果數據龐大,又需要檢索等,通常會選擇強大的搜索中間件來處理。顯式唯一索引,這種也會在程序上做規避,避免不友好的異常被拋出。
如何創建最優的索引,是一件不容易的事情,同樣在查詢的時候,是否使用索引也是一件難度極大的事情,經驗之談:多數是性能問題暴露的時候,才會回頭審視查詢的SQL語句,針對性能問題,做相應的查詢優化。
這里直接查詢主鍵索引,MySQL的主鍵一般選擇自增,所以速度非常快。
EXPLAIN SELECT * FROM ds_order WHERE id=2; EXPLAIN SELECT * FROM ds_order WHERE id=1+1; EXPLAIN SELECT * FROM ds_order WHERE id+1=1;
這里,id=2,id=1+1,MySQL都可以自動解析,但是id+1是在索引列上執行運算,直接導致主鍵索引失效。這里有一個基本策略,如果非要在單列索引上做操作,可以將該邏輯放在程序中,到MySQL層面,SQL語句越干凈利落越好。
前綴索引的查詢,可以基于Like對特定長度篩選,或者全訂單號查詢。
EXPLAIN SELECT * FROM ds_order WHERE order_no LIKE '202008011314158723628732871625%'; EXPLAIN SELECT * FROM ds_order WHERE order_no='20200801131415872362873287162572367';
查詢最麻煩的就是組合索引,或者說查詢條件組合起來,都使用了索引:
EXPLAIN SELECT * FROM ds_order WHERE create_time>'2020-08-01 00:00:00' AND order_state='1';
上述基于組合索引中列的順序,使用了組合索引:state_create_time_index。
EXPLAIN SELECT * FROM ds_order WHERE create_time>'2020-08-01 00:00:00';
上述只使用create_time列,也同樣使用了索引結構。
EXPLAIN SELECT * FROM ds_order WHERE order_state='1';
上述如果只使用order_state條件,則結果顯示全表掃描。
EXPLAIN SELECT * FROM ds_order WHERE create_time>'2020-08-01 00:00:00' AND order_no LIKE '20200801%';
上述則基于組合索引的create_time列和單列索引order_no保證查詢條件都使用了索引。
通過上面幾個查詢案例,索引組合索引使用的注意事項如下:
組合索引必須按索引最左列開始查詢;
不能跳過組合字段查詢,這樣無法使用索引。
感謝各位的閱讀,以上就是“怎么合理的使用MySQL索引結構和查詢”的內容了,經過本文的學習后,相信大家對怎么合理的使用MySQL索引結構和查詢這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。