索引相似大學圖書館建書目索引,能夠提升數據檢索的效率,下降數據庫的IO成本。MySQL在300萬條記錄左右性能開始逐漸降低,雖然官方文檔說500~800w記錄,因此大數據量創建索引是很是有必要的。MySQL提供了Explain,用於顯示SQL執行的詳細信息,能夠進行索引的優化。mysql
1.硬件問題。如網絡速度慢,內存不足,I/O吞吐量小,磁盤空間滿了等。sql
2.沒有索引或者索引失效。(通常在互聯網公司,DBA會在半夜把表鎖了,從新創建一遍索引,由於當你刪除某個數據的時候,索引的樹結構就不完整了。因此互聯網公司的數據作的是假刪除.一是爲了作數據分析,二是爲了避免破壞索引 )數據庫
3.數據過多(分庫分表)服務器
4.服務器調優及各個參數設置(調整my.cnf)網絡
1.先觀察,開啓慢查詢日誌,設置相應的閾值(好比超過3秒就是慢SQL),在生產環境跑上個一天事後,看看哪些SQL比較慢。數據結構
2.Explain和慢SQL分析。好比SQL語句寫的爛,索引沒有或失效,關聯查詢太多(有時候是設計缺陷或者不得以的需求)等等。運維
3.Show Profile是比Explain更近一步的執行細節,能夠查詢到執行每個SQL都幹了什麼事,這些事分別花了多少秒。性能
4.找DBA或者運維對MySQL進行服務器的參數調優。測試
MySQL官方對索引的定義爲:索引(Index)是幫助MySQL高效獲取數據的數據結構。咱們能夠簡單理解爲:快速查找排好序的一種數據結構。Mysql索引主要有兩種結構:B+Tree索引和Hash索引。咱們日常所說的索引,若是沒有特別指明,通常都是指B樹結構組織的索引(B+Tree索引)。索引如圖所示:大數據
最外層淺藍色磁盤塊1裏有數據1七、35(深藍色)和指針P一、P二、P3(黃色)。P1指針表示小於17的磁盤塊,P2是在17-35之間,P3指向大於35的磁盤塊。真實數據存在於子葉節點也就是最底下的一層三、五、九、十、13......非葉子節點不存儲真實的數據,只存儲指引搜索方向的數據項,如1七、35。
查找過程:例如搜索28數據項,首先加載磁盤塊1到內存中,發生一次I/O,用二分查找肯定在P2指針。接着發現28在26和30之間,經過P2指針的地址加載磁盤塊3到內存,發生第二次I/O。用一樣的方式找到磁盤塊8,發生第三次I/O。
真實的狀況是,上面3層的B+Tree能夠表示上百萬的數據,上百萬的數據只發生了三次I/O而不是上百萬次I/O,時間提高是巨大的。
前文鋪墊完成,進入實操部分,先來插入測試須要的數據:
CREATE TABLE `user_info` ( `id` BIGINT(20) NOT NULL AUTO_INCREMENT, `name` VARCHAR(50) NOT NULL DEFAULT '', `age` INT(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name_index` (`name`) )ENGINE = InnoDB DEFAULT CHARSET = utf8; INSERT INTO user_info (name, age) VALUES ('xys', 20); INSERT INTO user_info (name, age) VALUES ('a', 21); INSERT INTO user_info (name, age) VALUES ('b', 23); INSERT INTO user_info (name, age) VALUES ('c', 50); INSERT INTO user_info (name, age) VALUES ('d', 15); INSERT INTO user_info (name, age) VALUES ('e', 20); INSERT INTO user_info (name, age) VALUES ('f', 21); INSERT INTO user_info (name, age) VALUES ('g', 23); INSERT INTO user_info (name, age) VALUES ('h', 50); INSERT INTO user_info (name, age) VALUES ('i', 15); CREATE TABLE `order_info` ( `id` BIGINT(20) NOT NULL AUTO_INCREMENT, `user_id` BIGINT(20) DEFAULT NULL, `product_name` VARCHAR(50) NOT NULL DEFAULT '', `productor` VARCHAR(30) DEFAULT NULL, PRIMARY KEY (`id`), KEY `user_product_detail_index` (`user_id`, `product_name`, `productor`) )ENGINE = InnoDB DEFAULT CHARSET = utf8; INSERT INTO order_info (user_id, product_name, productor) VALUES (1, 'p1', 'WHH'); INSERT INTO order_info (user_id, product_name, productor) VALUES (1, 'p2', 'WL'); INSERT INTO order_info (user_id, product_name, productor) VALUES (1, 'p1', 'DX'); INSERT INTO order_info (user_id, product_name, productor) VALUES (2, 'p1', 'WHH'); INSERT INTO order_info (user_id, product_name, productor) VALUES (2, 'p5', 'WL'); INSERT INTO order_info (user_id, product_name, productor) VALUES (3, 'p3', 'MA'); INSERT INTO order_info (user_id, product_name, productor) VALUES (4, 'p1', 'WHH'); INSERT INTO order_info (user_id, product_name, productor) VALUES (6, 'p1', 'WHH'); INSERT INTO order_info (user_id, product_name, productor) VALUES (9, 'p8', 'TE');
初體驗,執行Explain的效果:
索引使用狀況在possible_keys、key和key_len三列,接下來咱們先從左到右依次講解。
--id相同,執行順序由上而下 explain select u.*,o.* from user_info u,order_info o where u.id=o.user_id;
--id不一樣,值越大越先被執行 explain select * from user_info where id=(select user_id from order_info where product_name ='p8');
能夠看id的執行實例,總共有如下幾種類型:
table表示查詢涉及的表或衍生的表:
explain select tt.* from (select u.* from user_info u,order_info o where u.id=o.user_id and u.id=1) tt
id爲1的<derived2>的表示id爲2的u和o表衍生出來的。
type 字段比較重要,它提供了判斷查詢是否高效的重要依據依據。 經過 type 字段,咱們判斷這次查詢是 全表掃描 仍是 索引掃描等。
type 經常使用的取值有:
一般來講, 不一樣的 type 類型的性能關係以下:
ALL < index < range ~ index_merge < ref < eq_ref < const < system
ALL 類型由於是全表掃描, 所以在相同的查詢條件下,它是速度最慢的。而 index 類型的查詢雖然不是全表掃描,可是它掃描了全部的索引,所以比 ALL 類型的稍快.後面的幾種類型都是利用了索引來查詢數據,所以能夠過濾部分或大部分數據,所以查詢效率就比較高了。
它表示 mysql 在查詢時,可能使用到的索引。 注意,即便有些索引在 possible_keys 中出現,可是並不表示此索引會真正地被 mysql 使用到。 mysql 在查詢時具體使用了哪些索引,由 key 字段決定。
此字段是 mysql 在當前查詢時所真正使用到的索引。好比請客吃飯,possible_keys是應到多少人,key是實到多少人。當咱們沒有創建索引時:
explain select o.* from order_info o where o.product_name= 'p1' and o.productor='whh'; create index idx_name_productor on order_info(productor); drop index idx_name_productor on order_info;
創建複合索引後再查詢:
表示查詢優化器使用了索引的字節數,這個字段能夠評估組合索引是否徹底被使用。
這個表示顯示索引的哪一列被使用了,若是可能的話,是一個常量。前文的type屬性裏也有ref,注意區別。
rows 也是一個重要的字段,mysql 查詢優化器根據統計信息,估算 sql 要查找到結果集須要掃描讀取的數據行數,這個值很是直觀的顯示 sql 效率好壞, 原則上 rows 越少越好。能夠對比key中的例子,一個沒創建索引錢,rows是9,創建索引後,rows是4。
explain 中的不少額外的信息會在 extra 字段顯示, 常見的有如下幾種內容:
explain select u.*,o.* from user_info u LEFT JOIN order_info o on u.id=o.user_id;
執行結果,type有ALL,而且沒有索引:
開始優化,在關聯列上建立索引,明顯看到type列的ALL變成ref,而且用到了索引,rows也從掃描9行變成了1行:
這裏面通常有個規律是:左連接索引加在右表上面,右連接索引加在左表上面。
索引雖然能很是高效的提升查詢速度,同時卻會下降更新表的速度。實際上索引也是一張表,該表保存了主鍵與索引字段,並指向實體表的記錄,因此索引列也是要佔用空間的。
我是個普通的程序猿,水平有限,文章不免有錯誤,歡迎犧牲本身寶貴時間的讀者,就本文內容直抒己見,個人目的僅僅是但願對讀者有所幫助。