Mysql存儲過程、索引

sql語句執行順序:  

    from---> join---> on---> where---> group by---> avg,sum.... ---> having---> select---> distinct---> order by--->  limit 

存儲過程優點:

存儲過程是一組予編譯的 SQL 語句，它的優點有：

允許模塊化程序設計，就是說只需要創建一次過程，以后在程序中就可以調用該過程任意次。
允許更快執行，如果某操作需要執行大量 SQL 語句或重復執行，存儲過程比 SQL 語句執行的要快。
減少網絡流量，例如一個需要數百行的 SQL 代碼的操作有一條執行語句完成，不需要在網絡中發送數百行代碼。

實際上盡量少用存儲過程，因為存儲過程難以調試和擴展

MySQL 存儲過程的創建

CREATE PROCEDURE 存儲過程名(參數列表)
BEGIN
SQL 語句代碼塊
END

查詢user表中有多少用戶demo：
CREATE PROCEDURE proc1(OUT s int)
BEGIN
SELECT COUNT(*) INTO s FROM user;
END

參數： MySQL 存儲過程參數有三種類型：in、out、inout。
如果僅僅想把數據傳給 MySQL 存儲過程，那就使用“in”類型參數；如果僅僅從 MySQL 存儲過程返回值，
那就使用“out”類型參數；如果需要把數據傳給 MySQL 存儲過程，還要經過一些計算后再傳回給我們，
此時，要使用“inout”類型參數。

Mysql 調用儲存過程

Set @n=1 //聲明變量
Call procName(@n) //調用儲存過程

索引

用到索引的地方：join、where、order by

索引是否起作用用explain查看，測試數據量小測試的sql可以拋棄索引。 

ALTER TABLE <表名> ADD INDEX (<字段>);
例：
mysql> alter table t_name add index(field_name);

索引分類

• 普通索引(index)：僅加速查詢

• 唯一索引(unique index)：加速查詢 + 列值唯一（可以有null）

• 主鍵索引(primary key)：加速查詢 + 列值唯一（不可以有null）+ 表中只有一個

• 組合索引：多列值組成一個索引，專門用於組合搜索，其效率大於索引合並

• 全文索引(fulltext)：對文本的內容進行分詞，進行搜索

全文索引要用MATCH (col1,col2,...) AGAINST (expr [search_modifier])查詢

約束

/*外鍵約束,父表一定要設置主鍵不然執行不成功*/
alter table 子表的數據表名 add foreign key(子表的外鍵名稱) references 父表的數據表名稱（父表的主鍵名稱）;   

mysql 分庫分表

分庫分表有垂直切分和水平切分兩種。

垂直切分：即將表按照功能模塊、關系密切程度划分出來，部署到不同的庫上。例如，我們會建立定義數據庫 workDB、商品數據庫 payDB、用戶數據庫 userDB、日志數據庫 logDB 等，分別用於存儲項目數據定義表、商品定義表、用戶數據表、日志數據表等。

水平切分：當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如 userID 散列，進行划分，然后存儲到多個結構相同的表，和不同的庫上。例如，我們的 userDB 中的用戶數據表中，每一個表的數據量都很大，就可以把 userDB 切分為結構相同的多個 userDB：part0DB、part1DB 等，再將 userDB 上的用戶數據表 userTable，切分為很多 userTable：userTable0、userTable1 等，然后將這些表按照一定的規則存儲到多個 userDB 上。

應該使用哪一種方式來實施數據庫分庫分表，這要看數據庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。如果數據庫是因為表太多而造成海量數據，並且項目的各項業務邏輯划分清晰、低耦合，那么規則簡單明了、容易實施的垂直切分必是首選。而如果數據庫中的表並不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬於一體的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，后期也將對項目人員及應用程序產生額外的數據管理負。在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對數據庫進行垂直切分，然后，再針對一部分表，通常是用戶數據表，進行水平切分。

單庫多表 ：
隨着用戶數量的增加，user 表的數據量會越來越大，當數據量達到一定程度的時候對 user 表的查詢會漸漸的變慢，從而影響整個 DB 的性能。如果使用 mysql, 還有一個更嚴重的問題是，當需要添加一列的時候，mysql 會鎖表，期間所有的讀寫操作只能等待。可以將 user 進行水平的切分，產生兩個表結構完全一樣的 user_0000,user_0001 等表，user_0000 +user_0001 + …的數據剛好是一份完整的數據。

多庫多表 ：
隨着數據量增加也許單台 DB 的存儲空間不夠，隨着查詢量的增加單台數據庫服務器已經沒辦法支撐。這個時候可以再對數據庫進行水平區分。分庫分表規則舉例：通過分庫分表規則查找到對應的表和庫的過程。如分庫分表的規則是 user_id 除以 4 的方式，當用戶新注冊了一個賬號，賬號 id 的 123,我們可以通過 id 除以 4 的方式確定此賬號應該保存到 User_0003 表中。當用戶 123 登錄的時候，我們通過 123 除以 4 后確定記錄在 User_0003 中。

mysql 讀寫分離

在實際的應用中，絕大部分情況都是讀遠大於寫。Mysql 提供了讀寫分離的機制，所有的寫操作都必須對應到 Master，讀操作可以在 Master 和 Slave 機器上進行，Slave 與 Master 的結構完全一樣，一個 Master可以有多個 Slave,甚至 Slave 下還可以掛 Slave,通過此方式可以有效的提高 DB 集群的每秒查詢率.所有的寫操作都是先在 Master 上操作，然后同步更新到 Slave 上，所以從 Master 同步到 Slave 機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，Slave 機器數量的增加也會使這個問題更加嚴重。此外，可以看出 Master 是集群的瓶頸，當寫操作過多，會嚴重影響到 Master 的穩定性，如果 Master 掛掉，整個集群都將不能正常工作。所以，
1. 當讀壓力很大的時候，可以考慮添加 Slave 機器的分式解決，但是當 Slave 機器達到一定的數量就得考慮分庫了。 2. 當寫壓力很大的時候，就必須得進行分庫操作。