MySQL優化(2)--------經常使用優化

前言

　　以前已經簡單介紹了MySQL的優化步驟，那麼接下來天然而是就是經常使用的SQL優化，好比inseer、group by等經常使用SQL的優化，會涉及SQL語句內部細節（這正是我缺少的）。最後但願本身能記錄完成的一套MySQL優化博文！

　　注：其中部分我並無所有實驗（並不表明是錯的），這裏只至關於記錄下，接下來會慢慢補充！

　　參考資料：《深刻淺出MySQL》（有須要PDF電子書的夥伴能夠評論或者私信我）

 

---

 

一、大批量插入數據優化

（1）對於MyISAM存儲引擎的表，可使用：DISABLE KEYS 和 ENABLE KEYS 用來打開或者關閉 MyISAM 表非惟一索引的更新。

ALTER TABLE tbl_name DISABLE KEYS;
loading the data
ALTER TABLE tbl_name ENABLE KEYS;

（2）對於InnoDB引擎，有如下幾種優化措施：

　　① 導入的數據按照主鍵的順序保存：這是由於InnoDB引擎表示按照主鍵順序保存的，若是能將插入的數據提早按照排序好天然能省去不少時間。

　　好比bulk_insert.txt文件是以表user主鍵的順序存儲的，導入的時間爲15.23秒

mysql> load data infile 'mysql/bulk_insert.txt' into table user;
Query OK, 126732 rows affected (15.23 sec)
Records: 126732 Deleted: 0 Skipped: 0 Warnings: 0

　　沒有按照主鍵排序的話，時間爲：26.54秒

mysql> load data infile 'mysql/bulk_insert.txt' into table user;
Query OK, 126732 rows affected (26.54 sec)
Records: 126732 Deleted: 0 Skipped: 0 Warnings: 0

　　② 導入數據前執行SET UNIQUE_CHECKS=0，關閉惟一性校驗，帶導入以後再打開設置爲1：校驗會消耗時間，在數據量大的狀況下須要考慮。

　　③ 導入前設置SET AUTOCOMMIT=0，關閉自動提交，導入後結束再設置爲1：這是由於自動提交會消耗部分時間與資源，雖然消耗不是很大，可是在數據量大的狀況下仍是得考慮。

二、INSERT的優化

（1）儘可能使用多個值表的 INSERT 語句，這種方式將大大縮減客戶端與數據庫之間的鏈接、關閉等消耗。（同一客戶的狀況下），即：

　INSERT INTO tablename values(1,2),(1,3),(1,4)

實驗：插入8條數據到user表中（使用navicat客戶端工具）

insert into user values(1,'test',replace(uuid(),'-',''));
insert into user values(2,'test',replace(uuid(),'-',''));
insert into user values(3,'test',replace(uuid(),'-',''));
insert into user values(4,'test',replace(uuid(),'-',''));
insert into user values(5,'test',replace(uuid(),'-',''));
insert into user values(6,'test',replace(uuid(),'-',''));
insert into user values(7,'test',replace(uuid(),'-',''));
insert into user values(8,'test',replace(uuid(),'-',''));

獲得反饋：

[SQL] insert into user values(1,'test',replace(uuid(),'-',''));
受影響的行: 1
時間: 0.033s
[SQL] 
insert into user values(2,'test',replace(uuid(),'-',''));
受影響的行: 1
時間: 0.034s
[SQL] 
insert into user values(3,'test',replace(uuid(),'-',''));
受影響的行: 1
時間: 0.056s
[SQL] 
insert into user values(4,'test',replace(uuid(),'-',''));
受影響的行: 1
時間: 0.008s
[SQL] 
insert into user values(5,'test',replace(uuid(),'-',''));
受影響的行: 1
時間: 0.008s
[SQL] 
insert into user values(6,'test',replace(uuid(),'-',''));
受影響的行: 1
時間: 0.024s
[SQL] 
insert into user values(7,'test',replace(uuid(),'-',''));
受影響的行: 1
時間: 0.004s
[SQL] 
insert into user values(8,'test',replace(uuid(),'-',''));
受影響的行: 1
時間: 0.004s

總共的時間爲0.171秒，接下來使用多值表形式：

insert into user values
(9,'test',replace(uuid(),'-','')),
(10,'test',replace(uuid(),'-','')),
(11,'test',replace(uuid(),'-','')),
(12,'test',replace(uuid(),'-','')),
(13,'test',replace(uuid(),'-','')),
(14,'test',replace(uuid(),'-','')),
(15,'test',replace(uuid(),'-','')),
(16,'test',replace(uuid(),'-',''));

獲得反饋：

[SQL] insert into user values
(9,'test',replace(uuid(),'-','')),
(10,'test',replace(uuid(),'-','')),
(11,'test',replace(uuid(),'-','')),
(12,'test',replace(uuid(),'-','')),
(13,'test',replace(uuid(),'-','')),
(14,'test',replace(uuid(),'-','')),
(15,'test',replace(uuid(),'-','')),
(16,'test',replace(uuid(),'-',''));
受影響的行: 8
時間: 0.038s

獲得時間爲0.038，這樣一來能夠很明顯節約時間優化SQL

（2）若是在不一樣客戶端插入不少行，可以使用INSERT DELAYED語句獲得更高的速度，DELLAYED含義是讓INSERT語句立刻執行，其實數據都被放在內存的隊列中。並無真正寫入磁盤。LOW_PRIORITY恰好相反。

（3）將索引文件和數據文件分在不一樣的磁盤上存放（InnoDB引擎是在同一個表空間的）。

（4）若是批量插入，則能夠增長bluk_insert_buffer_size變量值提供速度（只對MyISAM有用）

（5）當從一個文本文件裝載一個表時，使用LOAD DATA INFILE，一般比INSERT語句快20倍。

三、GROUP BY的優化

　　在默認狀況下，MySQL中的GROUP BY語句會對其後出現的字段進行默認排序（非主鍵狀況），就比如咱們使用ORDER BY col1,col2,col3...因此咱們在後面跟上具備相同列（與GROUP BY後出現的col1,col2,col3...相同）ORDER BY子句並無影響該SQL的實際執行性能。

　　那麼就會有這樣的狀況出現，咱們對查詢到的結果是否已經排序不在意時，可使用ORDER BY NULL禁止排序達到優化目的。下面使用EXPLAIN命令分析SQL。

　　在user_1中執行select id, sum(money) form user_1 group by name時，會默認排序（注意group by後的column是非index纔會體現group by的排序，若是是primary key，那以前說過了InnoDB默認是按照主鍵index排好序的）

mysql> select*from user_1;
+----+----------+-------+
| id | name     | money |
+----+----------+-------+
|  1 | Zhangsan |    32 |
|  2 | Lisi     |    65 |
|  3 | Wangwu   |    44 |
|  4 | Lijian   |   100 |
+----+----------+-------+
4 rows in set

不由止排序，即不使用ORDER BY NULL時：有明顯的Using filesort。

　　

當使用ORDER BY NULL禁止排序後，Using filesort不存在

四、ORDER BY 的優化　　

MySQL可使用一個索引來知足ORDER BY 子句的排序，而不須要額外的排序，可是須要知足如下幾個條件：

（1）WHERE 條件和OREDR BY 使用相同的索引：即key_part1與key_part2是複合索引，where中使用複合索引中的key_part1

SELECT*FROM user WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC;

（2）並且ORDER BY順序和索引順序相同：

SELECT*FROM user ORDER BY key_part1, key_part2;

（3）而且要麼都是升序要麼都是降序：

SELECT*FROM user ORDER BY key_part1 DESC, key_part2 DESC;

但如下幾種狀況則不使用索引：

（1）ORDER BY中混合ASC和DESC：

SELECT*FROM user ORDER BY key_part1 DESC, key_part2 ASC;

（2）查詢行的關鍵字與ORDER BY所使用的不相同，即WHERE 後的字段與ORDER BY 後的字段是不同的

SELECT*FROM user WHERE key2 = ‘xxx’ ORDER BY key1;

（3）ORDER BY對不一樣的關鍵字使用，即ORDER BY後的關鍵字不相同

SELECT*FROM user ORDER BY key1, key2;

五、OR的優化

當MySQL使用OR查詢時，若是要利用索引的話，必須每一個條件列都使獨立索引，而不是複合索引（多列索引），才能保證使用到查詢的時候使用到索引。

好比咱們新建一張用戶信息表user_info

mysql> select*from user_info;
+---------+--------+----------+-----------+
| user_id | idcard | name     | address    |
+---------+--------+----------+-----------+
|       1 | 111111 | Zhangsan | Kunming   |
|       2 | 222222 | Lisi     | Beijing   |
|       3 | 333333 | Wangwu   | Shanghai  |
|       4 | 444444 | Lijian   | Guangzhou |
+---------+--------+----------+-----------+
4 rows in set

以後建立ind_name_id(user_id, name)複合索引、id_index(id_index)獨立索引，idcard主鍵索引三個索引。

mysql> show index from user_info;
+-----------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table     | Non_unique | Key_name    | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-----------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| user_info |          0 | PRIMARY     |            1 | idcard      | A         |           4 | NULL     | NULL   |      | BTREE      |         |               |
| user_info |          1 | ind_name_id |            1 | user_id     | A         |           4 | NULL     | NULL   |      | BTREE      |         |               |
| user_info |          1 | ind_name_id |            2 | name        | A         |           4 | NULL     | NULL   | YES  | BTREE      |         |               |
| user_info |          1 | id_index    |            1 | user_id     | A         |           4 | NULL     | NULL   |      | BTREE      |         |               |
+-----------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
4 rows in set

測試一：OR鏈接兩個有單獨索引的字段，整個SQL查詢纔會用到索引(index_merge)，而且咱們知道OR其實是把每一個結果最後UNION一塊兒的。

mysql> explain select*from user_info where user_id=1 or idcard='222222';
+----+-------------+-----------+------------+-------------+------------------------------+---------------------+---------+------+------+----------+----------------------------------------------------+
| id | select_type | table     | partitions | type        | possible_keys                | key                 | key_len | ref  | rows | filtered | Extra                                              |
+----+-------------+-----------+------------+-------------+------------------------------+---------------------+---------+------+------+----------+----------------------------------------------------+
|  1 | SIMPLE      | user_info | NULL       | index_merge | PRIMARY,ind_name_id,id_index | ind_name_id,PRIMARY | 4,62    | NULL |    2 |      100 | Using sort_union(ind_name_id,PRIMARY); Using where |
+----+-------------+-----------+------------+-------------+------------------------------+---------------------+---------+------+------+----------+----------------------------------------------------+
1 row in set

測試二：OR使用複合索引的字段name，與沒有索引的address，整個SQL都是ALL全表掃描的

mysql> explain select*from user_info where name='Zhangsan' or address='Beijing';
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    43.75 | Using where |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set

交換OR位置而且使用另外的複合索引的列，也是ALL全表掃描：

mysql> explain select*from user_info where address='Beijing' or user_id=1;
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys        | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | ind_name_id,id_index | NULL | NULL    | NULL |    4 |    43.75 | Using where |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
1 row in set

六、優化嵌套查詢

使用嵌套查詢有時候可使用更有效的JOIN鏈接代替，這是由於MySQL中不須要在內存中建立臨時表完成SELECT子查詢與主查詢兩部分查詢工做。可是並非全部的時候都成立，最好是在on關鍵字後面的列有索引的話，效果會更好！

好比在表major中major_id是有索引的：

select * from student u left join major m on u.major_id=m.major_id where m.major_id is null;

而經過嵌套查詢時，在內存中建立臨時表完成SELECT子查詢與主查詢兩部分查詢工做，會有必定的消耗

select * from student u where major_id not in (select major_id from major);

七、使用SQL提示

SQL提示（SQL HINT）是優化數據庫的一個重要手段，就是往SQL語句中加入一些人爲的提示來達到優化目的。下面是一些經常使用的SQL提示：

（1）USE INDEX：使用USE INDEX是但願MySQL去參考索引列表，就可讓MySQL不須要考慮其餘可用索引，其實也就是possible_keys屬性下參考的索引值

mysql> explain select* from user_info use index(id_index,ind_name_id) where user_id>0;
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys        | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | ind_name_id,id_index | NULL | NULL    | NULL |    4 |      100 | Using where |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
1 row in set

mysql> explain select* from user_info use index(id_index) where user_id>0;
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | id_index      | NULL | NULL    | NULL |    4 |      100 | Using where |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set

（2）IGNORE INDEX忽略索引

咱們使用user_id判斷，用不到其餘索引時，能夠忽略索引。即與USE INDEX相反，從possible_keys中減去不須要的索引，可是實際環境中不多使用。

mysql> explain select* from user_info ignore index(primary,ind_name_id,id_index) where user_id>0;
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    33.33 | Using where |
+----+-------------+-----------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set

（3）FORCE INDEX強制索引

好比where user_id > 0，可是user_id在表中都是大於0的，天然就會進行ALL全表搜索，可是使用FORCE INDEX雖然執行效率不是最高（where user_id > 0條件決定的）但MySQL仍是使用索引。

mysql> explain select* from user_info where user_id>0;
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type | possible_keys        | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_info | NULL       | ALL  | ind_name_id,id_index | NULL | NULL    | NULL |    4 |      100 | Using where |
+----+-------------+-----------+------------+------+----------------------+------+---------+------+------+----------+-------------+
1 row in set

以後強制使用獨立索引id_index(user_id)：

mysql> explain select* from user_info force index(id_index) where user_id>0;
+----+-------------+-----------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
| id | select_type | table     | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-----------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | user_info | NULL       | range | id_index      | id_index | 4       | NULL |    4 |      100 | Using index condition |
+----+-------------+-----------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
1 row in set

 

---

 

總結

　　（1）不少時候數據庫的性能是因爲不合適（是指效率不高，可能會致使鎖表等）的SQL語句形成，本篇博文只是介紹簡單的SQL優化

　　（2）其中有些優化在真正開發中是用不到的，可是一旦出問題性能降低的時候須要去一一分析。