數據庫操作(四)
1.索引原理
1.為什么要有索引?
一般的應用系統，讀寫比例在10:1左右，而且插入操作和一般的更新操作很少出現性能問題，在生產環境中，我們遇到最多的，也是最容易出問題的，還是一些復雜的查詢操作，因此對查詢語句的優化顯然是重中之重。說起加速查詢，就不得不提到索引了。
2.什么是索引?
索引在MySQL中也叫是一種“鍵”，是存儲引擎用於快速找到記錄的一種數據結構。索引對於良好的性能非常關鍵，尤其是當表中的數據量越來越大時，索引對於性能的影響愈發重要。
索引優化應該是對查詢性能優化最有效的手段了。索引能夠輕易將查詢性能提高好幾個數量級。
索引相當於字典的音序表，如果要查某個字，如果不使用音序表，則需要從幾百頁中逐頁去查。
3.對索引的正確理解
索引是應用程序設計和開發的一個重要方面。若索引太多，應用程序的性能可能會受到影響。而索引太少，對查詢性能又會產生影響，要找到一個平衡點，這對應用程序的性能至關重要。一些開發人員總是在事后才想起添加索引----我一直認為，這源於一種錯誤的開發模式。如果知道數據的使用，從一開始就應該在需要處添加索引。開發人員往往對數據庫的使用停留在應用的層面，比如編寫SQL語句、存儲過程之類，他們甚至可能不知道索引的存在，或認為事后讓相關DBA加上即可。DBA往往不夠了解業務的數據流，而添加索引需要通過監控大量的SQL語句進而從中找到問題，這個步驟所需的時間肯定是遠大於初始添加索引所需的時間，並且可能會遺漏一部分的索引。當然索引也並不是越多越好，我曾經遇到過這樣一個問題：某台MySQL服務器iostat顯示磁盤使用率一直處於100%，經過分析后發現是由於開發人員添加了太多的索引，在刪除一些不必要的索引之后，磁盤使用率馬上下降為20%。可見索引的添加也是非常有技術含量的。
索引的影響:①在表中有大量數據的前提下,創建索引速度會很慢②在索引創建完畢后,對表的查詢性能會大幅度提升,但是寫性能會降低
索引原理:
通過不斷地縮小想要獲取數據的范圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是說，有了這種索引機制，我們可以總是用同一種查找方式來鎖定數據。
4.磁盤IO與預讀
簡單介紹一下磁盤IO和預讀，磁盤讀取數據靠的是機械運動，每次讀取數據花費的時間可以分為尋道時間、旋轉延遲、傳輸時間三個部分，尋道時間指的是磁臂移動到指定磁道所需要的時間，主流磁盤一般在5ms以下；旋轉延遲就是我們經常聽說的磁盤轉速，比如一個磁盤7200轉，表示每分鍾能轉7200次，也就是說1秒鍾能轉120次，旋轉延遲就是1/120/2 = 4.17ms；傳輸時間指的是從磁盤讀出或將數據寫入磁盤的時間，一般在零點幾毫秒，相對於前兩個時間可以忽略不計。那么訪問一次磁盤的時間，即一次磁盤IO的時間約等於5+4.17 = 9ms左右，聽起來還挺不錯的，但要知道一台500 -MIPS（Million Instructions Per Second）的機器每秒可以執行5億條指令，因為指令依靠的是電的性質，換句話說執行一次IO的時間可以執行約450萬條指令，數據庫動輒十萬百萬乃至千萬級數據，每次9毫秒的時間，顯然是個災難。下圖是計算機硬件延遲的對比圖，供大家參考：
img
考慮到磁盤IO是非常高昂的操作，計算機操作系統做了一些優化，當一次IO時，不光把當前磁盤地址的數據，而是把相鄰的數據也都讀取到內存緩沖區內，因為局部預讀性原理告訴我們，當計算機訪問一個地址的數據的時候，與其相鄰的數據也會很快被訪問到。每一次IO讀取的數據我們稱之為一頁(page)。具體一頁有多大數據跟操作系統有關，一般為4k或8k，也就是我們讀取一頁內的數據時候，實際上才發生了一次IO，這個理論對於索引的數據結構設計非常有幫助。
5.索引的數據結構
樹
樹狀圖是一種數據結構，它是由n（n>=1）個有限結點組成一個具有層次關系的集合。把它叫做“樹”是因為它看起來像一棵倒掛的樹，也就是說它是根朝上，而葉朝下的。
它具有以下的特點：每個結點有零個或多個子結點；沒有父結點的結點稱為根結點；每一個非根結點有且只有一個父結點；除了根結點外，每個子結點可以分為多個不相交的子樹
img
根結點 : A
父節點 : A是B,C的父節點
葉子節點：D,E是葉子節點
樹的深度/樹的高度：高度為3
B+樹
前面講了索引的基本原理，數據庫的復雜性，又講了操作系統的相關知識，目的就是讓大家了解，任何一種數據結構都不是憑空產生的，一定會有它的背景和使用場景，我們現在總結一下，我們需要這種數據結構能夠做些什么，其實很簡單，那就是：每次查找數據時把磁盤IO次數控制在一個很小的數量級，最好是常數數量級。那么我們就想到如果一個高度可控的多路搜索樹是否能滿足需求呢？就這樣，b+樹應運而生（B+樹是通過二叉查找樹，再由平衡二叉樹，B樹演化而來）。
img
b+樹性質
1.索引字段要盡量的小：通過上面的分析，我們知道IO次數取決於b+數的高度h，假設當前數據表的數據為N，每個磁盤塊的數據項的數量是m，則有h=㏒(m+1)N，當數據量N一定的情況下，m越大，h越小；而m = 磁盤塊的大小 / 數據項的大小，磁盤塊的大小也就是一個數據頁的大小，是固定的，如果數據項占的空間越小，數據項的數量越多，樹的高度越低。這就是為什么每個數據項，即索引字段要盡量的小，比如int占4字節，要比bigint8字節少一半。這也是為什么b+樹要求把真實的數據放到葉子節點而不是內層節點，一旦放到內層節點，磁盤塊的數據項會大幅度下降，導致樹增高。當數據項等於1時將會退化成線性表。
2.索引的最左匹配特性：當b+樹的數據項是復合的數據結構，比如(name,age,sex)的時候，b+數是按照從左到右的順序來建立搜索樹的，比如當(張三,20,F)這樣的數據來檢索的時候，b+樹會優先比較name來確定下一步的所搜方向，如果name相同再依次比較age和sex，最后得到檢索的數據；但當(20,F)這樣的沒有name的數據來的時候，b+樹就不知道下一步該查哪個節點，因為建立搜索樹的時候name就是第一個比較因子，必須要先根據name來搜索才能知道下一步去哪里查詢。比如當(張三,F)這樣的數據來檢索時，b+樹可以用name來指定搜索方向，但下一個字段age的缺失，所以只能把名字等於張三的數據都找到，然后再匹配性別是F的數據了， 這個是非常重要的性質，即索引的最左匹配特性。
6.聚集索引與輔助索引
聚集索引與輔助索引相同的是:不管是聚集索引還是輔助索引,其內部都是B+樹的形式,即高度是平衡的,葉子結點存放着所有的數據
聚集索引與輔助索引不同的是:葉子結點存放的是否是一整行的信息
聚集索引
InnoDB存儲引擎表是索引組織表，即表中數據按照主鍵順序存放。
而聚集索引（clustered index）就是按照每張表的主鍵構造一棵B+樹，同時葉子結點存放的即為整張表的行記錄數據，也將聚集索引的葉子結點稱為數據頁。
聚集索引的這個特性決定了索引組織表中數據也是索引的一部分。同B+樹數據結構一樣，每個數據頁都通過一個雙向鏈表來進行鏈接。
如果未定義主鍵，MySQL取第一個唯一索引（unique）而且只含非空列（NOT NULL）作為主鍵，InnoDB使用它作為聚簇索引。
如果沒有這樣的列，InnoDB就自己產生一個這樣的ID值，它有六個字節，而且是隱藏的，使其作為聚簇索引。
由於實際的數據頁只能按照一棵B+樹進行排序，因此每張表只能擁有一個聚集索引。
在多數情況下，查詢優化器傾向於采用聚集索引。因為聚集索引能夠在B+樹索引的葉子節點上直接找到數據。
此外由於定義了數據的邏輯順序，聚集索引能夠特別快地訪問針對范圍值得查詢。
聚集索引的好處之一：它對主鍵的排序查找和范圍查找速度非常快，葉子節點的數據就是用戶所要查詢的數據。如用戶需要查找一張表，查詢最后的10位用戶信息，由於B+樹索引是雙向鏈表，所以用戶可以快速找到最后一個數據頁，並取出10條記錄
聚集索引的好處之二：范圍查詢（range query），即如果要查找主鍵某一范圍內的數據，通過葉子節點的上層中間節點就可以得到頁的范圍，之后直接讀取數據頁即可
輔助索引
表中除了聚集索引外其他索引都是輔助索引（Secondary Index，也稱為非聚集索引），與聚集索引的區別是：輔助索引的葉子節點不包含行記錄的全部數據。
葉子節點除了包含鍵值以外，每個葉子節點中的索引行中還包含一個書簽（bookmark）。該書簽用來告訴InnoDB存儲引擎去哪里可以找到與索引相對應的行數據。
由於InnoDB存儲引擎是索引組織表，因此InnoDB存儲引擎的輔助索引的書簽就是相應行數據的聚集索引鍵。
輔助索引的存在並不影響數據在聚集索引中的組織，因此每張表上可以有多個輔助索引，但只能有一個聚集索引。當通過輔助索引來尋找數據時，InnoDB存儲引擎會遍歷輔助索引並通過葉子級別的指針獲得只想主鍵索引的主鍵，然后再通過主鍵索引來找到一個完整的行記錄。
舉例來說，如果在一棵高度為3的輔助索引樹種查找數據，那需要對這個輔助索引樹遍歷3次找到指定主鍵，如果聚集索引樹的高度同樣為3，那么還需要對聚集索引樹進行3次查找，最終找到一個完整的行數據所在的頁，因此一共需要6次邏輯IO訪問才能得到最終的一個數據頁。
聚集索引與非聚集索引的區別
聚集索引
1.紀錄的索引順序與無力順序相同
因此更適合between and和order by操作
2.葉子結點直接對應數據
從中間級的索引頁的索引行直接對應數據頁
3.每張表只能創建一個聚集索引
非聚集索引
1.索引順序和物理順序無關
2.葉子結點不直接指向數據頁
3.每張表可以有多個非聚集索引，需要更多磁盤和內容
多個索引會影響insert和update的速度
2.MySQL索引管理
1.功能
- 索引的功能就是加速查找
- mysql中的primary key，unique，聯合唯一也都是索引，這些索引除了加速查找以外，還有約束的功能
2.MySQL常用的索引
普通索引INDEX：加速查找
唯一索引：
-主鍵索引PRIMARY KEY：加速查找+約束（不為空、不能重復）
-唯一索引UNIQUE:加速查找+約束（不能重復）
聯合索引：
-PRIMARY KEY(id,name):聯合主鍵索引
-UNIQUE(id,name):聯合唯一索引
-INDEX(id,name):聯合普通索引
1.各個索引的應用場景
舉個例子來說，比如你在為某商場做一個會員卡的系統。
這個系統有一個會員表
有下列字段：
會員編號 INT
會員姓名 VARCHAR(10)
會員身份證號碼 VARCHAR(18)
會員電話 VARCHAR(10)
會員住址 VARCHAR(50)
會員備注信息 TEXT
那么這個 會員編號，作為主鍵，使用 PRIMARY
會員姓名 如果要建索引的話，那么就是普通的 INDEX
會員身份證號碼 如果要建索引的話，那么可以選擇 UNIQUE （唯一的，不允許重復）
除此之外還有全文索引，即FULLTEXT
會員備注信息,如果需要建索引的話，可以選擇全文搜索。
用於搜索很長一篇文章的時候，效果最好。
用在比較短的文本，如果就一兩行字的，普通的 INDEX 也可以。
但其實對於全文搜索，我們並不會使用MySQL自帶的該索引，而是會選擇第三方軟件如Sphinx，專門來做全文搜索。
其他的如空間索引SPATIAL，了解即可，幾乎不用
2.索引的兩大類型hash與btree
我們可以在創建上述索引的時候，為其指定索引類型，分兩類
hash類型的索引：查詢單條快，范圍查詢慢
btree類型的索引：b+樹，層數越多，數據量指數級增長（我們就用它，因為innodb默認支持它）
不同的存儲引擎支持的索引類型也不一樣
InnoDB 支持事務，支持行級別鎖定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；
MyISAM 不支持事務，支持表級別鎖定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；
Memory 不支持事務，支持表級別鎖定，支持 B-tree、Hash 等索引，不支持 Full-text 索引；
NDB 支持事務，支持行級別鎖定，支持 Hash 索引，不支持 B-tree、Full-text 等索引；
Archive 不支持事務，支持表級別鎖定，不支持 B-tree、Hash、Full-text 等索引；
3.創建/刪除索引的語法
方法一：創建表時
CREATE TABLE 表名 (
字段名1 數據類型 [完整性約束條件…],
字段名2 數據類型 [完整性約束條件…],
[UNIQUE | FULLTEXT | SPATIAL ] INDEX | KEY
[索引名] (字段名[(長度)] [ASC |DESC])
);
方法二：CREATE在已存在的表上創建索引
CREATE [UNIQUE | FULLTEXT | SPATIAL ] INDEX 索引名
ON 表名 (字段名[(長度)] [ASC |DESC]) ;
方法三：ALTER TABLE在已存在的表上創建索引
ALTER TABLE 表名 ADD [UNIQUE | FULLTEXT | SPATIAL ] INDEX
索引名 (字段名[(長度)] [ASC |DESC]) ;
刪除索引：DROP INDEX 索引名 ON 表名字;
舉例:
方式一
create table t1(
id int,
name char,
age int,
sex enum('male','female'),
unique key uni_id(id),
index ix_name(name) #index沒有key
);
create table t1(
id int,
name char,
age int,
sex enum('male','female'),
unique key uni_id(id),
index(name) #index沒有key
);
方式二
create index ix_age on t1(age);
方式三
alter table t1 add index ix_sex(sex);
alter table t1 add index(sex);
查看
mysql> show create table t1;
| t1 | CREATE TABLE t1 (
id int(11) DEFAULT NULL,
name char(1) DEFAULT NULL,
age int(11) DEFAULT NULL,
sex enum('male','female') DEFAULT NULL,
UNIQUE KEY uni_id (id),
KEY ix_name (name),
KEY ix_age (age),
KEY ix_sex (sex)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
測試索引
1.准備
數據准備:
1. 准備表
create table s1(
id int,
name varchar(20),
gender char(6),
email varchar(50)
);
2. 創建存儲過程，實現批量插入記錄
delimiter $$ #聲明存儲過程的結束符號為$$
create procedure auto_insert1()
BEGIN
declare i int default 1;
while(i<3000000)do
insert into s1 values(i,'eva','female',concat('eva',i,'@oldboy'));
set i=i+1;
end while;
END$$ #$$結束
delimiter ; #重新聲明分號為結束符號
3. 查看存儲過程
show create procedure auto_insert1\G
4. 調用存儲過程
call auto_insert1();
2.在沒有索引的前提下測試查詢速度
無索引：mysql根本就不知道到底是否存在id等於333333333的記錄，只能把數據表從頭到尾掃描一遍，此時有多少個磁盤塊就需要進行多少IO操作，所以查詢速度很慢
mysql> select * from s1 where id=333333333;
Empty set (0.33 sec)
3.在表中已經存在大量數據的前提下,為某個字段建立索引,建立速度會很慢
mysql>create index a on s1(id);
Query OK,0 rows affected(5.30 sec)
Records:0 Duplicates:0 Warnings:0
4.在索引建立完畢后,以該字段為查詢條件時,查詢速度提升明顯
mysql>select * from s1 where id = 333333333;
Empty set(0.00 sec) #提速效果明顯
ps:
1.mysql先去索引表根據B+樹的搜索原理很快搜索到id=333333333的記錄不存在,IO大大降低,因而速度明顯提升
2.可以去mysql的data目錄下找到該表,可以看到占用的硬盤空間變多了
3.mysql> select * from s1 where email = 'xxxx';
Empty set(0.34 sec)
沒有為email加索引,因而以該字段為查詢條件,速度依然很慢
5.總結
-
一定是為搜索條件的字段創建索引，比如select * from s1 where id = 333;就需要為id加上索引
-
在表中已經有大量數據的情況下，建索引會很慢，且占用硬盤空間，建完后查詢速度加快
比如create index idx on s1(id);會掃描表中所有的數據，然后以id為數據項，創建索引結構，存放於硬盤的表中。
建完以后，再查詢就會很快了。 -
需要注意的是：innodb表的索引會存放於s1.ibd文件中，而myisam表的索引則會有單獨的索引文件table1.MYI
MySAM索引文件和數據文件是分離的，索引文件僅保存數據記錄的地址。而在innodb中，表數據文件本身就是按照B+Tree（BTree即Balance True）組織的一個索引結構，這棵樹的葉節點data域保存了完整的數據記錄。這個索引的key是數據表的主鍵，因此innodb表數據文件本身就是主索引。
因為inndob的數據文件要按照主鍵聚集，所以innodb要求表必須要有主鍵（Myisam可以沒有），如果沒有顯式定義，則mysql系統會自動選擇一個可以唯一標識數據記錄的列作為主鍵，如果不存在這種列，則mysql會自動為innodb表生成一個隱含字段作為主鍵，這字段的長度為6個字節，類型為長整型.
6.正確使用索引
創建索引但是無法命中索引,在添加索引時必須注意以下問題
1.范圍問題,或者說條件不明確，條件中出現這些符號或關鍵字：>、>=、<、<=、!= 、between...and...、like、
舉例:
id = 1000 明確指定要找1000這個id,在索引樹中可以快速找到
id > 1000 也會利用索引樹,但是指定的范圍過大,mysql會挨個到搜索樹中搜索,跟全表掃描沒多大區別
id > 1000 and id < 2000 范圍很小,查詢速度仍然很快
id != 1000 范圍很大,所以速度也會很慢
id between 1 and 300000 范圍大,查詢速度很慢
id between 1 and 3 范圍小,查詢速度很快
email = 'xxxx' 沒有給email字段添加索引,查詢速度慢,添加索引后很快
email like 'xxxx' like指定的是一個明確的值,速度依然很快
email like 'xx%' 通配符在末尾,查詢速度依然很快
email like '%xx' 通配符在開頭,查詢速度慢
2.盡量選擇區分度高的列作為索引,區分度的公式是count(distinct col)/count(*)，表示字段不重復的比例，比例越大我們掃描的記錄數越少，唯一鍵的區分度是1，而一些狀態、性別字段可能在大數據面前區分度就是0，那可能有人會問，這個比例有什么經驗值嗎？使用場景不同，這個值也很難確定，一般需要join的字段我們都要求是0.1以上，即平均1條掃描10條記錄
舉例:
select count(*) from s1 where name = 'xxx';
沒有為name添加索引,查詢速度很慢
添加索引:create index b on s1(name);
select count(*) from s1 where name = 'xxx';
添加索引后,查詢速度變快
select count(*) from s1 where name = 'egon';
查詢速度變慢,因為無法從樹的某個位置得到一個明確的范圍,需要類似全表掃描.
3.索引列不能在條件中參與計算，保持列“干凈”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很簡單，b+樹中存的都是數據表中的字段值，但進行檢索時，需要把所有元素都應用函數才能比較，顯然成本太大。所以語句應該寫成create_time = unix_timestamp(’2014-05-29’)
select count(*) from s1 where id = 3000;
id字段有索引所以查詢速度很快
select count() from s1 where id3 = 3000;
索引字段id參與了計算,無法拿到一個明確的值去索引樹中查找,每次都得臨時計算以下,所以速度變慢
4.and/or
①and與or的邏輯
條件1 and 條件2:所有條件都成立才算成立，但凡要有一個條件不成立則最終結果不成立
條件1 or 條件2:只要有一個條件成立則最終結果就成立
②and的工作原理
條件：
a = 10 and b = 'xxx' and c > 3 and d =4
索引：
制作聯合索引(d,a,b,c)
工作原理:
對於連續多個and：mysql會按照聯合索引，從左到右的順序找一個區分度高的索引字段(這樣便可以快速鎖定很小的范圍)，加速查詢，即按照d—>a->b->c的順序
③or的工作原理
條件：
a = 10 or b = 'xxx' or c > 3 or d =4
索引：
制作聯合索引(d,a,b,c)
工作原理:
對於連續多個or：mysql會按照條件的順序，從左到右依次判斷，即a->b->c->d
5.最左前綴匹配原則，非常重要的原則，對於組合索引mysql會一直向右匹配直到遇到范圍查詢(>、<、between、like)就停止匹配(指的是范圍大了，有索引速度也慢)，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調整。
6.其他情況
-
使用函數
select * from tb1 where reverse(email) = 'egon'; -
類型不一致
如果列是字符串類型，傳入條件是必須用引號引起來，不然...
select * from tb1 where email = 999;
排序條件為索引，則select字段必須也是索引字段，否則無法命中
-
order by
select name from s1 order by email desc;
當根據索引排序時候，select查詢的字段如果不是索引，則速度仍然很慢
select email from s1 order by email desc;
特別的：如果對主鍵排序，則還是速度很快：
select * from tb1 order by nid desc; -
組合索引最左前綴
如果組合索引為：(name,email)
name and email -- 命中索引
name -- 命中索引
email -- 未命中索引 -
count(1)或count(列)代替count(*)在mysql中沒有差別了
-
create index xxxx on tb(title(19)) #text類型，必須制定長度
其他注意事項:
- 避免使用select *
- 使用count(*)
- 創建表時盡量使用 char 代替 varchar
- 表的字段順序固定長度的字段優先
- 組合索引代替多個單列索引（由於mysql中每次只能使用一個索引，所以經常使用多個條件查詢時更適合使用組合索引）
- 盡量使用短索引
- 使用連接（JOIN）來代替子查詢(Sub-Queries)
- 連表時注意條件類型需一致
- 索引散列值（重復少）不適合建索引，例：性別不適合
3.聯合索引與覆蓋索引
聯合索引
聯合索引是指對表上的多個列合起來做一個索引。聯合索引的創建方法與單個索引的創建方法一樣，不同之處僅在於有多個索引列，如下
mysql> create table t(
-> a int,
-> b int,
-> primary key(a),
-> key idx_a_b(a,b)
-> );
那么何時需要使用聯合索引呢？在討論這個問題之前，先來看一下聯合索引內部的結果。從本質上來說，聯合索引就是一棵B+樹，不同的是聯合索引的鍵值得數量不是1，而是>=2。接着來討論兩個整型列組成的聯合索引，假定兩個鍵值得名稱分別為a、b如圖
img
可以看到這與我們之前看到的單個鍵的B+樹並沒有什么不同，鍵值都是排序的，通過葉子結點可以邏輯上順序地讀出所有數據，就上面的例子來說，即（1,1），（1,2），（2,1），（2,4），（3,1），（3,2），數據按（a,b）的順序進行了存放。
因此，對於查詢select * from table where a=xxx and b=xxx, 顯然是可以使用(a,b) 這個聯合索引的，對於單個列a的查詢select * from table where a=xxx,也是可以使用（a,b）這個索引的。
但對於b列的查詢select * from table where b=xxx,則不可以使用（a,b） 索引，其實你不難發現原因，葉子節點上b的值為1、2、1、4、1、2顯然不是排序的，因此對於b列的查詢使用不到(a,b) 索引
聯合索引的第二個好處是在第一個鍵相同的情況下，已經對第二個鍵進行了排序處理，例如在很多情況下應用程序都需要查詢某個用戶的購物情況，並按照時間進行排序，最后取出最近三次的購買記錄，這時使用聯合索引可以幫我們避免多一次的排序操作，因為索引本身在葉子節點已經排序了，
覆蓋索引
InnoDB存儲引擎支持覆蓋索引（covering index，或稱索引覆蓋），即從輔助索引中就可以得到查詢記錄，而不需要查詢聚集索引中的記錄。
使用覆蓋索引的一個好處是：輔助索引不包含整行記錄的所有信息，故其大小要遠小於聚集索引，因此可以減少大量的IO操作
注意：覆蓋索引技術最早是在InnoDB Plugin中完成並實現，這意味着對於InnoDB版本小於1.0的，或者MySQL數據庫版本為5.0以下的，InnoDB存儲引擎不支持覆蓋索引特性
對於InnoDB存儲引擎的輔助索引而言，由於其包含了主鍵信息，因此其葉子節點存放的數據為（primary key1，priamey key2，...,key1，key2，...）.
覆蓋索引的另外一個好處是對某些統計問題而言的。innodb存儲引擎並不會選擇通過查詢聚集索引來進行統計.
對於（a,b）形式的聯合索引，一般是不可以選擇b中所謂的查詢條件。但如果是統計操作，並且是覆蓋索引，則優化器還是會選擇使用該索引
查詢優化命令 -- explain
關於explain命令相信大家並不陌生，具體用法和字段含義可以參考官網explain-output，這里需要強調rows是核心指標，絕大部分rows小的語句執行一定很快（有例外，下面會講到）。所以優化語句基本上都是在優化rows。
執行計划：讓mysql預估執行操作(一般正確)
all < index < range < index_merge < ref_or_null < ref < eq_ref < system/const
id,email
慢：
select * from userinfo3 where name='alex'
explain select * from userinfo3 where name='alex'
type: ALL(全表掃描)
select * from userinfo3 limit 1;
快：
select * from userinfo3 where email='alex'
type: const(走索引)
4.索引操作
普通索引\聚集索引(主鍵)\唯一索引(unique)
索引操作:
添加主鍵索引:
創建的時候添加: 添加索引的時候要注意,給字段里面數據大小比較小的字段添加,給字段里面的數據區分度高的字段添加.
聚集索引的添加方式
創建的時候添加:
create table t1(id int primary key,);
create table t1(id int,primary key(id));
表創建完了之后添加:
alter table 表名 add primary key(id)
刪除主鍵索引:
alter table 表名 drop primary key;
唯一索引:
Create table t1(id int unique);
Create table t1(id int,unique key uni_name (id));
表創建好之后添加唯一索引:
alter table s1 add unique key u_name(id);
刪除:
alter table s1 drop index u_name;
普通索引:
創建:
Create table t1(id int,index index_name(id));
表創建后添加:
alter table s1 add index index_name(id);
create index index_name on s1(id);
刪除:
alter table s1 drop index u_name;
drop index 索引名 on 表名字;
聯合索引(聯合主鍵\聯合唯一\聯合普通索引)
create table t1(Id int,
name char(10),
index index_name(id,name)
);
5.事務
事務是由一組SQL語句組成的邏輯處理單元，事務具有ACID屬性。
原子性（Atomicity）：事務是一個原子操作單元。原子是不可分割的最小元素，其對數據的修改，要么全部成功，要么全部都不成功。
一致性（Consistent）：事務開始到結束的時間段內，數據都必須保持一致狀態。
隔離性（Isolation）：數據庫系統提供一定的隔離機制，保證事務在不受外部並發操作影響的"獨立"環境執行。
持久性（Durable）：事務完成后，它對於數據的修改是永久性的，即使出現系統故障也能夠保持。
事務常見問題:
更新丟失（Lost Update）
原因：當多個事務選擇同一行操作，並且都是基於最初選定的值，由於每個事務都不知道其他事務的存在，就會發生更新覆蓋的問題。類比github提交沖突。
臟讀（Dirty Reads）
原因：事務A讀取了事務B已經修改但尚未提交的數據。若事務B回滾數據，事務A的數據存在不一致性的問題。
不可重復讀（Non-Repeatable Reads）
原因：事務A第一次讀取最初數據，第二次讀取事務B已經提交的修改或刪除數據。導致兩次讀取數據不一致。不符合事務的隔離性。
幻讀（Phantom Reads）
原因：事務A根據相同條件第二次查詢到事務B提交的新增數據，兩次數據結果集不一致。不符合事務的隔離性。
幻讀和臟讀有點類似
臟讀是事務B里面修改了數據，
幻讀是事務B里面新增了數據。
事務用於將某些操作的多個SQL作為原子性操作，也就是這些sql語句要么同時成功，要么都不成功，事務的其他特性在我第一篇博客關於事務的介紹里面有，這里就不多做介紹啦，一旦有某一個出現錯誤，即可回滾到原來的狀態，從而保證數據庫數據完整性。
簡單來說：給別人轉賬，他收到了200，你的賬戶上扣了200，這兩個操作是不是兩個sql語句，這兩個sql語句是你的應用程序發給mysql服務端的，並且這兩個sql語句都要一起執行，不然數據就錯了.並且如果你通過應用程序發送這兩條sql的時候，由於網絡問題，你只發送了一個sql過來，那只有一個賬戶改了數據，另外一個沒改，那數據就出錯了。這就是事務要完成的事情。
舉例:
create table user(
id int primary key auto_increment,
name char(32),
balance int
);
insert into user(name,balance)
values
('wsb',1000),
('chao',1000),
('ysb',1000);
原子操作
start transaction;
update user set balance=900 where name='wsb'; #買支付100元
update user set balance=1010 where name='chao'; #中介拿走10元
update user set balance=1090 where name='ysb'; #賣家拿到90元
commit; #只要不進行commit操作，就沒有保存下來，沒有刷到硬盤上
出現異常，回滾到初始狀態
start transaction;
update user set balance=900 where name='wsb'; #買支付100元
update user set balance=1010 where name='chao'; #中介拿走10元
uppdate user set balance=1090 where name='ysb'; #賣家拿到90元,出現異常沒有拿到
rollback; #如果上面三個sql語句出現了異常，就直接rollback，數據就直接回到原來的狀態了。但是執行了commit之后，rollback這個操作就沒法回滾了
我們要做的是檢測這幾個sql語句是否異常，沒有異常直接commit，有異常就rollback，但是現在單純的只是開啟了事務，但是還沒有說如何檢測異常，我們先來一個存儲過程來捕獲異常，等我們學了存儲過程，再細說存儲過程。
commit;
通過存儲過程來捕獲異常：(shit！，寫存儲過程的是，注意每一行都不要縮進！！！按照下面的縮進來寫，居然讓我翻車了！！！我記住你了~~~)，我的代碼直接黏貼就能用。
delimiter //
create PROCEDURE p5()
BEGIN
DECLARE exit handler for sqlexception
BEGIN
rollback;
END;
START TRANSACTION;
update user set balance=900 where name='wsb'; #買支付100元
update user set balance=1010 where name='chao'; #中介拿走10元
update user2 set balance=1090 where name='ysb'; #賣家拿到90元
update user set balance=1090 where name='ysb'; #賣家拿到90元
COMMIT;
END //
delimiter ;
mysql> select * from user;
+----+------+---------+
| id | name | balance |
+----+------+---------+
| 1 | wsb | 1000 |
| 2 | chao | 1000 |
| 3 | ysb | 1000 |
+----+------+---------+
3 rows in set (0.00 sec)
6.數據備份與還原
- 物理備份： 直接復制數據庫文件，適用於大型數據庫環境。但不能恢復到異構系統中如Windows。
- 邏輯備份： 備份的是建表、建庫、插入等操作所執行SQL語句，適用於中小型數據庫，效率相對較低。
- 導出表： 將表導入到文本文件中。
使用mysqldump實現備份
語法：
mysqldump -u用戶名 -p密碼 -B -d 庫名>保存路徑(G:\sql\t1.sql)
使用mysqldump實現還原
語法：
mysql -u用戶名 -p密碼 <保存路徑(G:\sql\t1.sql)
-B參數導出的文件中自帶創建數據庫和連接數據庫的功能：(使用-B參數備份出來的內容自帶create database 庫名和use 庫名的功能)
執行備份語句的時候，其中可以加上很多的參數，用來添加一些備份的時候的特殊要求的，其中有一個-B參數，執行備份語句時，如果加上了-B參數，那么將來再執行數據還原的時候，就不需要自己到數據庫里面去先創建同名的這個庫了，並且執行數據還原語句的時候就不需要指定這個庫了，如果沒有加-B參數，就需要自行到數據庫中先創建一個同名庫，並且執行語句是要指定將數據恢復到這個庫里面
mysqldump的關鍵參數說明：
1.-B指定多個庫，增加建庫語句和use 語句
2.--compact 去掉注釋，適合調試輸出，生產上不用
3.-A或者--all-databases
例如：C:\WINDOWS\system32>mysqldump -uroot -p -B -A> f:\數據庫備份練習\all.sql
Enter password: ***
4.-F刷新binlog日志(binlog具體是什么，后面咱們再解釋)
5.--master-data 增加binlog日志文件名及對應的為支點。
6.-x，--lock-all-tables 將所有的表鎖住，一般mysql引擎都是鎖表，全部都不能使用了
7.--add-locks這個選項會在INSERT語句中捆上一個LOCK TABLE和UNLOCK TABLE語句。這就防止在這些記錄被再次導入數據庫時其他用戶對表進行的操作(mysql默認是加上的)
8.-l，--lock-tables Lock all tables for read
9.-d 只備份表結構
10.-t 只備份數據
11. --single-transaction 開啟事務，適合innodb事務數據庫備份
InnoDB表在備份時，通常啟用選項--single-transaction來保證備份的一致性，實際上他的工作原理時設定本次會話的隔離界別為：REPEATABLE READ，以確保本次會話(dump)時，不會看到其他會話已經提交了數據。
MyISAM全庫備份指令推薦：(gzip是壓縮文件為zip類型的)
mysqldump -uroot -p666 -A -B --master-data=2 -x|gzip>f:\數據庫備份練習\all.sql.gz
InnoDB全庫備份指令推薦：
mysqldump -uroot -p666 -A -B --master-data=2 --single-transaction|gzip>f:\數據庫備份練習\all.sql.gz
7.鎖
數據庫鎖定機制簡單來說，就是數據庫為了保證數據的一致性，而使各種共享資源在被並發訪問變得有序所設計的一種規則。對於任何一種數據庫來說都需要有相應的鎖定機制，所以MySQL自然也不能例外。MySQL數據庫由於其自身架構的特點，存在多種數據存儲引擎，每種存儲引擎所針對的應用場景特點都不太一樣，為了滿足各自特定應用場景的需求，每種存儲引擎的鎖定機制都是為各自所面對的特定場景而優化設計，所以各存儲引擎的鎖定機制也有較大區別。MySQL各存儲引擎使用了三種類型（級別）的鎖定機制：表級鎖定，行級鎖定和頁級鎖定。
表級鎖定
表級別的鎖定是MySQL各存儲引擎中最大顆粒度的鎖定機制。該鎖定機制最大的特點是實現邏輯非常簡單，帶來的系統負面影響最小。所以獲取鎖和釋放鎖的速度很快。由於表級鎖一次會將整個表鎖定，所以可以很好的避免困擾我們的死鎖問題。
當然，鎖定顆粒度大所帶來最大的負面影響就是出現鎖定資源爭用的概率也會最高，致使並大度大打折扣。
使用表級鎖定的主要是MyISAM，MEMORY，CSV等一些非事務性存儲引擎。
行級鎖定
行級鎖定最大的特點就是鎖定對象的顆粒度很小，也是目前各大數據庫管理軟件所實現的鎖定顆粒度最小的。由於鎖定顆粒度很小，所以發生鎖定資源爭用的概率也最小，能夠給予應用程序盡可能大的並發處理能力而提高一些需要高並發應用系統的整體性能。
雖然能夠在並發處理能力上面有較大的優勢，但是行級鎖定也因此帶來了不少弊端。由於鎖定資源的顆粒度很小，所以每次獲取鎖和釋放鎖需要做的事情也更多，帶來的消耗自然也就更大了。此外，行級鎖定也最容易發生死鎖。
使用行級鎖定的主要是InnoDB存儲引擎。
頁級鎖定
頁級鎖定是MySQL中比較獨特的一種鎖定級別，在其他數據庫管理軟件中也並不是太常見。頁級鎖定的特點是鎖定顆粒度介於行級鎖定與表級鎖之間，所以獲取鎖定所需要的資源開銷，以及所能提供的並發處理能力也同樣是介於上面二者之間。另外，頁級鎖定和行級鎖定一樣，會發生死鎖。
在數據庫實現資源鎖定的過程中，隨着鎖定資源顆粒度的減小，鎖定相同數據量的數據所需要消耗的內存數量是越來越多的，實現算法也會越來越復雜。不過，隨着鎖定資源顆粒度的減小，應用程序的訪問請求遇到鎖等待的可能性也會隨之降低，系統整體並發度也隨之提升。
使用頁級鎖定的主要是BerkeleyDB存儲引擎。
總的來說，MySQL這3種鎖的特性可大致歸納如下：
表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高，並發度最低；
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，並發度也最高；
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並發度一般。
適用：從鎖的角度來說，表級鎖更適合於以查詢為主，只有少量按索引條件更新數據的應用，如Web應用；而行級鎖則更適合於有大量按索引條件並發更新少量不同數據，同時又有並發查詢的應用，如一些在線事務處理（OLTP）系統。
表級鎖定(以myisam為例)操作
表鎖，讀鎖會阻塞寫，不會阻塞讀。而寫鎖則會把讀寫都阻塞。
顯示加鎖：
共享讀鎖：lock table tableName read;
獨占寫鎖：lock table tableName write;
同時加多鎖：lock table t1 write,t2 read;
批量解鎖：unlock tables;
行級鎖定(以Innodb為例)
共享鎖: select 字段列表 from 表名 where 條件 lock in share mode;
排他鎖: select 字段列表 from 表名 where 條件 for update;