重新學習MySQL數據庫12:從實踐sql語句優化開始

本文轉自互聯網

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫,更多精彩內容請到我的倉庫裏查看

https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人博客:

www.how2playlife.com

本文是微信公衆號【Java技術江湖】的《重新學習MySQL數據庫》其中一篇,本文部分內容來源於網絡,爲了把本文主題講得清晰透徹,也整合了很多我認爲不錯的技術博客內容,引用其中了一些比較好的博客文章,如有侵權,請聯繫作者。

該系列博文會告訴你如何從入門到進階,從sql基本的使用方法,從MySQL執行引擎再到索引、事務等知識,一步步地學習MySQL相關技術的實現原理,更好地瞭解如何基於這些知識來優化sql,減少SQL執行時間,通過執行計劃對SQL性能進行分析,再到MySQL的主從複製、主備部署等內容,以便讓你更完整地瞭解整個MySQL方面的技術體系,形成自己的知識框架。

如果對本系列文章有什麼建議,或者是有什麼疑問的話,也可以關注公衆號【Java技術江湖】聯繫作者,歡迎你參與本系列博文的創作和修訂。

<!-- more -->

除非單表數據未來會一直不斷上漲,否則不要一開始就考慮拆分,拆分會帶來邏輯、部署、運維的各種複雜度,一般以整型值爲主的表在千萬級以下,字符串爲主的表在五百萬以下是沒有太大問題的。而事實上很多時候MySQL單表的性能依然有不少優化空間,甚至能正常支撐千萬級以上的數據量:

字段

  • 儘量使用TINYINTSMALLINTMEDIUM_INT作爲整數類型而非INT,如果非負則加上UNSIGNED

  • VARCHAR的長度只分配真正需要的空間

  • 使用枚舉或整數代替字符串類型

  • 儘量使用TIMESTAMP而非DATETIME

  • 單表不要有太多字段,建議在20以內

  • 避免使用NULL字段,很難查詢優化且佔用額外索引空間

  • 用整型來存IP

索引

  • 索引並不是越多越好,要根據查詢有針對性的創建,考慮在WHEREORDER BY命令上涉及的列建立索引,可根據EXPLAIN來查看是否用了索引還是全表掃描

  • 應儘量避免在WHERE子句中對字段進行NULL值判斷,否則將導致引擎放棄使用索引而進行全表掃描

  • 值分佈很稀少的字段不適合建索引,例如"性別"這種只有兩三個值的字段

  • 字符字段只建前綴索引

  • 字符字段最好不要做主鍵

  • 不用外鍵,由程序保證約束

  • 儘量不用UNIQUE,由程序保證約束

  • 使用多列索引時主意順序和查詢條件保持一致,同時刪除不必要的單列索引

查詢SQL

  • 可通過開啓慢查詢日誌來找出較慢的SQL

  • 不做列運算:SELECT id WHERE age + 1 = 10,任何對列的操作都將導致表掃描,它包括數據庫教程函數、計算表達式等等,查詢時要儘可能將操作移至等號右邊

  • sql語句儘可能簡單:一條sql只能在一個cpu運算;大語句拆小語句,減少鎖時間;一條大sql可以堵死整個庫

  • 不用SELECT *

  • OR改寫成INOR的效率是n級別,IN的效率是log(n)級別,in的個數建議控制在200以內

  • 不用函數和觸發器,在應用程序實現

  • 避免%xxx式查詢

  • 少用JOIN

  • 使用同類型進行比較,比如用'123''123'比,123123

  • 儘量避免在WHERE子句中使用!=或<>操作符,否則將引擎放棄使用索引而進行全表掃描

  • 對於連續數值,使用BETWEEN不用INSELECT id FROM t WHERE num BETWEEN 1 AND 5

  • 列表數據不要拿全表,要使用LIMIT來分頁,每頁數量也不要太大

引擎

目前廣泛使用的是MyISAM和InnoDB兩種引擎:

MyISAM

MyISAM引擎是MySQL 5.1及之前版本的默認引擎,它的特點是:

  • 不支持行鎖,讀取時對需要讀到的所有表加鎖,寫入時則對錶加排它鎖

  • 不支持事務

  • 不支持外鍵

  • 不支持崩潰後的安全恢復

  • 在表有讀取查詢的同時,支持往表中插入新紀錄

  • 支持BLOBTEXT的前500個字符索引,支持全文索引

  • 支持延遲更新索引,極大提升寫入性能

  • 對於不會進行修改的表,支持壓縮表,極大減少磁盤空間佔用

InnoDB

InnoDB在MySQL 5.5後成爲默認索引,它的特點是:

  • 支持行鎖,採用MVCC來支持高併發

  • 支持事務

  • 支持外鍵

  • 支持崩潰後的安全恢復

  • 不支持全文索引

總體來講,MyISAM適合SELECT密集型的表,而InnoDB適合INSERTUPDATE密集型的表

0、自己寫的海量數據sql優化實踐

首先是建表和導數據的過程。

參考https://nsimple.top/archives/mysql-create-million-data.html

有時候我們需要對大數據進行測試,本地一般沒有那麼多數據,就需要我們自己生成一些。下面會藉助內存表的特點進行生成百萬條測試數據。

  1. 創建一個臨時內存表, 做數據插入的時候會比較快些

SQL

-- 創建一個臨時內存表DROP TABLE IF EXISTS `vote_record_memory`;CREATE TABLE `vote_record_memory` (    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,    `user_id` varchar(20) NOT NULL DEFAULT '',    `vote_num` int(10) unsigned NOT NULL DEFAULT '0',    `group_id` int(10) unsigned NOT NULL DEFAULT '0',    `status` tinyint(2) unsigned NOT NULL DEFAULT '1',    `create_time` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',    PRIMARY KEY (`id`),    KEY `index_user_id` (`user_id`) USING HASH) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; 
  1. -- 創建一個普通表,用作模擬大數據的測試用例

SQL

DROP TABLE IF EXISTS `vote_record`;CREATE TABLE `vote_record` (    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,    `user_id` varchar(20) NOT NULL DEFAULT '' COMMENT '用戶Id',    `vote_num` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '投票數',    `group_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '用戶組id 0-未激活用戶 1-普通用戶 2-vip用戶 3-管理員用戶',    `status` tinyint(2) unsigned NOT NULL DEFAULT '1' COMMENT '狀態 1-正常 2-已刪除',    `create_time` int(10) unsigned NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '創建時間',    PRIMARY KEY (`id`),    KEY `index_user_id` (`user_id`) USING HASH COMMENT '用戶ID哈希索引') ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='投票記錄表'; 
  1. 爲了數據的隨機性和真實性,我們需要創建一個可生成長度爲n的隨機字符串的函數。

SQL

-- 創建生成長度爲n的隨機字符串的函數DELIMITER // -- 修改MySQL delimiter:'//'DROP FUNCTION IF EXISTS `rand_string` //SET NAMES utf8 //CREATE FUNCTION `rand_string` (n INT) RETURNS VARCHAR(255) CHARSET 'utf8'BEGIN     DECLARE char_str varchar(100) DEFAULT 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';    DECLARE return_str varchar(255) DEFAULT '';    DECLARE i INT DEFAULT 0;    WHILE i < n DO        SET return_str = concat(return_str, substring(char_str, FLOOR(1 + RAND()*62), 1));        SET i = i+1;    END WHILE;    RETURN return_str;END // 
  1. 爲了操作方便,我們再創建一個插入數據的存儲過程

SQL

-- 創建插入數據的存儲過程DROP PROCEDURE IF EXISTS `add_vote_record_memory` //CREATE PROCEDURE `add_vote_record_memory`(IN n INT)BEGIN    DECLARE i INT DEFAULT 1;    DECLARE vote_num INT DEFAULT 0;    DECLARE group_id INT DEFAULT 0;    DECLARE status TINYINT DEFAULT 1;    WHILE i < n DO        SET vote_num = FLOOR(1 + RAND() * 10000);        SET group_id = FLOOR(0 + RAND()*3);        SET status = FLOOR(1 + RAND()*2);        INSERT INTO `vote_record_memory` VALUES (NULL, rand_string(20), vote_num, group_id, status, NOW());        SET i = i + 1;    END WHILE;END //DELIMITER ;  -- 改回默認的 MySQL delimiter:';' 
  1. 開始執行存儲過程,等待生成數據(10W條生成大約需要40分鐘)

SQL

-- 調用存儲過程 生成100W條數據CALL add_vote_record_memory(1000000); 
  1. 查詢內存表已生成記錄(爲了下步測試,目前僅生成了105645條)

SQL

SELECT count(*) FROM `vote_record_memory`;-- count(*)-- 105646 
  1. 把數據從內存表插入到普通表中(10w條數據13s就插入完了)

SQL

INSERT INTO vote_record SELECT * FROM `vote_record_memory`; 
  1. 查詢普通表已的生成記錄

SQL

SELECT count(*) FROM `vote_record`;-- count(*)-- 105646 
  1. 如果一次性插入普通表太慢,可以分批插入,這就需要寫個存儲過程了:

SQL

-- 參數n是每次要插入的條數-- lastid是已導入的最大idCREATE PROCEDURE `copy_data_from_tmp`(IN n INT)BEGIN    DECLARE lastid INT DEFAULT 0;    SELECT MAX(id) INTO lastid FROM `vote_record`;    INSERT INTO `vote_record` SELECT * FROM `vote_record_memory` where id > lastid LIMIT n;END 
  1. 調用存儲過程:

SQL

-- 調用存儲過程 插入60w條CALL copy_data_from_tmp(600000);

SELECT * FROM vote_record;

全表查詢

建完表以後開啓慢查詢日誌,具體參考下面的例子,然後學會用explain。windows慢日誌的位置在c盤,另外,使用client工具也可以記錄慢日誌,所以不一定要用命令行來執行測試,否則大表數據在命令行中要顯示的非常久。

*1 全表掃描select from vote_record**


慢日誌

SET timestamp=1529034398; select * from vote_record;

Time: 2018-06-15T03:52:58.804850Z

User@Host: root[root] @ localhost [::1]  Id:    74

Query_time: 3.166424  Lock_time: 0.000000 Rows_sent: 900500  Rows_examined: 999999

耗時3秒,我設置的門檻是一秒。所以記錄了下來。

explain執行計劃

id select_type table partitions type possible_keys key key_len ref rows filtered Extra

1 SIMPLE vote_record \N ALL \N \N \N \N 996507 100.00 \N

全表掃描耗時3秒多,用不到索引。

*2 select from vote_record where vote_num > 1000**

沒有索引,所以相當於全表掃描,一樣是3.5秒左右

*3 select from vote_record where vote_num > 1000**

加索引create 

CREATE INDEX vote ON vote_record(vote_num);

explain查看執行計劃

id select_type table partitions type possible_keys key key_len ref rows filtered Extra

1 SIMPLE vote_record \N ALL votenum,vote \N \N \N 996507 50.00 Using where

還是沒用到索引,因爲不符合最左前綴匹配。查詢需要3.5秒左右

最後修改一下sql語句

EXPLAIN SELECT * FROM vote_record WHERE id > 0 AND vote_num > 1000;

id select_type table partitions type possible_keys key key_len ref rows filtered Extra

1 SIMPLE vote_record \N range PRIMARY,votenum,vote PRIMARY 4 \N 498253 50.00 Using where

用到了索引,但是只用到了主鍵索引。再修改一次

EXPLAIN SELECT * FROM vote_record WHERE id > 0 AND vote_num = 1000;

id select_type table partitions type possible_keys key key_len ref rows filtered Extra

1 SIMPLE vote_record \N index_merge PRIMARY,votenum,vote votenum,PRIMARY 8,4 \N 51 100.00 Using intersect(votenum,PRIMARY); Using where

用到了兩個索引,votenum,PRIMARY。

這是爲什麼呢。

再看一個語句

EXPLAIN SELECT * FROM vote_record WHERE id = 1000 AND vote_num > 1000

id select_type table partitions type possible_keys key key_len ref rows filtered Extra

1 SIMPLE vote_record \N const PRIMARY,votenum PRIMARY 4 const 1 100.00 \N

也只有主鍵用到了索引。這是因爲只有最左前綴索引可以用>或<,其他索引用<或者>會導致用不到索引。

下面是幾個網上參考的例子:

一:索引是sql語句優化的關鍵,學會使用慢日誌和執行計劃分析sql

背景:使用A電腦安裝mysql,B電腦通過xshell方式連接,數據內容我都已經創建好,現在我已正常的進入到mysql中

步驟1:設置慢查詢日誌的超時時間,先查看日誌存放路徑查詢慢日誌的地址,因爲有慢查詢的內容,就會到這個日誌中:

<pre>show global variables like "%slow%";</pre>

重新學習MySQL數據庫12:從實踐sql語句優化開始

2.開啓慢查詢日誌

<pre>set global slow_query_log=on;</pre>

3.查看慢查詢日誌的設置時間,是否是自己需要的

<pre>show global variables like "%long%";</pre>

重新學習MySQL數據庫12:從實踐sql語句優化開始

4.如果不是自己想的時間,修改慢查詢時間,只要超過了以下的設置時間,查詢的日誌就會到剛剛的日誌中,我設置查詢時間超過1S就進入到慢查詢日誌中

<pre>set global long_query_time=1;</pre>

5.大數據已準備,進行數據的查詢,xshell最好開兩個窗口,一個查看日誌,一個執行內容

<pre>Sql查詢語句:select sql_no_cache * from employees_tmp where first_name='Duangkaew' and gender='M'</pre>

重新學習MySQL數據庫12:從實踐sql語句優化開始

發現查數據的總時間去掉了17.74S

查看日誌:打開日誌

重新學習MySQL數據庫12:從實踐sql語句優化開始

重新學習MySQL數據庫12:從實踐sql語句優化開始

標記1:執行的sql語句

標記2:執行sql的時間,我的是10點52執行的

標記3:使用那臺機器

標記4:執行時間,query_tims,查詢數據的時間

標記5:不知道是幹嘛的

標記6:執行耗時的sql語句,我在想我1的應該是截取錯了!但是記住最後一定是顯示耗時是因爲執行什麼sql造成的

6.執行打印計劃,主要是查看是否使用了索引等其他內容,主要就是在sql前面加上explain 關鍵字

<pre>explain select sql_no_cache * from employees_tmp where first_name='Duangkaew' and gender='M';</pre>

重新學習MySQL數據庫12:從實踐sql語句優化開始

描述extra中,表示只使用了where條件,沒有其他什麼索引之類的

7.進行sql優化,建一個fist_name的索引,索引就是將你需要的數據先給篩選出來,這樣就可以節省很多掃描時間

<pre>create index firstname on employees_tmp(first_name);</pre>

 重新學習MySQL數據庫12:從實踐sql語句優化開始

注:創建索引時會很慢,是對整個表做了一個複製功能,並進行數據的一些分類(我猜是這樣,所以會很慢)

8.查看建立的索引

<pre>show index from employees_tmp;</pre>

 重新學習MySQL數據庫12:從實踐sql語句優化開始

9.在執行查詢語句,查看語句的執行時間

<pre>select sql_no_cache * from employees_tmp where first_name='Duangkaew' and gender='M'</pre>

重新學習MySQL數據庫12:從實踐sql語句優化開始

   發現時間已經有所提升了,其實選擇索引也不一開始就知道,我們在試試使用性別,gender進行索引

10.刪除已經有的索引,刪除索引:

<pre>drop index first_name on employees_tmp;</pre>

11.創建性別的索引(性別是不怎麼好的索引方式,因爲有很多重複數據)

<pre>create index index_gendar on employees_tmp(gender);</pre>

在執行sql語句查詢數據,查看查詢執行時間,沒有創建比較優秀的索引,導致查詢時間還變長了,

爲嘛還變長了,這個我沒有弄懂

重新學習MySQL數據庫12:從實踐sql語句優化開始

12.我們在試試使用創建組合索引,使用性別和姓名

<pre>alter table employees_tmp add index idx_union (first_name,gender);</pre>

在執行sql查看sql數據的執行時間

<pre>select sql_no_cache * from employees_tmp where first_name='Duangkaew' and gender='M'</pre>

速度提升了N多倍啊

重新學習MySQL數據庫12:從實踐sql語句優化開始

查看創建的索引

<pre>show index from employees_tmp;</pre>

重新學習MySQL數據庫12:從實踐sql語句優化開始

索引建的好真的一個好幫手,建不好就是費時的一個操作

 目前還不知道爲什麼建立性別的索引會這麼慢

二:sql優化注意要點,比如索引是否用到,查詢優化是否改變了執行計劃,以及一些細節

場景

我用的數據庫是mysql5.6,下面簡單的介紹下場景

課程表

create table Course( c_id int PRIMARY KEY, name varchar(10) )

數據100條

學生表:

create table Student( id int PRIMARY KEY, name varchar(10) )

數據70000條

學生成績表SC

CREATE table SC(     sc_id int PRIMARY KEY,     s_id int,     c_id int,     score int )

數據70w條

查詢目的:

查找語文考100分的考生

查詢語句:

select s.* from Student s where s.s_id in (select s_id from SC sc where sc.c_id = 0 and sc.score = 100 )

執行時間:30248.271s

暈,爲什麼這麼慢,先來查看下查詢計劃:

EXPLAIN  select s.* from Student s where s.s_id in (select s_id from SC sc where sc.c_id = 0 and sc.score = 100 )

image

發現沒有用到索引,type全是ALL,那麼首先想到的就是建立一個索引,建立索引的字段當然是在where條件的字段。

先給sc表的c_id和score建個索引

CREATE index sc_c_id_index on SC(c_id);
CREATE index sc_score_index on SC(score);

再次執行上述查詢語句,時間爲: 1.054s

快了3w多倍,大大縮短了查詢時間,看來索引能極大程度的提高查詢效率,看來建索引很有必要,很多時候都忘記建

索引了,數據量小的的時候壓根沒感覺,這優化感覺挺爽。

但是1s的時間還是太長了,還能進行優化嗎,仔細看執行計劃:

image

查看優化後的sql:

SELECT    `YSB`.`s`.`s_id` AS `s_id`,    `YSB`.`s`.`name` AS `name`FROM    `YSB`.`Student` `s`WHERE    < in_optimizer > (        `YSB`.`s`.`s_id` ,< EXISTS > (            SELECT                1            FROM                `YSB`.`SC` `sc`            WHERE                (                    (`YSB`.`sc`.`c_id` = 0)                    AND (`YSB`.`sc`.`score` = 100)                    AND (                        < CACHE > (`YSB`.`s`.`s_id`) = `YSB`.`sc`.`s_id`                    )                )        )    )

補充:這裏有網友問怎麼查看優化後的語句

方法如下:

在命令窗口執行 

image

image

有type=all

按照我之前的想法,該sql的執行的順序應該是先執行子查詢

select s_id from SC sc where sc.c_id = 0 and sc.score = 100

耗時:0.001s

得到如下結果:

image

然後再執行

select s.* from Student s where s.s_id in(7,29,5000)

耗時:0.001s

這樣就是相當快了啊,Mysql竟然不是先執行裏層的查詢,而是將sql優化成了exists子句,並出現了EPENDENT SUBQUERY,

mysql是先執行外層查詢,再執行裏層的查詢,這樣就要循環70007*11=770077次。

那麼改用連接查詢呢?

SELECT s.* from  Student s INNER JOIN SC sc on sc.s_id = s.s_id where sc.c_id=0 and sc.score=100

這裏爲了重新分析連接查詢的情況,先暫時刪除索引sc_c_id_index,sc_score_index

執行時間是:0.057s

效率有所提高,看看執行計劃:

image

這裏有連表的情況出現,我猜想是不是要給sc表的s_id建立個索引

CREATE index sc_s_id_index on SC(s_id);

show index from SC

image

在執行連接查詢

時間: 1.076s,竟然時間還變長了,什麼原因?查看執行計劃:

image

優化後的查詢語句爲:

SELECT    `YSB`.`s`.`s_id` AS `s_id`,    `YSB`.`s`.`name` AS `name`FROM    `YSB`.`Student` `s`JOIN `YSB`.`SC` `sc`WHERE    (        (            `YSB`.`sc`.`s_id` = `YSB`.`s`.`s_id`        )        AND (`YSB`.`sc`.`score` = 100)        AND (`YSB`.`sc`.`c_id` = 0)    )

貌似是先做的連接查詢,再執行的where過濾

回到前面的執行計劃:

image

這裏是先做的where過濾,再做連表,執行計劃還不是固定的,那麼我們先看下標準的sql執行順序:

image

正常情況下是先join再where過濾,但是我們這裏的情況,如果先join,將會有70w條數據發送join做操,因此先執行where

過濾是明智方案,現在爲了排除mysql的查詢優化,我自己寫一條優化後的sql

SELECT    s.*FROM    (        SELECT            *        FROM            SC sc        WHERE            sc.c_id = 0        AND sc.score = 100    ) tINNER JOIN Student s ON t.s_id = s.s_id

即先執行sc表的過濾,再進行表連接,執行時間爲:0.054s

和之前沒有建s_id索引的時間差不多

查看執行計劃:

image

先提取sc再連表,這樣效率就高多了,現在的問題是提取sc的時候出現了掃描表,那麼現在可以明確需要建立相關索引

CREATE index sc_c_id_index on SC(c_id);
CREATE index sc_score_index on SC(score);

再執行查詢:

SELECT    s.*FROM    (        SELECT            *        FROM            SC sc        WHERE            sc.c_id = 0        AND sc.score = 100    ) tINNER JOIN Student s ON t.s_id = s.s_id

執行時間爲:0.001s,這個時間相當靠譜,快了50倍

執行計劃:

image

我們會看到,先提取sc,再連表,都用到了索引。

那麼再來執行下sql

SELECT s.* from  Student s INNER JOIN SC sc on sc.s_id = s.s_id where sc.c_id=0 and sc.score=100

執行時間0.001s

執行計劃:

image

這裏是mysql進行了查詢語句優化,先執行了where過濾,再執行連接操作,且都用到了索引。

總結:

1.mysql嵌套子查詢效率確實比較低

2.可以將其優化成連接查詢

3.建立合適的索引

4.學會分析sql執行計劃,mysql會對sql進行優化,所以分析執行計劃很重要

由於時間問題,這篇文章先寫到這裏,後續再分享其他的sql優化經歷。

三、海量數據分頁查找時如何使用主鍵索引進行優化

mysql百萬級分頁優化

  普通分頁

   數據分頁在網頁中十分多見,分頁一般都是limit start,offset,然後根據頁碼page計算start

<pre> select * from user limit 1,20</pre>

   這種分頁在幾十萬的時候分頁效率就會比較低了,MySQL需要從頭開始一直往後計算,這樣大大影響效率

<pre>SELECT from user limit 100001,20; //time 0.151s explain SELECT from user limit 100001,20;</pre>

  我們可以用explain分析下語句,沒有用到任何索引,MySQL執行的行數是16W+,於是我們可以想用到索引去實現分頁

  重新學習MySQL數據庫12:從實踐sql語句優化開始

   優化分頁

   使用主鍵索引來優化數據分頁

<pre> select * from user where id>(select id from user where id>=100000 limit 1) limit 20; //time 0.003s</pre>

  使用explain分析語句,MySQL這次掃描的行數是8W+,時間也大大縮短。

<pre> explain select * from user where id>(select id from user where id>=100000 limit 1) limit 20;</pre>

     重新學習MySQL數據庫12:從實踐sql語句優化開始

  總結

  在數據量比較大的時候,我們儘量去利用索引來優化語句。上面的優化方法如果id不是主鍵索引,查詢效率比第一種還要低點。我們可以先使用explain來分析語句,查看語句的執行順序和執行性能。

轉載於:https://my.oschina.net/alicoder/blog/3097141

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章