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. 當寫壓力很大的時候，就必須得進行分庫操作。

轉自：Mysql儲存過程、索引 - 秋夜雨巷 - 部落格園 (cnblogs.com)