3萬字總結,Mysql優化之精髓
本文知識點較多,篇幅較長,請耐心學習
MySQL已經成為時下關係型資料庫產品的中堅力量,備受網際網路大廠的青睞,出門面試想進BAT,想拿高工資,不會點MySQL優化知識,拿offer的成功率會大大下降。
為什麼要優化
- 系統的吞吐量瓶頸往往出現在資料庫的訪問速度上
- 隨著應用程式的執行,資料庫的中的資料會越來越多,處理時間會相應變慢
- 資料是存放在磁碟上的,讀寫速度無法和記憶體相比
如何優化
- 設計資料庫時:資料庫表、欄位的設計,儲存引擎
- 利用好MySQL自身提供的功能,如索引等
- 橫向擴充套件:MySQL叢集、負載均衡、讀寫分離
- SQL語句的優化(收效甚微)
欄位設計
欄位型別的選擇,設計規範,正規化,常見設計案例
原則:儘量使用整型表示字串
儲存IP
INET_ATON(str)
,address to number
INET_NTOA(number)
,number to address
MySQL內部的列舉型別(單選)和集合(多選)型別
但是因為維護成本較高因此不常使用,使用關聯表的方式來替代enum
原則:定長和非定長資料型別的選擇
decimal不會損失精度,儲存空間會隨資料的增大而增大。double佔用固定空間,較大數的儲存會損失精度。非定長的還有varchar、text
金額
對資料的精度要求較高,小數的運算和儲存存在精度問題(不能將所有小數轉換成二進位制)
定點數decimal
price decimal(8,2)
int,bigint
儲存範圍的數)
小單位大數額避免出現小數
元->分
字串儲存
定長char
,非定長varchar、text
(上限65535,其中varchar
還會消耗1-3位元組記錄長度,而text
使用額外空間記錄長度)
原則:儘可能選擇小的資料型別和指定短的長度
原則:儘可能使用 not null
非null
欄位的處理要比null
欄位的處理高效些!且不需要判斷是否為null
。
null
在MySQL中,不好處理,儲存需要額外空間,運算也需要特殊的運算子。如select null = null
和select null <> null
<>
為不等號)有著同樣的結果,只能通過is null
和is not null
來判斷欄位是否為null
。
如何儲存?MySQL中每條記錄都需要額外的儲存空間,表示每個欄位是否為null
。因此通常使用特殊的資料進行佔位,比如int not null default 0
、string not null default ‘’
原則:欄位註釋要完整,見名知意
原則:單表字段不宜過多
二三十個就極限了
原則:可以預留欄位
在使用以上原則之前首先要滿足業務需求
關聯表的設計
外來鍵
foreign key
只能實現一對一或一對多的對映
一對多
使用外來鍵
多對多
單獨新建一張表將多對多拆分成兩個一對多
一對一
如商品的基本資訊(item
)和商品的詳細資訊(item_intro
),通常使用相同的主鍵或者增加一個外來鍵欄位(item_id
)
正規化 Normal Format
資料表的設計規範,一套越來越嚴格的規範體系(如果需要滿足N正規化,首先要滿足N-1正規化)。N
第一正規化1NF:欄位原子性
欄位原子性,欄位不可再分割。
關係型資料庫,預設滿足第一正規化
注意比較容易出錯的一點,在一對多的設計中使用逗號分隔多個外來鍵,這種方法雖然儲存方便,但不利於維護和索引(比如查詢帶標籤java
的文章)
第二正規化:消除對主鍵的部分依賴
即在表中加上一個與業務邏輯無關的欄位作為主鍵
主鍵:可以唯一標識記錄的欄位或者欄位集合。
course_name | course_class | weekday(周幾) | course_teacher |
---|---|---|---|
MySQL | 教育大樓1525 | 週一 | 張三 |
Java | 教育大樓1521 | 週三 | 李四 |
MySQL | 教育大樓1521 | 週五 | 張三 |
依賴:A欄位可以確定B欄位,則B欄位依賴A欄位。比如知道了下一節課是數學課,就能確定任課老師是誰。於是周幾和下一節課和就能構成複合主鍵,能夠確定去哪個教室上課,任課老師是誰等。但我們常常增加一個id
作為主鍵,而消除對主鍵的部分依賴。
對主鍵的部分依賴:某個欄位依賴複合主鍵中的一部分。
解決方案:新增一個獨立欄位作為主鍵。
第三正規化:消除對主鍵的傳遞依賴
傳遞依賴:B欄位依賴於A,C欄位又依賴於B。比如上例中,任課老師是誰取決於是什麼課,是什麼課又取決於主鍵id
。因此需要將此表拆分為兩張表日程表和課程表(獨立資料獨立建表):
id | weekday | course_class | course_id |
---|---|---|---|
1001 | 週一 | 教育大樓1521 | 3546 |
course_id | course_name | course_teacher |
---|---|---|
3546 | Java | 張三 |
這樣就減少了資料的冗餘(即使週一至週日每天都有Java課,也只是course_id:3546
出現了7次)
儲存引擎選擇
早期問題:如何選擇MyISAM和Innodb?
現在不存在這個問題了,Innodb不斷完善,從各個方面趕超MyISAM,也是MySQL預設使用的。
儲存引擎Storage engine:MySQL中的資料、索引以及其他物件是如何儲存的,是一套檔案系統的實現。
功能差異
show engines
Engine | Support | Comment |
---|---|---|
InnoDB | DEFAULT | Supports transactions, row-level locking, and foreign keys |
MyISAM | YES | MyISAM storage engine |
儲存差異
MyISAM | Innodb | |
---|---|---|
檔案格式 | 資料和索引是分別儲存的,資料.MYD ,索引.MYI |
資料和索引是集中儲存的,.ibd |
檔案能否移動 | 能,一張表就對應.frm 、MYD 、MYI 3個檔案 |
否,因為關聯的還有data 下的其它檔案 |
記錄儲存順序 | 按記錄插入順序儲存 | 按主鍵大小有序插入 |
空間碎片(刪除記錄並flush table 表名 之後,表文件大小不變) |
產生。定時整理:使用命令optimize table 表名 實現 |
不產生 |
事務 | 不支援 | 支援 |
外來鍵 | 不支援 | 支援 |
鎖支援(鎖是避免資源爭用的一個機制,MySQL鎖對使用者幾乎是透明的) | 表級鎖定 | 行級鎖定、表級鎖定,鎖定力度小併發能力高 |
鎖擴充套件
表級鎖(
table-level lock
):lock tables <table_name1>,<table_name2>... read/write
,unlock tables <table_name1>,<table_name2>...
。其中read
是共享鎖,一旦鎖定任何客戶端都不可讀;write
是獨佔/寫鎖,只有加鎖的客戶端可讀可寫,其他客戶端既不可讀也不可寫。鎖定的是一張表或幾張表。行級鎖(
row-level lock
):鎖定的是一行或幾行記錄。共享鎖:select * from <table_name> where <條件> LOCK IN SHARE MODE;
,對查詢的記錄增加共享鎖;select * from <table_name> where <條件> FOR UPDATE;
,對查詢的記錄增加排他鎖。這裡值得注意的是:innodb
的行鎖,其實是一個子範圍鎖,依據條件鎖定部分範圍,而不是就對映到具體的行上,因此還有一個學名:間隙鎖。比如select * from stu where id < 20 LOCK IN SHARE MODE
會鎖定id
在20
左右以下的範圍,你可能無法插入id
為18
或22
的一條新紀錄。
選擇依據
如果沒有特別的需求,使用預設的Innodb
即可。
MyISAM:以讀寫插入為主的應用程式,比如部落格系統、新聞入口網站。
Innodb:更新(刪除)操作頻率也高,或者要保證資料的完整性;併發量高,支援事務和外來鍵保證資料完整性。比如OA自動化辦公系統。
索引
關鍵字與資料的對映關係稱為索引(==包含關鍵字和對應的記錄在磁碟中的地址==)。關鍵字是從資料當中提取的用於標識、檢索資料的特定內容。
索引檢索為什麼快?
- 關鍵字相對於資料本身,==資料量小==
- 關鍵字是==有序==的,二分查詢可快速確定位置
圖書館為每本書都加了索引號(類別-樓層-書架)、字典為詞語解釋按字母順序編寫目錄等都用到了索引。
MySQL中索引型別
普通索引(
key
),唯一索引(unique key
),主鍵索引(primary key
),全文索引(fulltext key
)
三種索引的索引方式是一樣的,只不過對索引的關鍵字有不同的限制:
- 普通索引:對關鍵字沒有限制
- 唯一索引:要求記錄提供的關鍵字不能重複
- 主鍵索引:要求關鍵字唯一且不為null
索引管理語法
檢視索引
show create table 表名
:
desc 表名
建立索引
建立表之後建立索引
create TABLE user_index(
id int auto_increment primary key,
first_name varchar(16),
last_name VARCHAR(16),
id_card VARCHAR(18),
information text
);
-- 更改表結構
alter table user_index
-- 建立一個first_name和last_name的複合索引,並命名為name
add key name (first_name,last_name),
-- 建立一個id_card的唯一索引,預設以欄位名作為索引名
add UNIQUE KEY (id_card),
-- 雞肋,全文索引不支援中文
add FULLTEXT KEY (information);
show create table user_index
:
建立表時指定索引
CREATE TABLE user_index2 (
id INT auto_increment PRIMARY KEY,
first_name VARCHAR (16),
last_name VARCHAR (16),
id_card VARCHAR (18),
information text,
KEY name (first_name, last_name),
FULLTEXT KEY (information),
UNIQUE KEY (id_card)
);
刪除索引
根據索引名刪除普通索引、唯一索引、全文索引:alter table 表名 drop KEY 索引名
alter table user_index drop KEY name;
alter table user_index drop KEY id_card;
alter table user_index drop KEY information;
刪除主鍵索引:alter table 表名 drop primary key
(因為主鍵只有一個)。這裡值得注意的是,如果主鍵自增長,那麼不能直接執行此操作(自增長依賴於主鍵索引):
需要取消自增長再行刪除:
alter table user_index
-- 重新定義欄位
MODIFY id int,
drop PRIMARY KEY
但通常不會刪除主鍵,因為設計主鍵一定與業務邏輯無關。
執行計劃explain
CREATE TABLE innodb1 (
id INT auto_increment PRIMARY KEY,
first_name VARCHAR (16),
last_name VARCHAR (16),
id_card VARCHAR (18),
information text,
KEY name (first_name, last_name),
FULLTEXT KEY (information),
UNIQUE KEY (id_card)
);
insert into innodb1 (first_name,last_name,id_card,information) values ('張','三','1001','華山派');
我們可以通過explain selelct
來分析SQL語句執行前的執行計劃:
由上圖可看出此SQL語句是按照主鍵索引來檢索的。
執行計劃是:當執行SQL語句時,首先會分析、優化,形成執行計劃,在按照執行計劃執行。
索引使用場景(重點)
where
上圖中,根據id
查詢記錄,因為id
欄位僅建立了主鍵索引,因此此SQL執行可選的索引只有主鍵索引,如果有多個,最終會選一個較優的作為檢索的依據。
-- 增加一個沒有建立索引的欄位
alter table innodb1 add sex char(1);
-- 按sex檢索時可選的索引為null
EXPLAIN SELECT * from innodb1 where sex='男';
可以嘗試在一個欄位未建立索引時,根據該欄位查詢的效率,然後對該欄位建立索引(
alter table 表名 add index(欄位名)
),同樣的SQL執行的效率,你會發現查詢效率會有明顯的提升(資料量越大越明顯)。
order by
當我們使用order by
將查詢結果按照某個欄位排序時,如果該欄位沒有建立索引,那麼執行計劃會將查詢出的所有資料使用外部排序(將資料從硬碟分批讀取到記憶體使用內部排序,最後合併排序結果),這個操作是很影響效能的,因為需要將查詢涉及到的所有資料從磁碟中讀到記憶體(如果單條資料過大或者資料量過多都會降低效率),更無論讀到記憶體之後的排序了。
但是如果我們對該欄位建立索引alter table 表名 add index(欄位名)
,那麼由於索引本身是有序的,因此直接按照索引的順序和對映關係逐條取出資料即可。而且如果分頁的,那麼只用取出索引表某個範圍內的索引對應的資料,而不用像上述那取出所有資料進行排序再返回某個範圍內的資料。(從磁碟取資料是最影響效能的)
join
對
join
語句匹配關係(on
)涉及的欄位建立索引能夠提高效率
索引覆蓋
如果要查詢的欄位都建立過索引,那麼引擎會直接在索引表中查詢而不會訪問原始資料(否則只要有一個欄位沒有建立索引就會做全表掃描),這叫索引覆蓋。因此我們需要儘可能的在select
後==只寫必要的查詢欄位==,以增加索引覆蓋的機率。
這裡值得注意的是不要想著為每個欄位建立索引,因為優先使用索引的優勢就在於其體積小。
語法細節(要點)
在滿足索引使用的場景下(
where/order by/join on
或索引覆蓋),索引也不一定被使用
欄位要獨立出現
比如下面兩條SQL語句在語義上相同,但是第一條會使用主鍵索引而第二條不會。
select * from user where id = 20-1;
select * from user where id+1 = 20;
like
查詢,不能以萬用字元開頭
比如搜尋標題包含mysql
的文章:
select * from article where title like '%mysql%';
這種SQL的執行計劃用不了索引(like
語句匹配表示式以萬用字元開頭),因此只能做全表掃描,效率極低,在實際工程中幾乎不被採用。而一般會使用第三方提供的支援中文的全文索引來做。
但是 關鍵字查詢 熱搜提醒功能還是可以做的,比如鍵入mysql
之後提醒mysql 教程
、mysql 下載
、mysql 安裝步驟
等。用到的語句是:
select * from article where title like 'mysql%';
這種like
是可以利用索引的(當然前提是title
欄位建立過索引)。
複合索引只對第一個欄位有效
建立複合索引:
alter table person add index(first_name,last_name);
其原理就是將索引先按照從first_name
中提取的關鍵字排序,如果無法確定先後再按照從last_name
提取的關鍵字排序,也就是說該索引表只是按照記錄的first_name
欄位值有序。
因此select * from person where first_name = ?
是可以利用索引的,而select * from person where last_name = ?
無法利用索引。
那麼該複合索引的應用場景是什麼?==組合查詢==
比如對於select * person from first_name = ? and last_name = ?
,複合索引就比對first_name
和last_name
單獨建立索引要高效些。很好理解,複合索引首先二分查詢與first_name = ?
匹配的記錄,再在這些記錄中二分查詢與last_name
匹配的記錄,只涉及到一張索引表。而分別單獨建立索引則是在first_name
索引表中二分找出與first_name = ?
匹配的記錄,再在last_name
索引表中二分找出與last_name = ?
的記錄,兩者取交集。
or,兩邊條件都有索引可用
一但有一邊無索引可用就會導致整個SQL語句的全表掃描
狀態值,不容易使用到索引
如性別、支付狀態等狀態值欄位往往只有極少的幾種取值可能,這種欄位即使建立索引,也往往利用不上。這是因為,一個狀態值可能匹配大量的記錄,這種情況MySQL會認為利用索引比全表掃描的效率低,從而棄用索引。索引是隨機訪問磁碟,而全表掃描是順序訪問磁碟,這就好比有一棟20層樓的寫字樓,樓底下的索引牌上寫著某個公司對應不相鄰的幾層樓,你去公司找人,與其按照索引牌的提示去其中一層樓沒找到再下來看索引牌再上樓,不如從1樓挨個往上找到頂樓。
如何建立索引
- 建立基礎索引:在
where、order by、join
欄位上建立索引。 - 優化,組合索引:基於業務邏輯
- 如果條件經常性出現在一起,那麼可以考慮將多欄位索引升級為==複合索引==
- 如果通過增加個別字段的索引,就可以出現==索引覆蓋==,那麼可以考慮為該欄位建立索引
- 查詢時,不常用到的索引,應該刪除掉
字首索引
語法:index(field(10))
,使用欄位值的前10個字元建立索引,預設是使用欄位的全部內容建立索引。
前提:字首的標識度高。比如密碼就適合建立字首索引,因為密碼幾乎各不相同。
==實操的難度==:在於字首擷取的長度。
我們可以利用select count(*)/count(distinct left(password,prefixLen));
,通過從調整prefixLen
的值(從1自增)檢視不同字首長度的一個平均匹配度,接近1時就可以了(表示一個密碼的前prefixLen
個字元幾乎能確定唯一一條記錄)
索引的儲存結構
BTree
btree(多路平衡查詢樹)是一種廣泛應用於==磁碟上實現索引功能==的一種資料結構,也是大多數資料庫索引表的實現。
以add index(first_name,last_name)
為例:
BTree的一個node可以儲存多個關鍵字,node的大小取決於計算機的檔案系統,因此我們可以通過減小索引欄位的長度使結點儲存更多的關鍵字。如果node中的關鍵字已滿,那麼可以通過每個關鍵字之間的子節點指標來拓展索引表,但是不能破壞結構的有序性,比如按照first_name
第一有序、last_name
第二有序的規則,新新增的韓香
就可以插到韓康
之後。白起 < 韓飛 < 韓康 < 李世民 < 趙奢 < 李尋歡 < 王語嫣 < 楊不悔
。這與二叉搜尋樹的思想是一樣的,只不過二叉搜尋樹的查詢效率是log(2,N)
(以2為底N的對數),而BTree的查詢效率是log(x,N)
(其中x為node的關鍵字數量,可以達到1000以上)。
從log(1000+,N)
可以看出,少量的磁碟讀取即可做到大量資料的遍歷,這也是btree的設計目的。
B+Tree聚簇結構
聚簇結構(也是在BTree上升級改造的)中,關鍵字和記錄是存放在一起的。
在MySQL中,僅僅只有Innodb
的==主鍵索引為聚簇結構==,其它的索引包括Innodb
的非主鍵索引都是典型的BTree結構。
雜湊索引
在索引被載入記憶體時,使用雜湊結構來儲存。
查詢快取
快取
select
語句的查詢結果
在配置檔案中開啟快取
windows上是my.ini
,linux上是my.cnf
在[mysqld]
段中配置query_cache_type
:
- 0:不開啟
- 1:開啟,預設快取所有,需要在SQL語句中增加
select sql-no-cache
提示來放棄快取 - 2:開啟,預設都不快取,需要在SQL語句中增加
select sql-cache
來主動快取(==常用==)
更改配置後需要重啟以使配置生效,重啟後可通過show variables like ‘query_cache_type’;
來檢視:
show variables like 'query_cache_type';
query_cache_type DEMAND
在客戶端設定快取大小
通過配置項query_cache_size
來設定:
show variables like 'query_cache_size';
query_cache_size 0
set global query_cache_size=64*1024*1024;
show variables like 'query_cache_size';
query_cache_size 67108864
將查詢結果快取
select sql_cache * from user;
重置快取
reset query cache;
快取失效問題(大問題)
當資料表改動時,基於該資料表的任何快取都會被刪除。(表層面的管理,不是記錄層面的管理,因此失效率較高)
注意事項
- 應用程式,不應該關心
query cache
的使用情況。可以嘗試使用,但不能由query cache
決定業務邏輯,因為query cache
由DBA來管理。 - 快取是以SQL語句為key儲存的,因此即使SQL語句功能相同,但如果多了一個空格或者大小寫有差異都會導致匹配不到快取。
分割槽
一般情況下我們建立的表對應一組儲存檔案,使用MyISAM
儲存引擎時是一個.MYI
和.MYD
檔案,使用Innodb
儲存引擎時是一個.ibd
和.frm
(表結構)檔案。
當資料量較大時(一般千萬條記錄級別以上),MySQL的效能就會開始下降,這時我們就需要將資料分散到多組儲存檔案,==保證其單個檔案的執行效率==。
最常見的分割槽方案是按id
分割槽,如下將id
的雜湊值對10取模將資料均勻分散到10個.ibd
儲存檔案中:
create table article(
id int auto_increment PRIMARY KEY,
title varchar(64),
content text
)PARTITION by HASH(id) PARTITIONS 10
檢視data
目錄:
==服務端的表分割槽對於客戶端是透明的==,客戶端還是照常插入資料,但服務端會按照分割槽演算法分散儲存資料。
MySQL提供的分割槽演算法
==分割槽依據的欄位必須是主鍵的一部分==,分割槽是為了快速定位資料,因此該欄位的搜尋頻次較高應作為強檢索欄位,否則依照該欄位分割槽毫無意義
hash(field)
相同的輸入得到相同的輸出。輸出的結果跟輸入是否具有規律無關。==僅適用於整型欄位==
key(field)
和hash(field)
的性質一樣,只不過key
是==處理字串==的,比hash()
多了一步從字串中計算出一個整型在做取模操作。
create table article_key(
id int auto_increment,
title varchar(64),
content text,
PRIMARY KEY (id,title) -- 要求分割槽依據欄位必須是主鍵的一部分
)PARTITION by KEY(title) PARTITIONS 10
range演算法
是一種==條件分割槽==演算法,按照資料大小範圍分割槽(將資料使用某種條件,分散到不同的分割槽中)。
如下,按文章的釋出時間將資料按照2018年8月、9月、10月分割槽存放:
create table article_range(
id int auto_increment,
title varchar(64),
content text,
created_time int, -- 釋出時間到1970-1-1的毫秒數
PRIMARY KEY (id,created_time) -- 要求分割槽依據欄位必須是主鍵的一部分
)charset=utf8
PARTITION BY RANGE(created_time)(
PARTITION p201808 VALUES less than (1535731199), -- select UNIX_TIMESTAMP('2018-8-31 23:59:59')
PARTITION p201809 VALUES less than (1538323199), -- 2018-9-30 23:59:59
PARTITION p201810 VALUES less than (1541001599) -- 2018-10-31 23:59:59
);
注意:條件運算子只能使用==less than==,這以為著較小的範圍要放在前面,比如上述p201808,p201819,p201810
分割槽的定義順序依照created_time
數值範圍從小到大,不能顛倒。
insert into article_range values(null,'MySQL優化','內容示例',1535731180);
flush tables; -- 使操作立即重新整理到磁碟檔案
由於插入的文章的釋出時間1535731180
小於1535731199
(2018-8-31 23:59:59
),因此被儲存到p201808
分割槽中,這種演算法的儲存到哪個分割槽取決於資料狀況。
list演算法
也是一種條件分割槽,按照列表值分割槽(in (值列表)
)。
create table article_list(
id int auto_increment,
title varchar(64),
content text,
status TINYINT(1), -- 文章狀態:0-草稿,1-完成但未釋出,2-已釋出
PRIMARY KEY (id,status) -- 要求分割槽依據欄位必須是主鍵的一部分
)charset=utf8
PARTITION BY list(status)(
PARTITION writing values in(0,1), -- 未釋出的放在一個分割槽
PARTITION published values in (2) -- 已釋出的放在一個分割槽
);
insert into article_list values(null,'mysql優化','內容示例',0);
flush tables;
分割槽管理語法
range/list
增加分割槽
前文中我們嘗試使用range
對文章按照月份歸檔,隨著時間的增加,我們需要增加一個月份:
alter table article_range add partition(
partition p201811 values less than (1543593599) -- select UNIX_TIMESTAMP('2018-11-30 23:59:59')
-- more
);
刪除分割槽
alter table article_range drop PARTITION p201808
注意:==刪除分割槽後,分割槽中原有的資料也會隨之刪除!==
key/hash
新增分割槽
alter table article_key add partition partitions 4
銷燬分割槽
alter table article_key coalesce partition 6
key/hash
分割槽的管理不會刪除資料,但是每一次調整(新增或銷燬分割槽)都會將所有的資料重寫分配到新的分割槽上。==效率極低==,最好在設計階段就考慮好分割槽策略。
分割槽的使用
當資料表中的資料量很大時,分割槽帶來的效率提升才會顯現出來。
只有檢索欄位為分割槽欄位時,分割槽帶來的效率提升才會比較明顯。因此,==分割槽欄位的選擇很重要==,並且==業務邏輯要儘可能地根據分割槽欄位做相應調整==(儘量使用分割槽欄位作為查詢條件)。
水平分割和垂直分割
水平分割:通過建立結構相同的幾張表分別儲存資料
垂直分割:將經常一起使用的欄位放在一個單獨的表中,分割後的表記錄之間是一一對應關係。
分表原因
- 為資料庫減壓
- 分割槽演算法侷限
- 資料庫支援不完善(
5.1
之後mysql
才支援分割槽操作)
id重複的解決方案
- 借用第三方應用如
memcache、redis
的id
自增器 - 單獨建一張只包含
id
一個欄位的表,每次自增該欄位作為資料記錄的id
叢集
橫向擴充套件:從根本上(單機的硬體處理能力有限)提升資料庫效能 。由此而生的相關技術:==讀寫分離、負載均衡==
安裝和配置主從複製
環境
Red Hat Enterprise Linux Server release 7.0 (Maipo)
(虛擬機器)mysql5.7
(下載地址)
安裝和配置
解壓到對外提供的服務的目錄(我自己專門建立了一個/export/server
來存放)
tar xzvf mysql-5.7.23-linux-glibc2.12-x86_64.tar.gz -C /export/server
cd /export/server
mv mysql-5.7.23-linux-glibc2.12-x86_64 mysql
新增mysql
目錄的所屬組和所屬者:
groupadd mysql
useradd -r -g mysql mysql
cd /export/server
chown -R mysql:mysql mysql/
chmod -R 755 mysql/
建立mysql
資料存放目錄(其中/export/data
是我建立專門用來為各種服務存放資料的目錄)
mkdir /export/data/mysql
初始化mysql
服務
cd /export/server/mysql
./bin/mysqld --basedir=/export/server/mysql --datadir=/export/data/mysql --user=mysql --pid-file=/export/data/mysql/mysql.pid --initialize
如果成功會顯示
mysql
的root
賬戶的初始密碼,記下來以備後續登入。如果報錯缺少依賴,則使用yum instally
依次安裝即可
配置my.cnf
vim /etc/my.cnf
[mysqld]
basedir=/export/server/mysql
datadir=/export/data/mysql
socket=/tmp/mysql.sock
user=mysql
server-id=10 # 服務id,在叢集時必須唯一,建議設定為IP的第四段
port=3306
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
[mysqld_safe]
log-error=/export/data/mysql/error.log
pid-file=/export/data/mysql/mysql.pid
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
將服務新增到開機自動啟動
cp /export/server/mysql/support-files/mysql.server /etc/init.d/mysqld
啟動服務
service mysqld start
配置環境變數,在/etc/profile
中新增如下內容
# mysql env
MYSQL_HOME=/export/server/mysql
MYSQL_PATH=$MYSQL_HOME/bin
PATH=$PATH:$MYSQL_PATH
export PATH
使配置即可生效
source /etc/profile
使用root
登入
mysql -uroot -p
# 這裡填寫之前初始化服務時提供的密碼
登入上去之後,更改root
賬戶密碼(我為了方便將密碼改為root),否則操作資料庫會報錯
set password=password('root');
flush privileges;
設定服務可被所有遠端客戶端訪問
use mysql;
update user set host='%' where user='root';
flush privileges;
這樣就可以在宿主機使用
navicat
遠端連線虛擬機器linux上的mysql了
配置主從節點
配置master
以linux
(192.168.10.10
)上的mysql
為master
,宿主機(192.168.10.1
)上的mysql
為slave
配置主從複製。
修改master
的my.cnf
如下
[mysqld]
basedir=/export/server/mysql
datadir=/export/data/mysql
socket=/tmp/mysql.sock
user=mysql
server-id=10
port=3306
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
log-bin=mysql-bin # 開啟二進位制日誌
expire-logs-days=7 # 設定日誌過期時間,避免佔滿磁碟
binlog-ignore-db=mysql # 不使用主從複製的資料庫
binlog-ignore-db=information_schema
binlog-ignore-db=performation_schema
binlog-ignore-db=sys
binlog-do-db=test #使用主從複製的資料庫
[mysqld_safe]
log-error=/export/data/mysql/error.log
pid-file=/export/data/mysql/mysql.pid
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
重啟master
service mysqld restart
登入master
檢視配置是否生效(ON
即為開啟,預設為OFF
):
mysql> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin | ON |
+---------------+-------+
在master
的資料庫中建立備份賬號:backup
為使用者名稱,%
表示任何遠端地址,使用者back
可以使用密碼1234
通過任何遠端客戶端連線master
grant replication slave on *.* to 'backup'@'%' identified by '1234'
檢視user
表可以看到我們剛建立的使用者:
mysql> use mysql
mysql> select user,authentication_string,host from user;
+---------------+-------------------------------------------+-----------+
| user | authentication_string | host |
+---------------+-------------------------------------------+-----------+
| root | *81F5E21E35407D884A6CD4A731AEBFB6AF209E1B | % |
| mysql.session | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE | localhost |
| mysql.sys | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE | localhost |
| backup | *A4B6157319038724E3560894F7F932C8886EBFCF | % |
+---------------+-------------------------------------------+-----------+
新建test
資料庫,建立一個article
表以備後續測試
CREATE TABLE `article` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`title` varchar(64) DEFAULT NULL,
`content` text,
PRIMARY KEY (`id`)
) CHARSET=utf8;
重啟服務並重新整理資料庫狀態到儲存檔案中(with read lock
表示在此過程中,客戶端只能讀資料,以便獲得一個一致性的快照)
[root@zhenganwen ~]# service mysqld restart
Shutting down MySQL.... SUCCESS!
Starting MySQL. SUCCESS!
[root@zhenganwen mysql]# mysql -uroot -proot
mysql> flush tables with read lock;
Query OK, 0 rows affected (0.00 sec)
檢視master
上當前的二進位制日誌和偏移量(記一下其中的File
和Position
)
mysql> show master status \G
*************************** 1. row ***************************
File: mysql-bin.000002
Position: 154
Binlog_Do_DB: test
Binlog_Ignore_DB: mysql,information_schema,performation_schema,sys
Executed_Gtid_Set:
1 row in set (0.00 sec)
File
表示實現複製功能的日誌,即上圖中的Binary log
;Position
則表示Binary log
日誌檔案的偏移量之後的都會同步到slave
中,那麼在偏移量之前的則需要我們手動匯入。
主伺服器上面的任何修改都會儲存在二進位制日誌Binary log裡面,從伺服器上面啟動一個I/O thread(實際上就是一個主伺服器的客戶端程序),連線到主伺服器上面請求讀取二進位制日誌,然後把讀取到的二進位制日誌寫到本地的一個Realy log裡面。從伺服器上面開啟一個SQL thread定時檢查Realy log,如果發現有更改立即把更改的內容在本機上面執行一遍。
如果一主多從的話,這時主庫既要負責寫又要負責為幾個從庫提供二進位制日誌。此時可以稍做調整,將二進位制日誌只給某一從,這一從再開啟二進位制日誌並將自己的二進位制日誌再發給其它從。或者是乾脆這個從不記錄只負責將二進位制日誌轉發給其它從,這樣架構起來效能可能要好得多,而且資料之間的延時應該也稍微要好一些
手動匯入,從master
中匯出資料
mysqldump -uroot -proot -hlocalhost test > /export/data/test.sql
將test.sql
中的內容在slave
上執行一遍。
配置slave
修改slave
的my.ini
檔案中的[mysqld]
部分
log-bin=mysql
server-id=1 #192.168.10.1
儲存修改後重啟slave
,WIN+R
->services.msc
->MySQL5.7
->重新啟動
登入slave
檢查log_bin
是否以被開啟:
show VARIABLES like 'log_bin';
配置與master
的同步複製:
stop slave;
change master to
master_host='192.168.10.10', -- master的IP
master_user='backup', -- 之前在master上建立的使用者
master_password='1234',
master_log_file='mysql-bin.000002', -- master上 show master status \G 提供的資訊
master_log_pos=154;
啟用slave
節點並檢視狀態
mysql> start slave;
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.10
Master_User: backup
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 154
Relay_Log_File: DESKTOP-KUBSPE0-relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 154
Relay_Log_Space: 537
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 10
Master_UUID: f68774b7-0b28-11e9-a925-000c290abe05
Master_Info_File: C:\ProgramData\MySQL\MySQL Server 5.7\Data\master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
注意檢視第4、14、15三行,若與我一致,表示
slave
配置成功
測試
關閉master
的讀取鎖定
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)
向master
中插入一條資料
mysql> use test
mysql> insert into article (title,content) values ('mysql master and slave','record the cluster building succeed!:)');
Query OK, 1 row affected (0.00 sec)
檢視slave
是否自動同步了資料
mysql> insert into article (title,content) values ('mysql master and slave','record the cluster building succeed!:)');
Query OK, 1 row affected (0.00 sec)
至此,主從複製的配置成功!:)
使用mysqlreplicate命令快速搭建 Mysql 主從複製
讀寫分離
讀寫分離是依賴於主從複製,而主從複製又是為讀寫分離服務的。因為主從複製要求slave
不能寫只能讀(如果對slave
執行寫操作,那麼show slave status
將會呈現Slave_SQL_Running=NO
,此時你需要按照前面提到的手動同步一下slave
)。
方案一、定義兩種連線
就像我們在學JDBC時定義的DataBase
一樣,我們可以抽取出ReadDataBase,WriteDataBase implements DataBase
,但是這種方式無法利用優秀的執行緒池技術如DruidDataSource
幫我們管理連線,也無法利用Spring AOP
讓連線對DAO
層透明。
方案二、使用Spring AOP
如果能夠使用Spring AOP
解決資料來源切換的問題,那麼就可以和Mybatis
、Druid
整合到一起了。
我們在整合Spring1
和Mybatis
時,我們只需寫DAO介面和對應的SQL
語句,那麼DAO例項是由誰建立的呢?實際上就是Spring
幫我們建立的,它通過我們注入的資料來源,幫我們完成從中獲取資料庫連線、使用連線執行 SQL
語句的過程以及最後歸還連線給資料來源的過程。
如果我們能在呼叫DAO介面時根據介面方法命名規範(增addXXX/createXXX
、刪deleteXX/removeXXX
、改updateXXXX
、查selectXX/findXXX/getXX/queryXXX
)動態地選擇資料來源(讀資料來源對應連線master
而寫資料來源對應連線slave
),那麼就可以做到讀寫分離了。
專案結構
引入依賴
其中,為了方便訪問資料庫引入了mybatis
和druid
,實現資料來源動態切換主要依賴spring-aop
和spring-aspects
<dependencies>
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis-spring</artifactId>
<version>1.3.2</version>
</dependency>
<dependency>
<groupId>org.mybatis</groupId>
<artifactId>mybatis</artifactId>
<version>3.4.6</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.0.8.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>5.0.8.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>5.0.8.RELEASE</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.1.6</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>6.0.2</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.0.8.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aspects</artifactId>
<version>5.0.8.RELEASE</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.16.22</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<version>5.0.8.RELEASE</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
</dependency>
</dependencies>
資料類
package top.zhenganwen.mysqloptimize.entity;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;
@Data
@AllArgsConstructor
@NoArgsConstructor
public class Article {
private int id;
private String title;
private String content;
}
spring配置檔案
其中RoutingDataSourceImpl
是實現動態切換功能的核心類,稍後介紹。
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
<context:property-placeholder location="db.properties"></context:property-placeholder>
<context:component-scan base-package="top.zhenganwen.mysqloptimize"/>
<bean id="slaveDataSource" class="com.alibaba.druid.pool.DruidDataSource">
<property name="driverClassName" value="${db.driverClass}"/>
<property name="url" value="${master.db.url}"></property>
<property name="username" value="${master.db.username}"></property>
<property name="password" value="${master.db.password}"></property>
</bean>
<bean id="masterDataSource" class="com.alibaba.druid.pool.DruidDataSource">
<property name="driverClassName" value="${db.driverClass}"/>
<property name="url" value="${slave.db.url}"></property>
<property name="username" value="${slave.db.username}"></property>
<property name="password" value="${slave.db.password}"></property>
</bean>
<bean id="dataSourceRouting" class="top.zhenganwen.mysqloptimize.dataSource.RoutingDataSourceImpl">
<property name="defaultTargetDataSource" ref="masterDataSource"></property>
<property name="targetDataSources">
<map key-type="java.lang.String" value-type="javax.sql.DataSource">
<entry key="read" value-ref="slaveDataSource"/>
<entry key="write" value-ref="masterDataSource"/>
</map>
</property>
<property name="methodType">
<map key-type="java.lang.String" value-type="java.lang.String">
<entry key="read" value="query,find,select,get,load,"></entry>
<entry key="write" value="update,add,create,delete,remove,modify"/>
</map>
</property>
</bean>
<!-- Mybatis檔案 -->
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
<property name="configLocation" value="classpath:mybatis-config.xml" />
<property name="dataSource" ref="dataSourceRouting" />
<property name="mapperLocations" value="mapper/*.xml"/>
</bean>
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="basePackage" value="top.zhenganwen.mysqloptimize.mapper" />
<property name="sqlSessionFactoryBeanName" value="sqlSessionFactory" />
</bean>
</beans>
dp.properties
master.db.url=jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
master.db.username=root
master.db.password=root
slave.db.url=jdbc:mysql://192.168.10.10:3306/test?useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
slave.db.username=root
slave.db.password=root
db.driverClass=com.mysql.jdbc.Driver
mybatis-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration
PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
"http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>
<typeAliases>
<typeAlias type="top.zhenganwen.mysqloptimize.entity.Article" alias="Article"/>
</typeAliases>
</configuration>
mapper介面和配置檔案
ArticleMapper.java
package top.zhenganwen.mysqloptimize.mapper;
import org.springframework.stereotype.Repository;
import top.zhenganwen.mysqloptimize.entity.Article;
import java.util.List;
@Repository
public interface ArticleMapper {
List<Article> findAll();
void add(Article article);
void delete(int id);
}
ArticleMapper.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd" >
<mapper namespace="top.zhenganwen.mysqloptimize.mapper.ArticleMapper">
<select id="findAll" resultType="Article">
select * from article
</select>
<insert id="add" parameterType="Article">
insert into article (title,content) values (#{title},#{content})
</insert>
<delete id="delete" parameterType="int">
delete from article where id=#{id}
</delete>
</mapper>
核心類
RoutingDataSourceImpl
package top.zhenganwen.mysqloptimize.dataSource;
import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;
import java.util.*;
/**
* RoutingDataSourceImpl class
* 資料來源路由
*
* @author zhenganwen, blog:zhenganwen.top
* @date 2018/12/29
*/
public class RoutingDataSourceImpl extends AbstractRoutingDataSource {
/**
* key為read或write
* value為DAO方法的字首
* 什麼字首開頭的方法使用讀資料員,什麼開頭的方法使用寫資料來源
*/
public static final Map<String, List<String>> METHOD_TYPE_MAP = new HashMap<String, List<String>>();
/**
* 由我們指定資料來源的id,由Spring切換資料來源
*
* @return
*/
@Override
protected Object determineCurrentLookupKey() {
System.out.println("資料來源為:"+DataSourceHandler.getDataSource());
return DataSourceHandler.getDataSource();
}
public void setMethodType(Map<String, String> map) {
for (String type : map.keySet()) {
String methodPrefixList = map.get(type);
if (methodPrefixList != null) {
METHOD_TYPE_MAP.put(type, Arrays.asList(methodPrefixList.split(",")));
}
}
}
}
它的主要功能是,本來我們只配置一個數據源,因此Spring
動態代理DAO介面時直接使用該資料來源,現在我們有了讀、寫兩個資料來源,我們需要加入一些自己的邏輯來告訴呼叫哪個介面使用哪個資料來源(讀資料的介面使用slave
,寫資料的介面使用master
。這個告訴Spring
該使用哪個資料來源的類就是AbstractRoutingDataSource
,必須重寫的方法determineCurrentLookupKey
返回資料來源的標識,結合spring
配置檔案(下段程式碼的5,6兩行)
<bean id="dataSourceRouting" class="top.zhenganwen.mysqloptimize.dataSource.RoutingDataSourceImpl">
<property name="defaultTargetDataSource" ref="masterDataSource"></property>
<property name="targetDataSources">
<map key-type="java.lang.String" value-type="javax.sql.DataSource">
<entry key="read" value-ref="slaveDataSource"/>
<entry key="write" value-ref="masterDataSource"/>
</map>
</property>
<property name="methodType">
<map key-type="java.lang.String" value-type="java.lang.String">
<entry key="read" value="query,find,select,get,load,"></entry>
<entry key="write" value="update,add,create,delete,remove,modify"/>
</map>
</property>
</bean>
如果determineCurrentLookupKey
返回read
那麼使用slaveDataSource
,如果返回write
就使用masterDataSource
。
DataSourceHandler
package top.zhenganwen.mysqloptimize.dataSource;
/**
* DataSourceHandler class
* <p>
* 將資料來源與執行緒繫結,需要時根據執行緒獲取
*
* @author zhenganwen, blog:zhenganwen.top
* @date 2018/12/29
*/
public class DataSourceHandler {
/**
* 繫結的是read或write,表示使用讀或寫資料來源
*/
private static final ThreadLocal<String> holder = new ThreadLocal<String>();
public static void setDataSource(String dataSource) {
System.out.println(Thread.currentThread().getName()+"設定了資料來源型別");
holder.set(dataSource);
}
public static String getDataSource() {
System.out.println(Thread.currentThread().getName()+"獲取了資料來源型別");
return holder.get();
}
}
DataSourceAspect
package top.zhenganwen.mysqloptimize.dataSource;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;
import org.springframework.context.annotation.EnableAspectJAutoProxy;
import org.springframework.stereotype.Component;
import java.util.List;
import java.util.Set;
import static top.zhenganwen.mysqloptimize.dataSource.RoutingDataSourceImpl.METHOD_TYPE_MAP;
/**
* DataSourceAspect class
*
* 配置切面,根據方法字首設定讀、寫資料來源
* 專案啟動時會載入該bean,並按照配置的切面(哪些切入點、如何增強)確定動態代理邏輯
* @author zhenganwen,blog:zhenganwen.top
* @date 2018/12/29
*/
@Component
//宣告這是一個切面,這樣Spring才會做相應的配置,否則只會當做簡單的bean注入
@Aspect
@EnableAspectJAutoProxy
public class DataSourceAspect {
/**
* 配置切入點:DAO包下的所有類的所有方法
*/
@Pointcut("execution(* top.zhenganwen.mysqloptimize.mapper.*.*(..))")
public void aspect() {
}
/**
* 配置前置增強,物件是aspect()方法上配置的切入點
*/
@Before("aspect()")
public void before(JoinPoint point) {
String className = point.getTarget().getClass