你都是會點啥技術（五）— 數據庫
寫在前面的話：還記得2018年的時候開發的項目上線，經過大概一個月，因爲數據量增加，造成項目查詢頁面的延遲，因爲項目使用的羣體是固定的，所以當時提出來後並沒有着力解決，不過我一直對數據庫優化這塊耿耿於懷，抽出時間來基於MYSQL學習一下！
1.概念知識補充
數據庫系統圖：
2.查詢優化技術分類
（1.）查詢重用：①查詢結果重用；②查詢計劃重用。
（2.）查詢重寫規則：①基於關係型代數；②視圖重寫、子查詢優化、等價位置重寫、條件化簡、外聯接消除、聯接消除、嵌套聯接消除；③語義優化。
（3.）查詢優化算法（基於代價估算模型）：①單表掃描算法（全表掃描、索引掃描、行定位掃描）；②兩表連接算法（嵌套聯接算法、歸併連接算法、哈希連接算法）；③多表連接算法（貪婪）。
（4.）並行查詢優化：利用分解查詢SQL，進行並行計算查詢，提高查詢目的。
（5.）分佈式查詢優化：利用分佈式系統優化查詢。
3.數據庫調優
數據庫調優包括數據庫管理系統優化和查詢優化，主要目的是使數據庫有更高的吞吐量和更高的響應時間。
4.差不多了，實際應用開始走起！
第一招：explain：
顯示了mysql如何使用索引來處理語句以及連接表。可以幫助選擇更好的索引和寫出更優化的查詢語句!我們以select語句爲例子
詳情請參考：https://www.cnblogs.com/yycc/p/7338894.html
第二招：子查詢優化：
1.子查詢合併：
原理：把多次表掃描、多次連接減少爲低次表掃描和低次連接。
/*
*優化前
*/
SELECT * FROM t_user WHERE zhuhuid < 20 AND (
EXISTS (SELECT id FROM t_zhuhu WHERE id<15 AND id=5) OR
EXISTS (SELECT id FROM t_zhuhu WHERE id<15 AND id=10));
/*
*優化後
*/
SELECT * FROM t_user WHERE zhuhuid < 20 AND (
EXISTS (SELECT id FROM t_zhuhu WHERE id<15 AND id=5 OR id=10))
2.子查詢展開：
原理：將子查詢上拉到父查詢，實質是把某些子查詢重寫爲等價的多表連接操作，這樣有關的的訪問路徑、連接方法、連接順序可能被有效使用、使得查詢語句的層次儘可能減少。
/*
*優化前
*/
SELECT * FROM t_user a,(SELECT * FROM t_zhuhu WHERE
t_zhuhu.id>10) b WHERE a.zhuhuid<10 AND b.id<20
/*
*優化後
*/
SELECT * FROM t_user a,t_zhuhu b WHERE a.zhuhuid<10
AND b.id<20 AND b.id>10
3.聚集子查詢消除
原理：利用SQL函數消除子查詢的優化技術。
SELECT * FROM t_user a WHERE a.zhuhuid > (SELECT AVG(b.id)
FROM t_zhuhu b)
能夠做子查詢優化格式要求：
1.簡單Select查詢中的子查詢，
2.帶有DISTINCT、ORDERBY、LIMIT操作的簡單SELECT查詢中的子查詢。
不能做子查詢優化的格式：
1.帶有UNION操作
2.帶有GROUPBY、HAVING、聚集函數
3.使用ORDERBY中帶有LIMIT
4.內表、外表的個數超過MySQL支持的最大表的連接數（mysql最大連接數63）。
第三招：視圖重寫
定義：視圖是數據庫中基於表的一種對象，把對錶的查詢固化，這種固化是視圖。
原理：MySQL支持簡單視圖優化技術，MySQL把視圖轉爲對基表的查詢，然後進行類似子查詢的優化。但不支持複雜視圖（帶有GROUP BY、Oreder By 等操作稱爲複雜視圖）優化。
/*
* 創建視圖
*/
CREATE VIEW t_view AS SELECT * FROM t_user
/*
* 未使用視圖
*/
SELECT a.id FROM (SELECT id,zhuhuid FROM t_user) as a
WHERE a.zhuhuid>10
/*
* 使用視圖
*/
SELECT id FROM t_view WHERE zhuhuid>10
第四招：等價謂詞重寫
原理：把邏輯表達式重寫成等價的且效率更高的形式，提高查詢執行效率。
1.LIKE規則重寫
如果name列上存在索引，則可以利用索引提高查詢效率。
/*
* 重寫前
*/
name LIKE 'abc'
/*
* 重寫後
*/
name = 'abc'
2.BETWEEN-AND規則
如果sno上建立了索引，則可以用索引掃描代替原來BETWEEN-AND謂詞限定的全表掃描，從而提高了查詢的效率。
/*
* 重寫前
*/
sno BETWEEN 10 AND 20
/*
* 重寫後
*/
sno >=10 AND sno <=20
3.IN轉換OR規則
看實際情況使用，如果age列上存在索引，則轉換後查詢效率會提高。
/*
* 重寫前
*/
age IN (8,12,21)
/*
* 重寫後
*/
age=8 OR age=12 OR age=21
4.NOT規則
如果col_1建立了索引，則可以用索引掃描代替原來的全表掃描，從而提高查詢的效率
/*
* 重寫前
*/
NOT (col_1 != col_2)
/*
* 重寫後
*/
col_1 = col_2
5.OR重寫並集規則
可以分別利用列sex和age上的索引，進程索引掃描，執行UNION操作獲得最終結果。
/*
* 重寫前
*/
SELECT * FROM student WHERE (sex='f' and age>15) OR age>18
/*
* 重寫後
*/
SELECT * FROM student WHERE sex='f' and age>15
UNION
SELECT * FROM student WHERE age>18
第五招：條件化簡
1.把HAVING條件併入WHERE條件，前提是SQL中不存在GROUPBY條件或聚集函數的情況下，才能將HAVING條件與WHERE條件合併。
/*
*例子
*/
SELECT * FROM t1 WHERE a1>1 having a2=2
/*
*等價於
*/
SELECT * FROM t1 WHERE a1>1 and a2=2
2.去除表達式中冗餘的括號
減少語法分析時產生的AND和OR樹的層次。減少了CPU的消耗
/*
*例子
*/
((a AND b)AND (c AND d))
/*
*化簡爲
*/
a AND b AND c AND d
3.常量傳遞
/*
*例子
*/
col_1=col_2 AND col_2=3
/*
*化簡爲
*/
col_1=3 AND col_2=3
4.消除死碼，表達式計算，等式變換，不等式變換，布爾表達式變換
儘量減少數據庫去計算，把一些計算進行優化，儘量利用索引，提升數據庫查詢效率。
第六招.外連接消除、嵌套連接消除、連接消除
連接消除：去掉的是被連接的某個對象。
外連接消除：去掉的事外連接的語義，變形爲內連接。
嵌套連接消除：就是消除嵌套的連接層次，把多個層次的連接減少爲較少層次的連接，儘量"扁平化"。
第七招.8.語義優化
1.連接消除
2.連接引入
3.謂詞引入
4.檢測空回答集
5.排序優化
6.唯一性使用
9.非SPJ的優化
1.GROUP BY、ORDER BY優化，儘量利用索引。
物理優化
1.索引
優點：提高少量數據的獲取/檢索速度
缺點：佔用存儲空間、多個索引耗費索引的挑選時間、降低寫操作的性能，需要實時維護索引、併發情況下索引的維護高度複雜。
不使用索引：數據的重複度高、選擇率高於10%、表的數據量少
MYSQL高級教程
記錄一下學習過程！
1.觸發器
四個必要條件：監視地點（table）、監視事件（insert/update/delete）、觸發時間（after/before）、觸發事件（insert/update/delete）
觸發器使用語法練習
/*
* 聲明以;爲結尾符
*/
delemiter ;
/*
* 監聽table_1表在table_1表有insert事件之後更新table_2
*/
create trigger trigger_1
after
insert
on table_1
for each row
begin
update table_2 set num=num-1;
end;
/*
*new.num獲取table_1新插入的num值，相反old.num是獲取表刪除的num值
* insert 只能用 new
* delete 只能用 old
* update 可用 new/old
*/
create trigger trigger_2
after
insert
on table_1
for each row
begin
update table_2 set num=num-new.num;
end;
/*
*declare 聲明變量
*select num into rnum/set new.num = rnum;賦值
*if 條件 then 語句 end if; 判斷語句
*/
create trigger trigger_3
before
insert
on table_1
for each row
begin
declare rnum int;
select num into rnum from table_2 where id=new.id;
if new.num > runm then
set new.num = rnum;
end if;
update table_2 set num=num-new.num;
end;
2.存儲過程
/*
*創建存儲過程語法
*/
create procedure procedureName()
begin
--sql語句;
ends;
/*
*查看已有的procedure
*/
show procedure status;
/*
*調用存儲過程語法
*/
call procedureName()
/*
* 給存儲過程傳參數
*/
create procedure p1(width int,height int)
begin
select concat('你的面積是',width * height);
if width > height then
select '你挺胖';
elseif width<height then
select '你挺瘦';
else
select '你挺方';
end if;
end;
--調用
CALL p1(4,5)
/*
*in 輸入 out 輸出
*/
create procedure p2(in n int,out total int)
begin
declare num int default 0;
set total = 0;
while num < n do
set num = num + 1;
set total = total + num;
end while;
end;
call p2(100,@total)
SELECT @total
/*
*inout 輸入處理後輸出，即是輸入又是輸出
*/
create procedure p3(inout age int)
begin
SELECT CONCAT("20年後你的年齡是：",age+20);
end;
set @age =18;
call p3(@age)
/*
*repeat的用法
*/
--刪除存儲過程
drop procedure p4
create procedure p4()
begin
declare num int default 0;
declare total int default 0;
repeat
set num = num +1;
set total = total + num;
until num >= 100 end repeat;
select total;
end
call p4()
/*
*case的用法
*RAND()隨機0.1-1的數
*floor()取整
*/
create procedure p5()
begin
declare a int default 1;
set a = floor(RAND()*5);
case a
WHEN 0 then select "我是0";
WHEN 1 then select "我是1";
WHEN 2 then select "我是2";
else select "我不是0,1,2";
end case;
end;
call p5();
3.遊標
定義：sql查詢多條結果集，利用遊標可以一次取出一行
聲明：declare 遊標名 cursor for sql查詢結果集
打開：open 遊標名
取值：fetch 遊標名 into 值1，值2
關閉：close 遊標名
CREATE TABLE t_student ( sid INT PRIMARY KEY, sname VARCHAR ( 20 ), sage INT );
INSERT INTO t_student ( sid, sname, sage ) VALUES ( 1, "李一", 10 );
INSERT INTO t_student ( sid, sname, sage ) VALUES ( 2, "李二", 20 );
INSERT INTO t_student ( sid, sname, sage ) VALUES ( 3, "李三", 30 );
create procedure p6()
begin
declare row_sname varchar(20);
declare you int default 1;
declare c1 cursor for select sname from t_student;
declare exit handler for not found set you =0;
--如果句柄沒有值設置you爲0
--exit handler觸發後，後面的語句不再執行
--continue handler觸發後，後面的語句繼續執行
--undo handler觸發後，前面的語句撤銷 mysql不支持
open c1;
repeat
fetch c1 into row_sname;SELECT row_sname;
until you = 0 end repeat;
close c1;
end;
call p6
4.用戶權限設置
5.主從複製
配置：https://www.cnblogs.com/liaojie970/p/6198547.html
MySQL數據庫事物
1.事物的四種隔離級別
由低到高依次爲Read uncommitted(未授權讀取、讀未提交)、Read committed（授權讀取、讀提交）、Repeatable read（可重複讀取）、Serializable（序列化），這四個級別可以逐個解決髒讀、不可重複讀、幻讀這幾類問題。
(1)Read uncommitted(未授權讀取、讀未提交)
1）其他事務讀未提交數據，出現髒讀；
2）如果一個事務已經開始寫數據，則另外一個事務則不允許同時進行寫操作，但允許其他事務讀此行數據。該隔離級別可以通過“排他寫鎖”實現。
3）避免了更新丟失，卻可能出現髒讀。也就是說事務B讀取到了事務A未提交的數據。
（讀未提交：一個事務寫數據時，只允許其他事務對這行數據進行讀，所以會出現髒讀，事務T1讀取T2未提交的數據）
(2)Read committed（授權讀取、讀提交）
1）允許寫事務，所以會出現不可重複讀
2）讀取數據的事務允許其他事務繼續訪問該行數據，但是未提交的寫事務將會禁止其他事務訪問該行。
3）該隔離級別避免了髒讀，但是卻可能出現不可重複讀。事務A事先讀取了數據，事務B緊接了更新了數據，並提交了事務，而事務A再次讀取該數據時，數據已經發生了改變。
（讀已提交：讀取數據的事務允許其他事務進行操作，避免了髒讀，但是會出現不可重複讀，事務T1讀取數據，T2緊接着更新數據並提交數據，事務T1再次讀取數據的時候，和第一次讀的不一樣。即虛讀）
(3)Repeatable read（可重複讀取）
1）禁止寫事務；
2）讀取數據的事務將會禁止寫事務（但允許讀事務），寫事務則禁止任何其他事務。
3）避免了不可重複讀取和髒讀，但是有時可能出現幻讀。這可以通過“共享讀鎖”和“排他寫鎖”實現。
（可重複讀：讀事務會禁止所有的寫事務，但是允許讀事務，避免了不可重複讀和髒讀，但是會出現幻讀，即第二次查詢數據時會包含第一次查詢中未出現的數據）
(4)Serializable（序列化）
1）禁止任何事務，一個一個進行；
2）提供嚴格的事務隔離。它要求事務序列化執行，事務只能一個接着一個地執行，但不能併發執行。如果僅僅通過“行級鎖”是無法實現事務序列化的，必須通過其他機制保證新插入的數據不會被剛執行查詢操作的事務訪問到。
3）序列化是最高的事務隔離級別，同時代價也花費最高，性能很低，一般很少使用，在該級別下，事務順序執行，不僅可以避免髒讀、不可重複讀，還避免了幻讀。
基於mysql8.0版本查看，如果是老版本把
select @@global.transaction_isolation;
的transaction換成tx例
SELECT @@global.tx_isolation
//查看系統當前隔離級別
mysql> select @@global.transaction_isolation;
+--------------------------------+
| @@global.transaction_isolation |
+--------------------------------+
| REPEATABLE-READ |
+--------------------------------+
1 row in set (0.00 sec)
//查看當前會話隔離級別
mysql> select @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ |
+-------------------------+
1 row in set (0.00 sec)
//設置當前會話隔離級別
mysql> set transaction isolation level repeatable read;
Query OK, 0 rows affected (0.00 sec)
//設置系統當前隔離級別
mysql> set global transaction isolation level repeatable read;
Query OK, 0 rows affected (0.00 sec)
2.事物的四大特性
數據庫中事務的四大特性（ACID）：原子性、一致性、隔離性、持久性。如果一個數據庫聲稱支持事務的操作，那麼該數據庫必須要具備以下四個特性：
（1）原子性（Atomicity）
原子性是指事務包含的所有操作要麼全部成功，要麼全部失敗回滾，因此事務的操作如果成功就必須要完全應用到數據庫，如果操作失敗則不能對數據庫有任何影響。
（2）一致性（Consistency）
一致性是指事務必須使數據庫從一個一致性狀態變換到另一個一致性狀態，也就是說一個事務執行之前和執行之後都必須處於一致性狀態。
如：拿轉賬來說，假設用戶A和用戶B兩者的錢加起來一共是5000，那麼不管A和B之間如何轉賬，轉幾次賬，事務結束後兩個用戶的錢相加起來應該還得是5000，這就是事務的一致性。
（3）隔離性（Isolation）
隔離性是當多個用戶併發訪問數據庫時，比如操作同一張表時，數據庫爲每一個用戶開啓的事務，不能被其他事務的操作所幹擾，多個併發事務之間要相互隔離。
即要達到這麼一種效果：對於任意兩個併發的事務T1和T2，在事務T1看來，T2要麼在T1開始之前就已經結束，要麼在T1結束之後纔開始，這樣每個事務都感覺不到有其他事務在併發地執行。
（4）持久性（Durability）
持久性是指一個事務一旦被提交了，那麼對數據庫中的數據的改變就是永久性的，即便是在數據庫系統遇到故障的情況下也不會丟失提交事務的操作。
例如：我們在使用JDBC操作數據庫時，在提交事務方法後，提示用戶事務操作完成，當我們程序執行完成直到看到提示後，就可以認定事務以及正確提交，即使這時候數據庫出現了問題，也必須要將我們的事務完全執行完成，否則就會造成我們看到提示事務處理完畢，但是數據庫因爲故障而沒有執行事務的重大錯誤。
3.出現的三個問題
(1) 髒讀
1.髒讀定義：
1）說法1：指在一個事務處理過程裏讀取了另一個未提交的事務中的數據，讀取數據不一致。
2）說法2：指事務A對數據進行增刪改操作，但未提交，另一事務B可以讀取到未提交的數據。如果事務A這時候回滾了，則第二個事務B讀取的即爲髒數據。
2.舉例：
當一個事務正在多次修改某個數據，而在這個事務中多次的修改都還未提交，這時一個併發的事務來訪問該數據，就會造成兩個事務得到的數據不一致。
例如：用戶A向用戶B轉賬100元，對應SQL命令如下
update account set money=money+100 where name=’B’; (此時A通知B)
update account set money=money - 100 where name=’A’;
當只執行第一條SQL時，A通知B查看賬戶，B發現確實錢已到賬（此時即發生了髒讀），而之後無論第二條SQL是否執行，只要該事務不提交，則所有操作都將回滾，那麼當B以後再次查看賬戶時就會發現錢其實並沒有轉。
(2) 不可重複讀
1.不可重複讀定義：
1）說法1：是指在對於數據庫中的某個數據，一個事務範圍內多次查詢卻返回了不同的數據值，這是由於在查詢間隔，被另一個事務修改並提交了。
2）說法2：一個事務A中發生了兩次讀操作，第一次讀操作和第二次讀操作之間，另一個事務B對數據進行了修改，這時兩個事務讀取的數據不一致。
2.舉例：
例如事務T1在讀取某一數據，而事務T2立馬修改了這個數據並且提交事務給數據庫，事務T1再次讀取該數據就得到了不同的結果，發送了不可重複讀。
3.不可重複讀和髒讀的區別：
髒讀是某一事務讀取了另一個事務未提交的髒數據，而不可重複讀則是讀取了前一事務提交的數據。
在某些情況下，不可重複讀並不是問題，比如我們多次查詢某個數據當然以最後查詢得到的結果爲主。但在另一些情況下就有可能發生問題，例如對於同一個數據A和B依次查詢就可能不同，A和B就可能打起來了……
(3)虛讀(幻讀)
1.幻讀定義：
1）說法1：是事務非獨立執行時發生的一種現象。
2）說法2：第一個事務A對一定範圍的數據進行批量修改，第二個事務B在這個範圍增加一條數據，這時候第一個事務就會丟失對新增數據的修改。
2.舉例：
例如事務T1對一個表中所有的行的某個數據項做了從“1”修改爲“2”的操作，這時事務T2又對這個表中插入了一行數據項，而這個數據項的數值還是爲“1”並且提交給數據庫。而操作事務T1的用戶如果再查看剛剛修改的數據，會發現還有一行沒有修改，其實這行是從事務T2中添加的，就好像產生幻覺一樣，這就是發生了幻讀。
3.幻讀和不可重複讀區別：
都是讀取了另一條已經提交的事務（這點就髒讀不同），所不同的是不可重複讀查詢的都是同一個數據項，而幻讀針對的是一批數據整體（比如數據的個數）。
4.鎖知識
一.概述
數據庫鎖定機制簡單來說，就是數據庫爲了保證數據的一致性，而使各種共享資源在被併發訪問變得有序所設計的一種規則。對於任何一種數據庫來說都需要有相應的鎖定機制，所以MySQL自然也不能例外。MySQL數據庫由於其自身架構的特點，存在多種數據存儲引擎，每種存儲引擎所針對的應用場景特點都不太一樣，爲了滿足各自特定應用場景的需求，每種存儲引擎的鎖定機制都是爲各自所面對的特定場景而優化設計，所以各存儲引擎的鎖定機制也有較大區別。MySQL各存儲引擎使用了三種類型（級別）的鎖定機制：表級鎖定，行級鎖定和頁級鎖定。
1.表級鎖定（table-level）
表級別的鎖定是MySQL各存儲引擎中最大顆粒度的鎖定機制。該鎖定機制最大的特點是實現邏輯非常簡單，帶來的系統負面影響最小。所以獲取鎖和釋放鎖的速度很快。由於表級鎖一次會將整個表鎖定，所以可以很好的避免困擾我們的死鎖問題。
當然，鎖定顆粒度大所帶來最大的負面影響就是出現鎖定資源爭用的概率也會最高，致使並大度大打折扣。
使用表級鎖定的主要是MyISAM，MEMORY，CSV等一些非事務性存儲引擎。
2.行級鎖定（row-level）
行級鎖定最大的特點就是鎖定對象的顆粒度很小，也是目前各大數據庫管理軟件所實現的鎖定顆粒度最小的。由於鎖定顆粒度很小，所以發生鎖定資源爭用的概率也最小，能夠給予應用程序儘可能大的併發處理能力而提高一些需要高併發應用系統的整體性能。
雖然能夠在併發處理能力上面有較大的優勢，但是行級鎖定也因此帶來了不少弊端。由於鎖定資源的顆粒度很小，所以每次獲取鎖和釋放鎖需要做的事情也更多，帶來的消耗自然也就更大了。此外，行級鎖定也最容易發生死鎖。
使用行級鎖定的主要是InnoDB存儲引擎。
3.頁級鎖定（page-level）
頁級鎖定是MySQL中比較獨特的一種鎖定級別，在其他數據庫管理軟件中也並不是太常見。頁級鎖定的特點是鎖定顆粒度介於行級鎖定與表級鎖之間，所以獲取鎖定所需要的資源開銷，以及所能提供的併發處理能力也同樣是介於上面二者之間。另外，頁級鎖定和行級鎖定一樣，會發生死鎖。
在數據庫實現資源鎖定的過程中，隨着鎖定資源顆粒度的減小，鎖定相同數據量的數據所需要消耗的內存數量是越來越多的，實現算法也會越來越複雜。不過，隨着鎖定資源顆粒度的減小，應用程序的訪問請求遇到鎖等待的可能性也會隨之降低，系統整體併發度也隨之提升。
使用頁級鎖定的主要是BerkeleyDB存儲引擎。
總的來說，MySQL這3種鎖的特性可大致歸納如下：
表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的概率最高，併發度最低；
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高；
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度一般。
適用：從鎖的角度來說，表級鎖更適合於以查詢爲主，只有少量按索引條件更新數據的應用，如Web應用；而行級鎖則更適合於有大量按索引條件併發更新少量不同數據，同時又有併發查詢的應用，如一些在線事務處理（OLTP）系統。
二、表級鎖定
由於MyISAM存儲引擎使用的鎖定機制完全是由MySQL提供的表級鎖定實現，所以下面我們將以MyISAM存儲引擎作爲示例存儲引擎。
1.MySQL表級鎖的鎖模式
MySQL的表級鎖有兩種模式：表共享讀鎖（Table Read Lock）和表獨佔寫鎖（Table Write Lock）。鎖模式的兼容性：
對MyISAM表的讀操作，不會阻塞其他用戶對同一表的讀請求，但會阻塞對同一表的寫請求；
對MyISAM表的寫操作，則會阻塞其他用戶對同一表的讀和寫操作；
MyISAM表的讀操作與寫操作之間，以及寫操作之間是串行的。當一個線程獲得對一個表的寫鎖後，只有持有鎖的線程可以對錶進行更新操作。其他線程的讀、寫操作都會等待，直到鎖被釋放爲止。
2.如何加表鎖
MyISAM在執行查詢語句（SELECT）前，會自動給涉及的所有表加讀鎖，在執行更新操作（UPDATE、DELETE、INSERT等）前，會自動給涉及的表加寫鎖，這個過程並不需要用戶干預，因此，用戶一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。
3.MyISAM表鎖優化建議
對於MyISAM存儲引擎，雖然使用表級鎖定在鎖定實現的過程中比實現行級鎖定或者頁級鎖所帶來的附加成本都要小，鎖定本身所消耗的資源也是最少。但是由於鎖定的顆粒度比較到，所以造成鎖定資源的爭用情況也會比其他的鎖定級別都要多，從而在較大程度上會降低併發處理能力。所以，在優化MyISAM存儲引擎鎖定問題的時候，最關鍵的就是如何讓其提高併發度。由於鎖定級別是不可能改變的了，所以我們首先需要儘可能讓鎖定的時間變短，然後就是讓可能併發進行的操作儘可能的併發。
(1) 查詢表級鎖爭用情況
MySQL內部有兩組專門的狀態變量記錄系統內部鎖資源爭用情況：
mysql> show status like 'table%';
+----------------------------+---------+
| Variable_name | Value |
+----------------------------+---------+
| Table_locks_immediate | 100 |
| Table_locks_waited | 11 |
+----------------------------+---------+
這裏有兩個狀態變量記錄MySQL內部表級鎖定的情況，兩個變量說明如下：
Table_locks_immediate：產生表級鎖定的次數；
Table_locks_waited：出現表級鎖定爭用而發生等待的次數；
兩個狀態值都是從系統啓動後開始記錄，出現一次對應的事件則數量加1。如果這裏的Table_locks_waited狀態值比較高，那麼說明系統中表級鎖定爭用現象比較嚴重，就需要進一步分析爲什麼會有較多的鎖定資源爭用了。
（2）縮短鎖定時間
如何讓鎖定時間儘可能的短呢？唯一的辦法就是讓我們的Query執行時間儘可能的短。
a)盡兩減少大的複雜Query，將複雜Query分拆成幾個小的Query分佈進行；
b)儘可能的建立足夠高效的索引，讓數據檢索更迅速；
c)儘量讓MyISAM存儲引擎的表只存放必要的信息，控制字段類型；
d)利用合適的機會優化MyISAM表數據文件。
（3）分離能並行的操作
說到MyISAM的表鎖，而且是讀寫互相阻塞的表鎖，可能有些人會認爲在MyISAM存儲引擎的表上就只能是完全的串行化，沒辦法再並行了。大家不要忘記了，MyISAM的存儲引擎還有一個非常有用的特性，那就是ConcurrentInsert（併發插入）的特性。
MyISAM存儲引擎有一個控制是否打開Concurrent Insert功能的參數選項：concurrent_insert，可以設置爲0，1或者2。三個值的具體說明如下：
concurrent_insert=2，無論MyISAM表中有沒有空洞，都允許在表尾併發插入記錄；
concurrent_insert=1，如果MyISAM表中沒有空洞（即表的中間沒有被刪除的行），MyISAM允許在一個進程讀表的同時，另一個進程從表尾插入記錄。這也是MySQL的默認設置；
concurrent_insert=0，不允許併發插入。
可以利用MyISAM存儲引擎的併發插入特性，來解決應用中對同一表查詢和插入的鎖爭用。例如，將concurrent_insert系統變量設爲2，總是允許併發插入；同時，通過定期在系統空閒時段執行OPTIMIZE TABLE語句來整理空間碎片，收回因刪除記錄而產生的中間空洞。
（4）合理利用讀寫優先級
MyISAM存儲引擎的是讀寫互相阻塞的，那麼，一個進程請求某個MyISAM表的讀鎖，同時另一個進程也請求同一表的寫鎖，MySQL如何處理呢？
答案是寫進程先獲得鎖。不僅如此，即使讀請求先到鎖等待隊列，寫請求後到，寫鎖也會插到讀鎖請求之前。
這是因爲MySQL的表級鎖定對於讀和寫是有不同優先級設定的，默認情況下是寫優先級要大於讀優先級。
所以，如果我們可以根據各自系統環境的差異決定讀與寫的優先級：
通過執行命令SET LOW_PRIORITY_UPDATES=1，使該連接讀比寫的優先級高。如果我們的系統是一個以讀爲主，可以設置此參數，如果以寫爲主，則不用設置；
通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優先級。
雖然上面方法都是要麼更新優先，要麼查詢優先的方法，但還是可以用其來解決查詢相對重要的應用（如用戶登錄系統）中，讀鎖等待嚴重的問題。
另外，MySQL也提供了一種折中的辦法來調節讀寫衝突，即給系統參數max_write_lock_count設置一個合適的值，當一個表的讀鎖達到這個值後，MySQL就暫時將寫請求的優先級降低，給讀進程一定獲得鎖的機會。
這裏還要強調一點：一些需要長時間運行的查詢操作，也會使寫進程“餓死”，因此，應用中應儘量避免出現長時間運行的查詢操作，不要總想用一條SELECT語句來解決問題，因爲這種看似巧妙的SQL語句，往往比較複雜，執行時間較長，在可能的情況下可以通過使用中間表等措施對SQL語句做一定的“分解”，使每一步查詢都能在較短時間完成，從而減少鎖衝突。如果複雜查詢不可避免，應儘量安排在數據庫空閒時段執行，比如一些定期統計可以安排在夜間執行。
三、行級鎖定
行級鎖定不是MySQL自己實現的鎖定方式，而是由其他存儲引擎自己所實現的，如廣爲大家所知的InnoDB存儲引擎，以及MySQL的分佈式存儲引擎NDBCluster等都是實現了行級鎖定。考慮到行級鎖定君由各個存儲引擎自行實現，而且具體實現也各有差別，而InnoDB是目前事務型存儲引擎中使用最爲廣泛的存儲引擎，所以這裏我們就主要分析一下InnoDB的鎖定特性。
1.InnoDB鎖定模式及實現機制
考慮到行級鎖定君由各個存儲引擎自行實現，而且具體實現也各有差別，而InnoDB是目前事務型存儲引擎中使用最爲廣泛的存儲引擎，所以這裏我們就主要分析一下InnoDB的鎖定特性。
總的來說，InnoDB的鎖定機制和Oracle數據庫有不少相似之處。InnoDB的行級鎖定同樣分爲兩種類型，共享鎖和排他鎖，而在鎖定機制的實現過程中爲了讓行級鎖定和表級鎖定共存，InnoDB也同樣使用了意向鎖（表級鎖定）的概念，也就有了意向共享鎖和意向排他鎖這兩種。
當一個事務需要給自己需要的某個資源加鎖的時候，如果遇到一個共享鎖正鎖定着自己需要的資源的時候，自己可以再加一個共享鎖，不過不能加排他鎖。但是，如果遇到自己需要鎖定的資源已經被一個排他鎖佔有之後，則只能等待該鎖定釋放資源之後自己才能獲取鎖定資源並添加自己的鎖定。而意向鎖的作用就是當一個事務在需要獲取資源鎖定的時候，如果遇到自己需要的資源已經被排他鎖佔用的時候，該事務可以需要鎖定行的表上面添加一個合適的意向鎖。如果自己需要一個共享鎖，那麼就在表上面添加一個意向共享鎖。而如果自己需要的是某行（或者某些行）上面添加一個排他鎖的話，則先在表上面添加一個意向排他鎖。意向共享鎖可以同時並存多個，但是意向排他鎖同時只能有一個存在。所以，可以說InnoDB的鎖定模式實際上可以分爲四種：共享鎖（S），排他鎖（X），意向共享鎖（IS）和意向排他鎖（IX），我們可以通過以下表格來總結上面這四種所的共存邏輯關係：
如果一個事務請求的鎖模式與當前的鎖兼容，InnoDB就將請求的鎖授予該事務；反之，如果兩者不兼容，該事務就要等待鎖釋放。
意向鎖是InnoDB自動加的，不需用戶干預。對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數據集加排他鎖（X)；對於普通SELECT語句，InnoDB不會加任何鎖；事務可以通過以下語句顯示給記錄集加共享鎖或排他鎖。
共享鎖（S）
SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
排他鎖（X)
SELECT * FROM table_name WHERE ... FOR UPDATE
用SELECT … IN SHARE MODE獲得共享鎖，主要用在需要數據依存關係時來確認某行記錄是否存在，並確保沒有人對這個記錄進行UPDATE或者DELETE操作。
但是如果當前事務也需要對該記錄進行更新操作，則很有可能造成死鎖，對於鎖定行記錄後需要進行更新操作的應用，應該使用SELECT… FOR UPDATE方式獲得排他鎖。
2.InnoDB行鎖實現方式
InnoDB行鎖是通過給索引上的索引項加鎖來實現的，只有通過索引條件檢索數據，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖
在實際應用中，要特別注意InnoDB行鎖的這一特性，不然的話，可能導致大量的鎖衝突，從而影響併發性能。下面通過一些實際例子來加以說明。
（1）在不通過索引條件查詢的時候，InnoDB確實使用的是表鎖，而不是行鎖。
（2）由於MySQL的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果是使用相同的索引鍵，是會出現鎖衝突的。
（3）當表有多個索引的時候，不同的事務可以使用不同的索引鎖定不同的行，另外，不論是使用主鍵索引、唯一索引或普通索引，InnoDB都會使用行鎖來對數據加鎖。
（4）即便在條件中使用了索引字段，但是否使用索引來檢索數據是由MySQL通過判斷不同執行計劃的代價來決定的，如果MySQL認爲全表掃描效率更高，比如對一些很小的表，它就不會使用索引，這種情況下InnoDB將使用表鎖，而不是行鎖。因此，在分析鎖衝突時，別忘了檢查SQL的執行計劃，以確認是否真正使用了索引。
3.間隙鎖（Next-Key鎖）
當我們用範圍條件而不是相等條件檢索數據，並請求共享或排他鎖時，InnoDB會給符合條件的已有數據記錄的索引項加鎖；
對於鍵值在條件範圍內但並不存在的記錄，叫做“間隙（GAP)”，InnoDB也會對這個“間隙”加鎖，這種鎖機制就是所謂的間隙鎖（Next-Key鎖）。
例：
假如emp表中只有101條記錄，其empid的值分別是 1,2,…,100,101，下面的SQL：
mysql> select * from emp where empid > 100 for update;
是一個範圍條件的檢索，InnoDB不僅會對符合條件的empid值爲101的記錄加鎖，也會對empid大於101（這些記錄並不存在）的“間隙”加鎖。
InnoDB使用間隙鎖的目的：
（1）防止幻讀，以滿足相關隔離級別的要求。對於上面的例子，要是不使用間隙鎖，如果其他事務插入了empid大於100的任何記錄，那麼本事務如果再次執行上述語句，就會發生幻讀；
（2）爲了滿足其恢復和複製的需要。
很顯然，在使用範圍條件檢索並鎖定記錄時，即使某些不存在的鍵值也會被無辜的鎖定，而造成在鎖定的時候無法插入鎖定鍵值範圍內的任何數據。在某些場景下這可能會對性能造成很大的危害。
除了間隙鎖給InnoDB帶來性能的負面影響之外，通過索引實現鎖定的方式還存在其他幾個較大的性能隱患：
（1）當Query無法利用索引的時候，InnoDB會放棄使用行級別鎖定而改用表級別的鎖定，造成併發性能的降低；
（2）當Query使用的索引並不包含所有過濾條件的時候，數據檢索使用到的索引鍵所只想的數據可能有部分並不屬於該Query的結果集的行列，但是也會被鎖定，因爲間隙鎖鎖定的是一個範圍，而不是具體的索引鍵；
（3）當Query在使用索引定位數據的時候，如果使用的索引鍵一樣但訪問的數據行不同的時候（索引只是過濾條件的一部分），一樣會被鎖定。
因此，在實際應用開發中，尤其是併發插入比較多的應用，我們要儘量優化業務邏輯，儘量使用相等條件來訪問更新數據，避免使用範圍條件。
還要特別說明的是，InnoDB除了通過範圍條件加鎖時使用間隙鎖外，如果使用相等條件請求給一個不存在的記錄加鎖，InnoDB也會使用間隙鎖。
4.死鎖
上文講過，MyISAM表鎖是deadlock free的，這是因爲MyISAM總是一次獲得所需的全部鎖，要麼全部滿足，要麼等待，因此不會出現死鎖。但在InnoDB中，除單個SQL組成的事務外，鎖是逐步獲得的，當兩個事務都需要獲得對方持有的排他鎖才能繼續完成事務，這種循環鎖等待就是典型的死鎖。
在InnoDB的事務管理和鎖定機制中，有專門檢測死鎖的機制，會在系統中產生死鎖之後的很短時間內就檢測到該死鎖的存在。當InnoDB檢測到系統中產生了死鎖之後，InnoDB會通過相應的判斷來選這產生死鎖的兩個事務中較小的事務來回滾，而讓另外一個較大的事務成功完成。
那InnoDB是以什麼來爲標準判定事務的大小的呢？MySQL官方手冊中也提到了這個問題，實際上在InnoDB發現死鎖之後，會計算出兩個事務各自插入、更新或者刪除的數據量來判定兩個事務的大小。也就是說哪個事務所改變的記錄條數越多，在死鎖中就越不會被回滾掉。
但是有一點需要注意的就是，當產生死鎖的場景中涉及到不止InnoDB存儲引擎的時候，InnoDB是沒辦法檢測到該死鎖的，這時候就只能通過鎖定超時限制參數InnoDB_lock_wait_timeout來解決。
需要說明的是，這個參數並不是只用來解決死鎖問題，在併發訪問比較高的情況下，如果大量事務因無法立即獲得所需的鎖而掛起，會佔用大量計算機資源，造成嚴重性能問題，甚至拖跨數據庫。我們通過設置合適的鎖等待超時閾值，可以避免這種情況發生。
通常來說，死鎖都是應用設計的問題，通過調整業務流程、數據庫對象設計、事務大小，以及訪問數據庫的SQL語句，絕大部分死鎖都可以避免。下面就通過實例來介紹幾種避免死鎖的常用方法：
（1）在應用中，如果不同的程序會併發存取多個表，應儘量約定以相同的順序來訪問表，這樣可以大大降低產生死鎖的機會。
（2）在程序以批量方式處理數據的時候，如果事先對數據排序，保證每個線程按固定的順序來處理記錄，也可以大大降低出現死鎖的可能。
（3）在事務中，如果要更新記錄，應該直接申請足夠級別的鎖，即排他鎖，而不應先申請共享鎖，更新時再申請排他鎖，因爲當用戶申請排他鎖時，其他事務可能又已經獲得了相同記錄的共享鎖，從而造成鎖衝突，甚至死鎖。
（4）在REPEATABLE-READ隔離級別下，如果兩個線程同時對相同條件記錄用SELECT…FOR UPDATE加排他鎖，在沒有符合該條件記錄情況下，兩個線程都會加鎖成功。程序發現記錄尚不存在，就試圖插入一條新記錄，如果兩個線程都這麼做，就會出現死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可避免問題。
（5）當隔離級別爲READ COMMITTED時，如果兩個線程都先執行SELECT…FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時，只有一個線程能插入成功，另一個線程會出現鎖等待，當第1個線程提交後，第2個線程會因主鍵重出錯，但雖然這個線程出錯了，卻會獲得一個排他鎖。這時如果有第3個線程又來申請排他鎖，也會出現死鎖。對於這種情況，可以直接做插入操作，然後再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執行ROLLBACK釋放獲得的排他鎖。
5.什麼時候使用表鎖
對於InnoDB表，在絕大部分情況下都應該使用行級鎖，因爲事務和行鎖往往是我們之所以選擇InnoDB表的理由。但在個別特殊事務中，也可以考慮使用表級鎖：
（1）事務需要更新大部分或全部數據，表又比較大，如果使用默認的行鎖，不僅這個事務執行效率低，而且可能造成其他事務長時間鎖等待和鎖衝突，這種情況下可以考慮使用表鎖來提高該事務的執行速度。
（2）事務涉及多個表，比較複雜，很可能引起死鎖，造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的表，從而避免死鎖、減少數據庫因事務回滾帶來的開銷。
當然，應用中這兩種事務不能太多，否則，就應該考慮使用MyISAM表了。
在InnoDB下，使用表鎖要注意以下兩點。
（1）使用LOCK TABLES雖然可以給InnoDB加表級鎖，但必須說明的是，表鎖不是由InnoDB存儲引擎層管理的，而是由其上一層──MySQL Server負責的，僅當autocommit=0、InnoDB_table_locks=1（默認設置）時，InnoDB層才能知道MySQL加的表鎖，MySQL Server也才能感知InnoDB加的行鎖，這種情況下，InnoDB才能自動識別涉及表級鎖的死鎖，否則，InnoDB將無法自動檢測並處理這種死鎖。
（2）在用 LOCK TABLES對InnoDB表加鎖時要注意，要將AUTOCOMMIT設爲0，否則MySQL不會給表加鎖；事務結束前，不要用UNLOCK TABLES釋放表鎖，因爲UNLOCK TABLES會隱含地提交事務；COMMIT或ROLLBACK並不能釋放用LOCK TABLES加的表級鎖，必須用UNLOCK TABLES釋放表鎖。正確的方式見如下語句：
例如，如果需要寫表t1並從表t讀，可以按如下做：
SET AUTOCOMMIT=0;
LOCK TABLES t1 WRITE, t2 READ, ...;
[do something with tables t1 and t2 here];
COMMIT;
UNLOCK TABLES;
6.InnoDB行鎖優化建議
InnoDB存儲引擎由於實現了行級鎖定，雖然在鎖定機制的實現方面所帶來的性能損耗可能比表級鎖定會要更高一些，但是在整體併發處理能力方面要遠遠優於MyISAM的表級鎖定的。當系統併發量較高的時候，InnoDB的整體性能和MyISAM相比就會有比較明顯的優勢了。但是，InnoDB的行級鎖定同樣也有其脆弱的一面，當我們使用不當的時候，可能會讓InnoDB的整體性能表現不僅不能比MyISAM高，甚至可能會更差。
（1）要想合理利用InnoDB的行級鎖定，做到揚長避短，我們必須做好以下工作：
a)儘可能讓所有的數據檢索都通過索引來完成，從而避免InnoDB因爲無法通過索引鍵加鎖而升級爲表級鎖定；
b)合理設計索引，讓InnoDB在索引鍵上面加鎖的時候儘可能準確，儘可能的縮小鎖定範圍，避免造成不必要的鎖定而影響其他Query的執行；
c)儘可能減少基於範圍的數據檢索過濾條件，避免因爲間隙鎖帶來的負面影響而鎖定了不該鎖定的記錄；
d)儘量控制事務的大小，減少鎖定的資源量和鎖定時間長度；
e)在業務環境允許的情況下，儘量使用較低級別的事務隔離，以減少MySQL因爲實現事務隔離級別所帶來的附加成本。
（2）由於InnoDB的行級鎖定和事務性，所以肯定會產生死鎖，下面是一些比較常用的減少死鎖產生概率的小建議：
a)類似業務模塊中，儘可能按照相同的訪問順序來訪問，防止產生死鎖；
b)在同一個事務中，儘可能做到一次鎖定所需要的所有資源，減少死鎖產生概率；
c)對於非常容易產生死鎖的業務部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產生的概率。
（3）可以通過檢查InnoDB_row_lock狀態變量來分析系統上的行鎖的爭奪情況：
mysql> show status like 'InnoDB_row_lock%';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| InnoDB_row_lock_current_waits | 0 |
| InnoDB_row_lock_time | 0 |
| InnoDB_row_lock_time_avg | 0 |
| InnoDB_row_lock_time_max | 0 |
| InnoDB_row_lock_waits | 0 |
+-------------------------------+-------+
InnoDB 的行級鎖定狀態變量不僅記錄了鎖定等待次數，還記錄了鎖定總時長，每次平均時長，以及最大時長，此外還有一個非累積狀態量顯示了當前正在等待鎖定的等待數量。對各個狀態量的說明如下：
InnoDB_row_lock_current_waits：當前正在等待鎖定的數量；
InnoDB_row_lock_time：從系統啓動到現在鎖定總時間長度；
InnoDB_row_lock_time_avg：每次等待所花平均時間；
InnoDB_row_lock_time_max：從系統啓動到現在等待最常的一次所花的時間；
InnoDB_row_lock_waits：系統啓動後到現在總共等待的次數；
對於這5個狀態變量，比較重要的主要是InnoDB_row_lock_time_avg（等待平均時長），InnoDB_row_lock_waits（等待總次數）以及InnoDB_row_lock_time（等待總時長）這三項。尤其是當等待次數很高，而且每次等待時長也不小的時候，我們就需要分析系統中爲什麼會有如此多的等待，然後根據分析結果着手指定優化計劃。
如果發現鎖爭用比較嚴重，如InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比較高，還可以通過設置InnoDB Monitors 來進一步觀察發生鎖衝突的表、數據行等，並分析鎖爭用的原因。
鎖衝突的表、數據行等，並分析鎖爭用的原因。具體方法如下：
mysql> create table InnoDB_monitor(a INT) engine=InnoDB;
然後就可以用下面的語句來進行查看：
mysql> show engine InnoDB status;
監視器可以通過發出下列語句來停止查看：
mysql> drop table InnoDB_monitor;
設置監視器後，會有詳細的當前鎖等待的信息，包括表名、鎖類型、鎖定記錄的情況等，便於進行進一步的分析和問題的確定。可能會有讀者朋友問爲什麼要先創建一個叫InnoDB_monitor的表呢？因爲創建該表實際上就是告訴InnoDB我們開始要監控他的細節狀態了，然後InnoDB就會將比較詳細的事務以及鎖定信息記錄進入MySQL的errorlog中，以便我們後面做進一步分析使用。打開監視器以後，默認情況下每15秒會向日志中記錄監控的內容，如果長時間打開會導致.err文件變得非常的巨大，所以用戶在確認問題原因之後，要記得刪除監控表以關閉監視器，或者通過使用“–console”選項來啓動服務器以關閉寫日誌文件。
引用：
mysql數據庫的鎖有多少種，怎麼編寫加鎖的sql語句
https://www.cnblogs.com/sessionbest/articles/8689071.htm
數據庫四大特性和事務隔離級別
https://www.cnblogs.com/Andya/p/7426436.html