原文鏈接：http://blog.csdn.net/qq_22329521/article/details/54801950
SQL優(yōu)化
--

通過show status命令了解各種sql的執(zhí)行效率

查看本session的sql執(zhí)行效率
show status like 'Com_%';
查看全局的統(tǒng)計結(jié)果
SHOW GLOBAL STATUS LIKE  'Com_%'
查看服務(wù)器的狀態(tài)
show global status;    

結(jié)果

• Com_select:執(zhí)行select操作的次數(shù)，依次查詢之累加1
• Com_insert:執(zhí)行insert操作的次數(shù)，對于批量插入的insert操作，只累加依次
• Com_update:執(zhí)行update操作的此時
• Com_delete:執(zhí)行delete的次數(shù)

上面的參數(shù)是對所有存儲引擎的表進(jìn)行累計，下面參數(shù)是針對InnoDB存儲引擎的，累加的算法也是略有不同的

• Innodb_rows_read:SELECT查詢返回的行數(shù)
• Innodb_rows_insered:執(zhí)行inser操作插入的行數(shù)
• Innodb_rows_updated:執(zhí)行UPDATE操作更新的行數(shù)
• Innodb_rows_deleted執(zhí)行DELETE操作刪除的行數(shù)

通過上述的參數(shù)可以了解當(dāng)前數(shù)據(jù)庫的應(yīng)用是插入更新為主還是查詢操作為主，以及各類的SQL的執(zhí)行比例是多少。對于更新操作的計算，是對執(zhí)行次數(shù)的計數(shù)，無論提交還是回滾都會進(jìn)行累加對于事務(wù)形的應(yīng)用，通過Com_commit和Com_rollback可以了解事務(wù)提交和回滾的情況，對于回滾操作非常頻繁的數(shù)據(jù)庫，可能意味著應(yīng)用編寫存在的問題

• Connections:試圖連接MySql服務(wù)器的次數(shù)
• Uptime：服務(wù)器工作時間
• Slow_queries:慢查詢的次數(shù)

定位執(zhí)行效率低的SQL語句

1. 通過慢查詢?nèi)罩径ㄎ荒切﹫?zhí)行效率較低的sql語句，用--log-show-queries[=file_name]選項去啟動，mysqlId寫一個包含所有執(zhí)行時間超過long_querty_time秒的sql語句的日志文件
2. 慢查詢?nèi)罩驹诓樵兘Y(jié)束后才記錄，所以在應(yīng)用反應(yīng)執(zhí)行效率出現(xiàn)問題的時候查詢慢查詢?nèi)罩静⒉荒芏ㄎ粏栴}，可以使用show processlist命令查看當(dāng)前Mysql在進(jìn)行的線程，包括線程的狀態(tài)，是否鎖表等，可以實(shí)時查看sql的執(zhí)行情況，同時對一些鎖表進(jìn)行優(yōu)化

通過explain分析執(zhí)行sql的執(zhí)行計劃

explain或者desc獲取mysql如何執(zhí)行select語句的信息

explain select * from user;

結(jié)果 包含，id，select_type,table.type....

每個列說明

• select_type：表示SELECT的類型，常見的取值有simple（簡單表，即不用表連接或者子查詢），primary（主查詢，即外部查詢），union（union中的第二個或者后面的查詢語句），subquery（子查詢中的第一個select）等
• table:輸出結(jié)果集
• type：表示Mysql在表中找到所需行的方式，或者叫訪問類型，常見類型如：all,index,range,ref,eq_ref,const,system,null,從做到右，性能由差到好

type=all，全表掃描，mysql遍歷全表來找到匹配的行
explain select * from film where rating>9
type=index,索引全掃描，MySQL遍歷整個索引來查詢匹配的行
explain select title from film
type=range,索引范圍掃描，常見<,<=,>,>=,between
 explain select * from payment where customer_id>=300 and customer_id<=350
type=ref，使用費(fèi)索引掃描或唯一索引的前綴掃描
explain select * from payment where customer_id=350
type=eq_ref,類似ref，區(qū)別在于使用的索引是唯一索引，對于每個索引鍵值，表中有一條記錄匹配；簡單來說就是多表連接使用primary key或者unique index作為關(guān)聯(lián)條件
explain select * from film a,film_text b where a.film_id=b.film_id
type=const/system,單表中最多有一個匹配行，查詢起來非常迅速，索引這個匹配行中的其他列的值可以被優(yōu)化器在當(dāng)前查詢中當(dāng)做常量來處理,例如根據(jù)主鍵primary key或者唯一一個索引來查詢

type null,mysql不用訪問數(shù)據(jù)庫直接得到結(jié)果
explain select 1 from dual where 1

mysql 4.1引入了explain extended命令，通過explain extended 加上show warnings可以查看mysql 真正被執(zhí)行之前優(yōu)化器所做的操作

explain select * from users;
show warnings;
可以從warning的字段中能夠看到，會去除一些恒成立的條件，可以利用explain extended的結(jié)果來迅速的獲取一個更清晰易讀的sql語句

通過show profile 分析sql

查看mysql是否支持profile
select @@have_profiling;

默認(rèn)profiling是關(guān)閉的，可以通過set語句在session級別啟動profiling;
select @@profiling;

set profiling=1;

通過profile，我們能夠更清楚的了解sql執(zhí)行的過程。例如我們知道，MyISAM表有表元數(shù)據(jù)的緩存（例如行，即COUNT()值),對于MyISAM表的COUNT()是不需要消耗太多資源，而對于Innodb來說，就沒有這種元數(shù)據(jù)，CONUT（*）執(zhí)行的比較慢

select count(*) from users;
執(zhí)行完畢查看 
show profiles

可以查看之前的queryid
show profile for query 2； 可以查看執(zhí)行過程中線程的每個狀態(tài)和消耗時間
其中 sendingdata 狀態(tài)表示mysql線程開始訪問數(shù)據(jù)行并把結(jié)果返回給客戶端，而不僅僅是返回給客戶端，由于在sending data狀態(tài)下，mysql線程往往需要做大量的磁盤讀取操作；所以經(jīng)常是整個查詢中最耗時的狀態(tài)

mysql 支持進(jìn)一步選擇all,cpu,block io,context,switch,page faults等明細(xì)來查看mysql在使用什么資源上耗費(fèi)了過高的時間，例如，選擇查看cpu的耗費(fèi)時間

show profile cpu for query 6;

對比MyISAM的操作，同樣執(zhí)行count(*)操作，檢查profile，Innodb表經(jīng)歷了Sending data狀態(tài)，而MyISAM的表完全不需要訪問數(shù)據(jù)
如果對Mysql 源碼感興趣，可以通過show profile source for query查看sql解析執(zhí)行過程的每個步驟對應(yīng)的源碼文件

show profile source for query 6

通過trace分析優(yōu)化器如何
MySql 5.6提供對sql的跟蹤trace，通過trace文件能夠進(jìn)一步了解為什么優(yōu)化器選擇A執(zhí)行計劃而不選擇B執(zhí)行計劃，幫助我們更好地了解優(yōu)化器的行為

使用方式
首先打開trace，設(shè)置格式為json，設(shè)置trace最大能夠使用的內(nèi)存，避免解析過程中因?yàn)槟J(rèn)內(nèi)存小而不能完整顯示
set optimizer_trace="enabled=on",end_markers_in_json=on;
set optimizer_trace_max_mem_size=1000000;

接下來執(zhí)行trace的sql語句，
select * from ....where....
最后檢查information_schema.optimizer_trace就可以知道Mysql如何執(zhí)行sql
select * from information_schema.optimizer_trace

索引問題

mysql提供四種索引

• B-Tree索引:最常見的的索引，大部分引擎支持B樹索引
• HASH索引:只有Memory引擎支持，使用場景簡單
• R-Tree索引:空間索引是MyISAM的一個特殊索引類型，主要用于地理空間數(shù)據(jù)類型，通常使用較少
• Full-text：全文索引也是MyISAM的一個特殊索引，主要用于全文索引，InnoDb從MySql5.6開始提供支持全文索引

MySql目前不支持函數(shù)索引，但是能對列的前面某一部分進(jìn)行索引，例如標(biāo)題title字段，可以只取title的前10個字符索引，這樣的特性大大縮小了索引文件的大小，但前綴索引也有缺點(diǎn)，在排序order by和分組group by操作的時候無法使用

create index idx_title on film(title(10));

常用的索引就是B-tree索引和hash索引，資只有memory引擎支持HASH索引，hash索引適用于key-value查詢，通過hash索引比B-tree索引查詢更加迅速，但是hash索引不支持范圍查找例如<><==,>==等操作，如果使用memory引擎并且where不使用=進(jìn)行 索引列，就不會用的索引。Memory只有在"="的條件下才會使用索引

簡單的優(yōu)化方法

本語句可以用于分析和存儲表的關(guān)鍵字分布，分析的結(jié)果可以使得系統(tǒng)得到準(zhǔn)確的統(tǒng)計信息使得sql，能夠生成正確的執(zhí)行計劃。如果用戶感覺實(shí)際執(zhí)行計劃并不預(yù)期的執(zhí)行計劃，執(zhí)行一次分析表可能會解決問題

analyze table payments;

檢查表：檢查表：檢查表的作用是檢查一個表或多個表是否有錯誤,也可以檢查視圖是否錯誤

check table payment;

優(yōu)化表:如果刪除了表的一大部分，或者如果已經(jīng)對可變長度的行表（含varchar、blob、text列）的表進(jìn)行改動，則使用optimize 進(jìn)行表優(yōu)化，這個命令可以使表中的空間碎片進(jìn)行合并、并且可以消除由于刪除或者更新造成的空間浪費(fèi)

optimize table payment;

對于innodb引擎的表，可以通過設(shè)置innodb_file_per_taable參數(shù)，設(shè)置InnoDb為獨(dú)立表空間模式，這樣每個數(shù)據(jù)庫的每個表都會生成一個獨(dú)立的idb文件，用于存儲表的數(shù)據(jù)和索引，可以一定程度減少Innodb表的空間回收問題,另外，在刪除大量數(shù)據(jù)后，Innodb表可以通過alter table但是不銹鋼引擎方式來回收不用的空間

alter table payment enigine=innodb;

ANALYZE,CHECK,OPTIMIZE,ALTER TABLE執(zhí)行期間都是對表進(jìn)行鎖定，因此要在數(shù)據(jù)庫不頻繁的時候執(zhí)行相關(guān)的操作

常用SQL的優(yōu)化

大批量的插入數(shù)據(jù)

當(dāng)用load導(dǎo)入數(shù)據(jù)，適當(dāng)?shù)脑O(shè)置可以提供導(dǎo)入的速度
對于MyISAM存儲引擎的表，可以通過以下方式快速導(dǎo)入大量的數(shù)據(jù)

alter table tab_name disable keys;
loading the data
alter table tab_name disable keys;

disable keys和enable keys 用來打開或者關(guān)閉MyISAM表非索引的更新。在導(dǎo)入大量的數(shù)據(jù)到一個非空的MyISAM表，通過設(shè)置這兩個命令，可以提高導(dǎo)入的效率
對于Innodb類型的表不能使用上面的方式提高導(dǎo)入效率
因?yàn)镮nnodb類型的表是按照主鍵的順序保存，所有將導(dǎo)入的數(shù)據(jù)按照主鍵的順序排序，可以有效地提高導(dǎo)入數(shù)據(jù)的效率

在導(dǎo)入數(shù)據(jù)強(qiáng)執(zhí)行SET UNIQUE_CHECKS=0，關(guān)閉唯一性校驗(yàn)，在導(dǎo)入結(jié)束后執(zhí)行SET UNIQUE_CHECKS=1.恢復(fù)唯一性校驗(yàn)，可以提高導(dǎo)入的效率，如果應(yīng)用使用自動提交的方式，建議在導(dǎo)入前執(zhí)行SET AUTOCOMMIT=0時，關(guān)閉自動提交，導(dǎo)入結(jié)束后再執(zhí)行SET AUTOCOMMIT=1，打開自動提交，也可以提高導(dǎo)入的效率

優(yōu)化insert語句

• 如果同時從一個客戶端插入很多行，應(yīng)盡量使用多個值表的insert語句，這種方式將大大縮減客戶端與數(shù)據(jù)庫之間的連接、關(guān)閉等消耗，使得效率比分開執(zhí)行的單個insert語句快（大部分情況下，使用多個值表的insert語句那比單個insert語句快上好幾倍）。

insert into test values(1,2),(1,3)...

• 如果從不同客戶插入很多行，可以通過使用insert delayed語句提高更高的速度，delayed的含義是讓insert語句馬上執(zhí)行，其實(shí)數(shù)據(jù)都被放到內(nèi)存的隊列中，并沒有真正寫入磁盤，這比每條語句分別插入要快的多；LOW_PRIORITY剛好相反，在所有其他用戶對表的讀寫完成后才可以進(jìn)行
• 將索引文件和數(shù)據(jù)文件分在不同的磁盤上存放（利用建表中的選項）
• 如果進(jìn)行批量插入，可以通過增加bulk_insert_buffer_size變量值的方法來通過速度，但是，這只能對MyISAM表使用。
• 當(dāng)從一個文本文件裝載一個表時，使用LOAD DATA INFILE。這通常比使用很多INSERT語句塊快20倍

優(yōu)化ORDER BY語句

MySQL有兩種排序方式

• 第一種通過有序排序索引順序掃描，這種方式在使用explain分析查詢的時候顯示為Using Index，不需要額外的排序，操作效率較高

explain select customer_id from customer order by store_id;

• 第二張通過返回數(shù)據(jù)進(jìn)行排序，也就是通常說的Filesort排序，所有不是通過索引直接返回排序結(jié)果的排序豆角Filesort排序。Filesort并不代表通過磁盤文件進(jìn)行排序，而只是說明進(jìn)行了一個排序操作，至于排序操作是否進(jìn)行了磁盤文件或臨時表等，則取決于MySql服務(wù)器對排序參數(shù)的設(shè)置和需要排序數(shù)據(jù)的大小

explain select * from customer order by store_id;

Filesort是通過相應(yīng)的排序算法，將取得的數(shù)據(jù)在sort_buffer_size系統(tǒng)變量設(shè)置的內(nèi)存排序區(qū)進(jìn)行排序，如果內(nèi)存裝載不下，它會將磁盤上的數(shù)據(jù)進(jìn)行分塊，再對各個數(shù)據(jù)塊進(jìn)行排序，然后將各個塊合并成有序的結(jié)果集。sort_buffer_size設(shè)置的排序區(qū)是每個線程獨(dú)占的，所有同一個時刻，MySql存在多個sort buffer排序區(qū)

優(yōu)化目標(biāo):盡量減少額外的排序，通過索引直接返回有序數(shù)據(jù).where和ordery by 使用相同的索引，并且order by的順序和索引順序相同，并且order by的字段都是升序或者都是降序。否則肯定需要額外的排序操作，這樣就會出現(xiàn)filesort

優(yōu)化group by 語句

如果查詢包括group by 但用戶想要避免排序結(jié)果的消耗，可以指定group by null

優(yōu)化嵌套查詢

子查詢可以被更有效率的連接替代

explain select * from customer where customer_id not in(select customer_id from payment)

explain select * from customer a left join payment b on a.customer_id=b.customer_id where b.customer id is null

連接之所用更有效率是因?yàn)閙ysql不需要在內(nèi)存中創(chuàng)建臨時表來完成這個邏輯上需要兩個步驟的查詢工作

優(yōu)化分頁查詢

一般分頁查詢，通過創(chuàng)建覆蓋索引能夠比較好地提高性能。一個場景是"limit 1000,20",此時Mysql排序出前1020條數(shù)據(jù)后僅僅需要返回第1001到1020條記錄，前1000條數(shù)據(jù)都被拋棄，查詢和排序代價非常高

優(yōu)化方式：可以增加一個字段last_page_record.記錄上一頁和最后一頁的編號，通過

explain select ...where last_page_record<... desc limt ..

如果排序字段出現(xiàn)大量重復(fù)字段，不適用這種方式進(jìn)行優(yōu)化

MySql常用技巧

正則表達(dá)式的使用

使用

select 'abcdefg' regexp '^a';
.....

如果range()提取隨機(jī)行

隨機(jī)抽取某些行

select * from categrory order by rand() limit 5;

利用group by的with rollup 子句

使用Group By的with rollup可以檢索更多分組聚合信息

select date_from(payment_date,'%Y-%M'),staff_id,sum(amount) from payment group by date_formate(payment_date,'%Y-%M'),staff_id;

用BIT GROUP FUNCTIONS做統(tǒng)計

使用GROUP BY語句和BIT_AND、BIT_OR函數(shù)完成統(tǒng)計工作，這兩個函數(shù)的一般用途就是做數(shù)值之間的邏輯

優(yōu)化數(shù)據(jù)庫對象

優(yōu)化表類型

表需要使用何種數(shù)據(jù)類型工具應(yīng)用來判斷，雖然考慮字段的長度會有一定的冗余，但是不推薦讓很多字段都留有大量的冗余，這樣既浪費(fèi)磁盤的存儲空間，同時在應(yīng)用操作時也浪費(fèi)物理內(nèi)存mysql，可以使用函數(shù)procedure analyse對當(dāng)前的表進(jìn)行分析

//輸出的每一類信息都對數(shù)據(jù)表中的列的數(shù)據(jù)類型提出優(yōu)化建議。第二語句高數(shù)procedure anaylse不要為那些包含的值多余16個或者256個字節(jié)的enum類型提出建議，如果沒有這個限制，輸出的信息可能很長；ENUM定義通常很難閱讀，通過輸出信息，可以將表中的部分字段修改為效率更高的字段
select * from tb1_name procedure analyse();
select * from tb2_name procedure analyse(16,256);

通過拆分提高表的訪問效率

• 重置拆分，把主碼和一些列放到一個表，然后把住碼和另外的列放到另一個表， 好處可以將常用的列放在一起，不常用的列放在一起，使得數(shù)據(jù)行變少，一個數(shù)據(jù)頁可以存放更多的數(shù)據(jù)，在查詢時會減少I/O次數(shù)，缺點(diǎn)：管理冗余，查詢所有數(shù)據(jù)需要用join操作
• 水平拆分。根據(jù)一列或多列數(shù)據(jù)把數(shù)據(jù)行放到兩個獨(dú)立的表中：水平拆分會給應(yīng)用增加復(fù)雜度，它通常在查詢時需要多個表名，查詢所有數(shù)據(jù)需要UNION操作，缺點(diǎn)：只要索引關(guān)鍵字不大，則在索引查詢時，表中增加了2-3倍的數(shù)據(jù)量，查詢時也增加了讀一個索引的磁盤次數(shù)，所有說拆分要考慮數(shù)據(jù)量的增長速度。常用場景
  • 表很大，分割后可以降低在查詢時需要讀的數(shù)據(jù)和索引的頁數(shù)，同時也降低了索引的層數(shù)，提高查詢速度
  • 表中的數(shù)據(jù)本來就有獨(dú)立性，例如表中分別記錄各個地區(qū)的數(shù)據(jù)或者不同時期的數(shù)據(jù)，特別是有些數(shù)據(jù)常用，而有些數(shù)據(jù)不常用
  • 需要把數(shù)據(jù)存放在多個介質(zhì)上：如賬單：最近三個月數(shù)據(jù)存在一個表中，3個月之前的數(shù)據(jù)存放在另一個表，成功一年的可以存儲在單獨(dú)的存儲介質(zhì)中。

逆規(guī)范化

數(shù)據(jù)庫設(shè)計時需要瞞住規(guī)范化，但是規(guī)范化程度越高，產(chǎn)生的關(guān)系就越多，關(guān)系越多直接結(jié)果就是表直接的連接操作越頻繁，而表連接的操作是性能較低的操作，直接影響到查詢的數(shù)據(jù)。
反規(guī)范化的好處在于降低連接操作的需求，降低外碼和索引的數(shù)目，還可以減少表的樹木，相應(yīng)帶來的問題可能出現(xiàn)數(shù)據(jù)的完整性問題。加快查詢速度，但是降低修改速度。好的索引和其他方法經(jīng)常能夠解決性能問題，而不必采用反規(guī)范這種方法
采用的反規(guī)范化技術(shù)

• 增加冗余列：指在多個表中具有相同的列，它常用來在查詢時避免連接操作
• 增加派生列：指增加的列來自其他表中的數(shù)據(jù)，由其他表中的數(shù)據(jù)經(jīng)過計算生成。增加的派生列其他作業(yè)是在查詢時減少連接操作，避免使用集函數(shù)
• 重新組表：指如果許多用戶需要查看兩個表連接出來的結(jié)果數(shù)據(jù)，則把這兩個表查詢組成一個表來減少連接而提高性能
• 分割表

維護(hù)數(shù)據(jù)的完整性

• 批處理維護(hù)是指對復(fù)制列或派生列的修改積累一定的時間后，運(yùn)行一批處理作業(yè)或修改存儲過程對復(fù)制或派生列進(jìn)行修改，這只能對實(shí)時性要求不高的情況下使用
• 數(shù)據(jù)的完整性也可由應(yīng)用邏輯來實(shí)現(xiàn)，這就要求必須在同一事務(wù)中對所有涉及的表進(jìn)行增、刪、改操作。用應(yīng)用邏輯來實(shí)現(xiàn)數(shù)據(jù)的完整性風(fēng)險較大，因?yàn)橥贿壿嫳仨氃谒械膽?yīng)用中使用和維護(hù)，容易遺漏。特別是在需求變化時，不易于維護(hù)
• 使用觸發(fā)器，對數(shù)據(jù)的任何修改立即觸發(fā)對復(fù)制列或者派生列的相應(yīng)修改，觸發(fā)器是實(shí)時的，而且相應(yīng)的處理邏輯只在一個地方出現(xiàn)，易于維護(hù)，一般來說，是解決這類問題比較好的方法

使用中間表提高統(tǒng)計查詢速度

對于數(shù)據(jù)量較大的表，在其上進(jìn)行統(tǒng)計查詢通常會效率很低，并且還要考慮統(tǒng)計查詢是
否會對在線的應(yīng)用產(chǎn)生負(fù)面影響。通常在這種情況下，使用中間表可以提高統(tǒng)計查詢的效率
session 表記錄了客戶每天的消費(fèi)記錄，表結(jié)構(gòu)如下：

CREATE TABLE session (
cust_id varchar(10) , --客戶編號
cust_amount DECIMAL(16,2), --客戶消費(fèi)金額
cust_date DATE, --客戶消費(fèi)時間
cust_ip varchar(20) –客戶IP 地址
)

由于每天都會產(chǎn)生大量的客戶消費(fèi)記錄,所以session 表的數(shù)據(jù)量很大,現(xiàn)在業(yè)務(wù)部門有
一具體的需求：希望了解最近一周客戶的消費(fèi)總金額和近一周每天不同時段用戶的消費(fèi)總金
額。針對這一需求我們通過2 種方法來得出業(yè)務(wù)部門想要的結(jié)果。
方法1：在session 表上直接進(jìn)行統(tǒng)計,得出想要的結(jié)果。

select sum(cust_amount) from session where cust_date>adddate(now(),-7);

方法2：創(chuàng)建中間表tmp_session，表結(jié)構(gòu)和源表結(jié)構(gòu)完全相同。

CREATE TABLE tmp_session (
cust_id varchar(10) , --客戶編號
cust_amount DECIMAL(16,2), --客戶消費(fèi)金額
cust_date DATE, --客戶消費(fèi)時間
cust_ip varchar(20) –客戶IP 地址
) ;

insert into tmp_session select * from session where cust_date>adddate(now(),-7);

轉(zhuǎn)移要統(tǒng)計的數(shù)據(jù)到中間表,然后在中間表上進(jìn)行統(tǒng)計，得出想要的結(jié)果。
在中間表上給出統(tǒng)計結(jié)果更為合適,原因是源數(shù)據(jù)表(session 表)
cust_date 字段沒有索引并且源表的數(shù)據(jù)量較大，所以在按時間進(jìn)行分時段統(tǒng)計時效率
很低，這時可以在中間表上對cust_date 字段創(chuàng)建單獨(dú)的索引來提高統(tǒng)計查詢的速度。
中間表在統(tǒng)計查詢中經(jīng)常會用到，其優(yōu)點(diǎn)如下:

1. 中間表復(fù)制源表部分?jǐn)?shù)據(jù)，并且與源表相“隔離”，在中間表上做統(tǒng)計查詢不
   會對在線應(yīng)用產(chǎn)生負(fù)面影響.
2. 中間表上可以靈活的添加索引或增加臨時用的新字段,從而達(dá)到提高統(tǒng)計查詢
   效率和輔助統(tǒng)計查詢作用。

鎖問題

MySql三種鎖的特性

• 表級鎖：開銷小，加鎖快;不會出現(xiàn)死鎖；鎖定粒度大，發(fā)生鎖沖突的概率最高，并發(fā)度最低
• 行級鎖：開銷大，加鎖慢;會出現(xiàn)死鎖;鎖定粒度小，發(fā)生鎖沖突的概率最低，并發(fā)度最高
• 頁面鎖：開銷和加鎖時間介于表鎖和行鎖之間；會出現(xiàn)死鎖；鎖定粒度介于表鎖和行鎖之間，并發(fā)度一般

不同的數(shù)據(jù)引擎支持不同的鎖機(jī)制：MyISAM和MEMORY存儲引擎采用的表級鎖;BDB存儲引擎采用的是頁面鎖。但也支持表級鎖；Innodb存儲引擎既支持行級鎖，也支持表級鎖，默認(rèn)采用行級鎖

//查詢表級鎖爭用情況，檢查table_locks_waited和table_locks_immediate狀態(tài)變量來分析
show status like 'table%'
//table_locks_waited 的值越高，則說明存在嚴(yán)重的表級鎖的爭用情況

表級鎖的鎖模式

|是否兼容|請求none|請求讀鎖|請求寫鎖|
| ------------- |:-------------:|
|當(dāng)前處于讀鎖| 是|是|否|
|當(dāng)前處于寫鎖|是|否|否|

對MyISAM表的讀操作，不會阻塞其他用戶對同一張表的讀請求，但會阻塞對同一張表的寫請求

MyISAM在執(zhí)行查詢語句前，會自動給涉及的所有表進(jìn)行表加讀鎖，在執(zhí)行更新（update,delete,insert)會自動給涉及到的表加寫鎖，這個過程不需要用戶干預(yù)，因此不需要用戶直接用lock table命令

對于給MyISAM顯示加鎖，一般是為了在一定程度上模擬事務(wù)操作，實(shí)現(xiàn)對某一個時間點(diǎn)多個表一致性讀取

例子

一個訂單表為orders，其中記錄各個訂單的總金額total，同時還有一個訂單明顯表為order_detail,其中記錄有各訂單每一產(chǎn)品的金額小計subtotal，假設(shè)我們需要檢查這兩個表的金額合計是否相符

select sum(total) from orders;
select sum(subtotal) from order_tail;
//如果不給表加鎖，可能出現(xiàn)錯誤，在第一條執(zhí)行的過程，第二張表發(fā)生了該表，正確的方法
lock tables orders read local,order_detail read local;
select sum(total) from orders;
select sum(subtotal) from order_tail;
unlock  tables

注意點(diǎn)

在用LOCKTABLES給表顯式加表鎖是時，必須同時取得所有涉及表的鎖，并且MySQL支持鎖升級。也就是說，在執(zhí)行LOCK TABLES后，只能訪問顯式加鎖的這些表，不能訪問未加鎖的表；同時，如果加的是讀鎖，那么只能執(zhí)行查詢操作，而不能執(zhí)行更新操作。其實(shí)，在自動加鎖的情況下也基本如此，MySQL問題一次獲得SQL語句所需要的全部鎖。這也正是MyISAM表不會出現(xiàn)死鎖（Deadlock Free）的原因

tips

當(dāng)使用LOCK TABLE時，不僅需要一次鎖定用到的所有表，而且，同一個表在SQL語句中出現(xiàn)多少次，就要通過與SQL語句中相同的別名鎖多少次，否則也會出錯！

lock table actor read
//會提示錯誤
select a.first_name.....
//需要對別名分別鎖定
lock table actor as read,actor as b read;

并發(fā)鎖

在一定條件下，MyISAM也支持查詢和操作的并發(fā)進(jìn)行。
MyISAM存儲引擎有一個系統(tǒng)變量concurrent_insert，專門用以控制其并發(fā)插入的行為，其值分別可以為0、1或2。

• 當(dāng)concurrent_insert設(shè)置為0時，不允許并發(fā)插入。
• 當(dāng)concurrent_insert設(shè)置為1時，如果MyISAM允許在一個讀表的同時，另一個進(jìn)程從表尾插入記錄。這也是MySQL的默認(rèn)設(shè)置。
• 當(dāng)concurrent_insert設(shè)置為2時，無論MyISAM表中有沒有空洞，都允許在表尾插入記錄，都允許在表尾并發(fā)插入記錄。

可以利用MyISAM存儲引擎的并發(fā)插入特性，來解決應(yīng)用中對同一表查詢和插入鎖爭用。例如，將concurrent_insert系統(tǒng)變量為2，總是允許并發(fā)插入；同時，通過定期在系統(tǒng)空閑時段執(zhí)行OPTIONMIZE TABLE語句來整理空間碎片，收到因刪除記錄而產(chǎn)生的中間空洞。

MyISAM的鎖調(diào)度

MyISAM存儲引擎的讀和寫鎖是互斥，讀操作是串行的。一個進(jìn)程請求某個MyISAM表的讀鎖，同時另一個進(jìn)程也請求同一表的寫鎖，MySQL如何處理呢？答案是寫進(jìn)程先獲得鎖。不僅如此，即使讀進(jìn)程先請求先到鎖等待隊列，寫請求后到，寫鎖也會插到讀請求之前！這是因?yàn)?strong>MySQL認(rèn)為寫請求一般比讀請求重要。這也正是MyISAM表不太適合于有大量更新操作和查詢操作應(yīng)用的原因，因?yàn)椋罅康母虏僮鲿斐刹樵儾僮骱茈y獲得讀鎖，從而可能永遠(yuǎn)阻塞。這種情況有時可能會變得非常糟糕！幸好我們可以通過一些設(shè)置來調(diào)節(jié)MyISAM的調(diào)度行為。

• 通過指定啟動參數(shù)low-priority-updates，使MyISAM引擎默認(rèn)給予讀請求以優(yōu)先的權(quán)利。
• 通過執(zhí)行命令SET LOW_PRIORITY_UPDATES=1，使該連接發(fā)出的更新請求優(yōu)先級降低。
• 通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優(yōu)先級。

另外，MySQL也提供了一種折中的辦法來調(diào)節(jié)讀寫沖突，即給系統(tǒng)參數(shù)max_write_lock_count設(shè)置一個合適的值，當(dāng)一個表的讀鎖達(dá)到這個值后，MySQL變暫時將寫請求的優(yōu)先級降低，給讀進(jìn)程一定獲得鎖的機(jī)會。

InnoDB鎖問題

InnoDB與MyISAM的最大不同有兩點(diǎn)：一是支持事務(wù)；二是采用了行級鎖。行級鎖和表級鎖本來就有許多不同之處，另外，事務(wù)的引入也帶來了一些新問題。

事務(wù)（Transaction）及其ACID屬性

事務(wù)是由一組SQL語句組成的邏輯處理單元，事務(wù)具有4屬性，通常稱為事務(wù)的ACID屬性。

• 原性性（Actomicity）：事務(wù)是一個原子操作單元，其對數(shù)據(jù)的修改，要么全都執(zhí)行，要么全都不執(zhí)行。
• 一致性（Consistent）：在事務(wù)開始和完成時，數(shù)據(jù)都必須保持一致狀態(tài)。這意味著所有相關(guān)的數(shù)據(jù)規(guī)則都必須應(yīng)用于事務(wù)的修改，以操持完整性；事務(wù)結(jié)束時，所有的內(nèi)部數(shù)據(jù)結(jié)構(gòu)（如B樹索引或雙向鏈表）也都必須是正確的。
• 隔離性（Isolation）：數(shù)據(jù)庫系統(tǒng)提供一定的隔離機(jī)制，保證事務(wù)在不受外部并發(fā)操作影響的“獨(dú)立”環(huán)境執(zhí)行。這意味著事務(wù)處理過程中的中間狀態(tài)對外部是不可見的，反之亦然。
• 持久性（Durable）：事務(wù)完成之后，它對于數(shù)據(jù)的修改是永久性的，即使出現(xiàn)系統(tǒng)故障也能夠保持。

并發(fā)事務(wù)帶來的問題

相對于串行處理來說，并發(fā)事務(wù)處理能大大增加數(shù)據(jù)庫資源的利用率，提高數(shù)據(jù)庫系統(tǒng)的事務(wù)吞吐量，從而可以支持可以支持更多的用戶。但并發(fā)事務(wù)處理也會帶來一些問題，主要包括以下幾種情況。

• 更新丟失（Lost Update）：當(dāng)兩個或多個事務(wù)選擇同一行，然后基于最初選定的值更新該行時，由于每個事務(wù)都不知道其他事務(wù)的存在，就會發(fā)生丟失更新問題——最后的更新覆蓋了其他事務(wù)所做的更新。例如，兩個編輯人員制作了同一文檔的電子副本。每個編輯人員獨(dú)立地更改其副本，然后保存更改后的副本，這樣就覆蓋了原始文檔。最后保存其更改保存其更改副本的編輯人員覆蓋另一個編輯人員所做的修改。如果在一個編輯人員完成并提交事務(wù)之前，另一個編輯人員不能訪問同一文件，則可避免此問題
• 臟讀（Dirty Reads）：一個事務(wù)正在對一條記錄做修改，在這個事務(wù)并提交前，這條記錄的數(shù)據(jù)就處于不一致狀態(tài)；這時，另一個事務(wù)也來讀取同一條記錄，如果不加控制，第二個事務(wù)讀取了這些“臟”的數(shù)據(jù)，并據(jù)此做進(jìn)一步的處理，就會產(chǎn)生未提交的數(shù)據(jù)依賴關(guān)系。這種現(xiàn)象被形象地叫做“臟讀”。
• 不可重復(fù)讀（Non-Repeatable Reads）：一個事務(wù)在讀取某些數(shù)據(jù)已經(jīng)發(fā)生了改變、或某些記錄已經(jīng)被刪除了！這種現(xiàn)象叫做“不可重復(fù)讀”。
• 幻讀（Phantom Reads）：一個事務(wù)按相同的查詢條件重新讀取以前檢索過的數(shù)據(jù)，卻發(fā)現(xiàn)其他事務(wù)插入了滿足其查詢條件的新數(shù)據(jù)，這種現(xiàn)象就稱為“幻讀”。

事務(wù)隔離級別

1. 在并發(fā)事務(wù)處理帶來的問題中，“更新丟失”通常應(yīng)該是完全避免的。但防止更新丟失，并不能單靠數(shù)據(jù)庫事務(wù)控制器來解決，需要應(yīng)用程序?qū)σ碌臄?shù)據(jù)加必要的鎖來解決，因此，防止更新丟失應(yīng)該是應(yīng)用的責(zé)任。
2. “臟讀”、“不可重復(fù)讀”和“幻讀”，其實(shí)都是數(shù)據(jù)庫讀一致性問題，必須由數(shù)據(jù)庫提供一定的事務(wù)隔離機(jī)制來解決。數(shù)據(jù)庫實(shí)現(xiàn)事務(wù)隔離的方式，基本可以分為以下兩種。

• .一種是在讀取數(shù)據(jù)前，對其加鎖，阻止其他事務(wù)對數(shù)據(jù)進(jìn)行修改。
• 另一種是不用加任何鎖，通過一定機(jī)制生成一個數(shù)據(jù)請求時間點(diǎn)的一致性數(shù)據(jù)快照（Snapshot），并用這個快照來提供一定級別（語句級或事務(wù)級）的一致性讀取。從用戶的角度，好像是數(shù)據(jù)庫可以提供同一數(shù)據(jù)的多個版本，因此，這種技術(shù)叫做數(shù)據(jù)多版本并發(fā)控制（ＭultiVersion Concurrency Control，簡稱MVCC或MCC），也經(jīng)常稱為多版本數(shù)據(jù)庫。

數(shù)據(jù)庫的事務(wù)隔離級別越嚴(yán)格，并發(fā)副作用越小，但付出的代價也就越大，因?yàn)槭聞?wù)隔離實(shí)質(zhì)上就是使事務(wù)在一定程度上“串行化”進(jìn)行，這顯然與“并發(fā)”是矛盾的，同時，不同的應(yīng)用對讀一致性和事務(wù)隔離程度的要求也是不同的，比如許多應(yīng)用對“不可重復(fù)讀”和“幻讀”并不敏感，可能更關(guān)心數(shù)據(jù)并發(fā)訪問的能力。
為了解決“隔離”與“并發(fā)”的矛盾，ISO/ANSI SQL92定義了４個事務(wù)隔離級別，每個級別的隔離程度不同，允許出現(xiàn)的副作用也不同，應(yīng)用可以根據(jù)自己業(yè)務(wù)邏輯要求，通過選擇不同的隔離級別來平衡＂隔離＂與＂并發(fā)＂的矛盾

|隔離級別/讀數(shù)據(jù)一致性及允許的并發(fā)副作用|讀數(shù)據(jù)一致性|臟讀|不可重復(fù)讀|幻讀|
| ------------- |:-------------:|
|未提交讀（Read uncommitted）|最低級別，只能保證不讀取物理上損壞的數(shù)據(jù)|是|是|是|
|已提交度（Read committed）|語句級|否|是|是|
|可重復(fù)讀（Repeatable read）|事務(wù)級|否|否是|
|可序列化（Serializable）|最高級別，事務(wù)級|否|否|否|

//查看Innodb行鎖爭用情況
show status like 'innodb_row_lock%'
//如果發(fā)現(xiàn)爭用比較嚴(yán)重，如Innodb_row_lock_waits和Innodb_row_lock_time_avg的值比較高
//通過查詢information_schema相關(guān)表來查看鎖情況
select * from innodb_locks
select * from innodb_locks_waits
//或者通過設(shè)置Innodb monitors來進(jìn)一步觀察發(fā)生鎖沖突的表，數(shù)據(jù)行等，并分析鎖爭用的原因
show ENGINE innodb status
//停止監(jiān)視器
drop table innodb_monitor;
//默認(rèn)情況每15秒回向日志中記錄監(jiān)控的內(nèi)容，如果長時間打開會導(dǎo)致.err文件變得非常巨大，所以確認(rèn)原因后，要刪除監(jiān)控表關(guān)閉監(jiān)視器，或者通過使用--console選項來啟動服務(wù)器以關(guān)閉寫日志功能

InnoDB的行鎖模式及加鎖方法

InnoDB實(shí)現(xiàn)了以下兩種類型的行鎖。

• 共享鎖（S）：允許一個事務(wù)去讀一行，阻止其他事務(wù)獲得相同數(shù)據(jù)集的排他鎖。
• 排他鎖（X）：允許獲取排他鎖的事務(wù)更新數(shù)據(jù)，阻止其他事務(wù)取得相同的數(shù)據(jù)集共享讀鎖和排他寫鎖。另外，為了允許行鎖和表鎖共存，實(shí)現(xiàn)多粒度鎖機(jī)制，InnoDB還有兩種內(nèi)部使用的意向鎖（Intention Locks），這兩種意向鎖都是表鎖。
• 意向共享鎖（IS）：事務(wù)打算給數(shù)據(jù)行共享鎖，事務(wù)在給一個數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖。
• 意向排他鎖（IX）：事務(wù)打算給數(shù)據(jù)行加排他鎖，事務(wù)在給一個數(shù)據(jù)行加排他鎖前必須先取得該表的IX鎖。

|當(dāng)前鎖模式/是否兼容/請求鎖模式|X|IX|S|IS|
| ------------- |:-------------:|
|X| 沖突| 沖突| 沖突| 沖突|
|IX|沖突|兼容|沖突|兼容|
|S| 沖突| 沖突|兼容|兼容|
|IS|沖突|兼容|兼容|兼容|

如果一個事務(wù)請求的鎖模式與當(dāng)前的鎖兼容，InnoDB就請求的鎖授予該事務(wù)；反之，如果兩者兩者不兼容，該事務(wù)就要等待鎖釋放。意向鎖是InnoDB自動加的，不需用戶干預(yù)。對于UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及及數(shù)據(jù)集排他鎖（X）；對于普通SELECT語句，InnoDB不會任何鎖；事務(wù)可以通過以下語句顯示給記錄集加共享鎖或排鎖。

• 共享鎖（Ｓ）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
• 排他鎖（X）：SELECT * FROM table_name WHERE ... FOR UPDATE

用SELECT .. IN SHARE MODE獲得共享鎖，主要用在需要數(shù)據(jù)依存關(guān)系時確認(rèn)某行記錄是否存在，并確保沒有人對這個記錄進(jìn)行UPDATE或者DELETE操作。但是如果當(dāng)前事務(wù)也需要對該記錄進(jìn)行更新操作，則很有可能造成死鎖，對于鎖定行記錄后需要進(jìn)行更新操作的應(yīng)用，應(yīng)該使用SELECT ... FOR UPDATE方式獲取排他鎖。

例子

Innodb共享鎖的例子

排他鎖例子

Innodb行鎖實(shí)現(xiàn)方式

InnoDb行鎖是通過給索引上的索引項加鎖來實(shí)現(xiàn)，如果沒有索引，InnoDB將通過隱藏的聚簇索引來對記錄加鎖

• Record Locks:對索引項加鎖
• Gap lock:對索引項之的“間隙“，第一天記錄前的”間隙“，或最后一條記錄后的”間隙“，加鎖
• Next-key lock：前兩種的組合，對記錄及其前面的間隙枷鎖

InnoDb 這中行鎖，實(shí)現(xiàn)特點(diǎn)意味著：如果不通過索引條件檢索數(shù)據(jù)，那么Innodb將對表的所有記錄枷鎖，實(shí)際效果和表鎖一樣

間隙鎖（Next-Key鎖）

SELECT * FROM emp WHERE empid > 100 FOR UPDATE
//    是一個范圍條件的檢索，InnoDB不僅會對符合條件的empid值為101的記錄加鎖，也會對empid大于101（這些記錄并不存在）的“間隙”加鎖。

InnoDB使用間隙鎖的目的，一方面是為了防止幻讀，以滿足相關(guān)隔離級別的要求，對于上面的例子，要是不使用間隙鎖，如果其他事務(wù)插入了empid大于100的任何記錄，那么本事務(wù)如果再次執(zhí)行上述語句，就會發(fā)生幻讀；另一方面，是為了滿足其恢復(fù)和復(fù)制的需要。很顯然，在使用范圍條件檢索并鎖定記錄時，InnoDB這種加鎖機(jī)制會阻塞符合條件范圍內(nèi)鍵值的并發(fā)插入，這往往會造成嚴(yán)重的鎖等待。因此，在實(shí)際開發(fā)中，尤其是并發(fā)插入比較多的應(yīng)用，我們要盡量優(yōu)化業(yè)務(wù)邏輯，盡量使用相等條件來訪問更新數(shù)據(jù)，避免使用范圍條件。

什么時候使用表鎖

對于InnoDB表，在絕大部分情況下都應(yīng)該使用行級鎖，因?yàn)槭聞?wù)和行鎖往往是我們之所以選擇InnoDB表的理由。但在個別特殊事務(wù)中，也可以考慮使用表級鎖。

• 第一種情況是：事務(wù)需要更新大部分或全部數(shù)據(jù)，表又比較大，如果使用默認(rèn)的行鎖，不僅這個事務(wù)執(zhí)行效率低，而且可能造成其他事務(wù)長時間鎖等待和鎖沖突，這種情況下可以考慮使用表鎖來提高該事務(wù)的執(zhí)行速度。
• 第二種情況是：事務(wù)涉及多個表，比較復(fù)雜，很可能引起死鎖，造成大量事務(wù)回滾。這種情況也可以考慮一次性鎖定事務(wù)涉及的表，從而避免死鎖、減少數(shù)據(jù)庫因事務(wù)回滾帶來的開銷。

當(dāng)然，應(yīng)用中這兩種事務(wù)不能太多，否則，就應(yīng)該考慮使用ＭyISAＭ表。 在InnoDB下 ，使用表鎖要注意以下兩點(diǎn)。

1. 使用LOCK TALBES雖然可以給InnoDB加表級鎖，但必須說明的是，表鎖不是由InnoDB存儲引擎層管理的，而是由其上一層ＭySQL Server負(fù)責(zé)的，僅當(dāng)autocommit=0、innodb_table_lock=1（默認(rèn)設(shè)置）時，InnoDB層才能知道MySQL加的表鎖，ＭySQL Server才能感知InnoDB加的行鎖，這種情況下，InnoDB才能自動識別涉及表級鎖的死鎖；否則，InnoDB將無法自動檢測并處理這種死鎖。
2. 在用LOCAK TABLES對InnoDB鎖時要注意，要將AUTOCOMMIT設(shè)為0，否則ＭySQL不會給表加鎖；事務(wù)結(jié)束前，不要用UNLOCAK TABLES釋放表鎖，因?yàn)閁NLOCK TABLES會隱含地提交事務(wù)；COMMIT或ROLLBACK產(chǎn)不能釋放用LOCAK TABLES加的表級鎖，必須用UNLOCK TABLES釋放表鎖，正確的方式見如下語句。

// 例如，如果需要寫表t1并從表t讀，可以按如下做：

SET AUTOCOMMIT=0;
LOCAK TABLES t1 WRITE, t2 READ, ...;
[do something with tables t1 and here];
COMMIT;
UNLOCK TABLES;

關(guān)于死鎖

ＭyISAM表鎖是deadlock free的，這是因?yàn)椋蛓ISAM總是一次性獲得所需的全部鎖，要么全部滿足，要么等待，因此不會出現(xiàn)死鎖。但是在InnoDB中，除單個SQL組成的事務(wù)外，鎖是逐步獲得的，這就決定了InnoDB發(fā)生死鎖是可能的。
發(fā)生死鎖后，InnoDB一般都能自動檢測到，并使一個事務(wù)釋放鎖并退回，另一個事務(wù)獲得鎖，繼續(xù)完成事務(wù)。但在涉及外部鎖，或涉及鎖的情況下，InnoDB并不能完全自動檢測到死鎖，這需要通過設(shè)置鎖等待超時參數(shù)innodb_lock_wait_timeout來解決。需要說明的是，這個參數(shù)并不是只用來解決死鎖問題，在并發(fā)訪問比較高的情況下，如果大量事務(wù)因無法立即獲取所需的鎖而掛起，會占用大量計算機(jī)資源，造成嚴(yán)重性能問題，甚至拖垮數(shù)據(jù)庫。我們通過設(shè)置合適的鎖等待超時閾值，可以避免這種情況發(fā)生。
通常來說，死鎖都是應(yīng)用設(shè)計的問題，通過調(diào)整業(yè)務(wù)流程、數(shù)據(jù)庫對象設(shè)計、事務(wù)大小、以及訪問數(shù)據(jù)庫的SQL語句，絕大部分都可以避免。下面就通過實(shí)例來介紹幾種死鎖的常用方法。

1. 在應(yīng)用中，如果不同的程序會并發(fā)存取多個表，應(yīng)盡量約定以相同的順序?yàn)樵L問表，這樣可以大大降低產(chǎn)生死鎖的機(jī)會。如果兩個session訪問兩個表的順序不同，發(fā)生死鎖的機(jī)會就非常高！但如果以相同的順序來訪問，死鎖就可能避免。
2. 在程序以批量方式處理數(shù)據(jù)的時候，如果事先對數(shù)據(jù)排序，保證每個線程按固定的順序來處理記錄，也可以大大降低死鎖的可能。
3. 在事務(wù)中，如果要更新記錄，應(yīng)該直接申請足夠級別的鎖，即排他鎖，而不應(yīng)該先申請共享鎖，更新時再申請排他鎖，甚至死鎖。
4. 在REPEATEABLE-READ隔離級別下，如果兩個線程同時對相同條件記錄用SELECT...ROR UPDATE加排他鎖，在沒有符合該記錄情況下，兩個線程都會加鎖成功。程序發(fā)現(xiàn)記錄尚不存在，就試圖插入一條新記錄，如果兩個線程都這么做，就會出現(xiàn)死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可以避免問題。
5. 當(dāng)隔離級別為READ COMMITED時，如果兩個線程都先執(zhí)行SELECT...FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時，只有一個線程能插入成功，另一個線程會出現(xiàn)鎖等待，當(dāng)?shù)冢眰€線程提交后，第２個線程會因主鍵重出錯，但雖然這個線程出錯了，卻會獲得一個排他鎖！這時如果有第３個線程又來申請排他鎖，也會出現(xiàn)死鎖。對于這種情況，可以直接做插入操作，然后再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執(zhí)行ROLLBACK釋放獲得的排他鎖。

如果出現(xiàn)死鎖，可以用SHOW INNODB STATUS命令來確定最后一個死鎖產(chǎn)生的原因和改進(jìn)措施。

鎖總結(jié)

對于MyISAM的表鎖，主要有以下幾點(diǎn)

1. 共享讀鎖（S）之間是兼容的，但共享讀鎖（S）和排他寫鎖（X）之間，以及排他寫鎖之間（X）是互斥的，也就是說讀和寫是串行的。
2. 在一定條件下，ＭyISAM允許查詢和插入并發(fā)執(zhí)行，我們可以利用這一點(diǎn)來解決應(yīng)用中對同一表和插入的鎖爭用問題。
3. ＭyISAM默認(rèn)的鎖調(diào)度機(jī)制是寫優(yōu)先，這并不一定適合所有應(yīng)用，用戶可以通過設(shè)置LOW_PRIPORITY_UPDATES參數(shù)，或在INSERT、UPDATE、DELETE語句中指定LOW_PRIORITY選項來調(diào)節(jié)讀寫鎖的爭用。
4. 由于表鎖的鎖定粒度大，讀寫之間又是串行的，因此，如果更新操作較多，ＭyISAM表可能會出現(xiàn)嚴(yán)重的鎖等待，可以考慮采用InnoDB表來減少鎖沖突。

對于InnoDB表，主要有以下幾點(diǎn)

1. InnoDB的行銷是基于索引實(shí)現(xiàn)的，如果不通過索引訪問數(shù)據(jù)，InnoDB會使用表鎖。
2. InnoDB間隙鎖機(jī)制，以及InnoDB使用間隙鎖的原因。
3. 在不同的隔離級別下，InnoDB的鎖機(jī)制和一致性讀策略不同。
4. ＭySQL的恢復(fù)和復(fù)制對InnoDB鎖機(jī)制和一致性讀策略也有較大影響。
5. 鎖沖突甚至死鎖很難完全避免。

在了解InnoDB的鎖特性后，用戶可以通過設(shè)計和SQL調(diào)整等措施減少鎖沖突和死鎖，包括：

• 盡量使用較低的隔離級別
• 精心設(shè)計索引，并盡量使用索引訪問數(shù)據(jù)，使加鎖更精確，從而減少鎖沖突的機(jī)會。
• 選擇合理的事務(wù)大小，小事務(wù)發(fā)生鎖沖突的幾率也更小。
• 給記錄集顯示加鎖時，最好一次性請求足夠級別的鎖。比如要修改數(shù)據(jù)的話，最好直接申請排他鎖，而不是先申請共享鎖，修改時再請求排他鎖，這樣容易產(chǎn)生死鎖。
• 不同的程序訪問一組表時，應(yīng)盡量約定以相同的順序訪問各表，對一個表而言，盡可能以固定的順序存取表中的行。這樣可以大減少死鎖的機(jī)會。
• 盡量用相等條件訪問數(shù)據(jù)，這樣可以避免間隙鎖對并發(fā)插入的影響。
• 不要申請超過實(shí)際需要的鎖級別；除非必須，查詢時不要顯示加鎖。
• 對于一些特定的事務(wù)，可以使用表鎖來提高處理速度或減少死鎖的可能。

參考文章
深入淺出MySQL數(shù)據(jù)庫開發(fā)、優(yōu)化與管理維護(hù)
http://blog.csdn.net/kash_chen007/article/details/19757577
http://blog.csdn.net/ustczyy/article/details/20567871
http://www.cnblogs.com/chenqionghe/p/4845693.html