2.2.2 多表銜接

1. 【強制】制止跨db的join句子。由于這樣可以減少模塊間耦合，為數(shù)據(jù)庫拆分奠定堅實基礎。
2. 【強制】制止在業(yè)務的更新類SQL句子中運用join，比方update t1 join t2…。
3. 【主張】不主張運用子查詢，主張將子查詢SQL拆開結合程序多次查詢，或運用join來替代子查詢。
4. 【主張】線上環(huán)境，多表join不要超越3個表。
5. 【主張】多表銜接查詢推薦運用別號，且SELECT列表中要用別號引用字段，數(shù)據(jù)庫.表格局，如select a from db1.table1 alias1 where …。
6. 【主張】在多表join中，盡量選取結果集較小的表作為驅(qū)動表，來join其他表。

2.2.3 業(yè)務

1. 【主張】業(yè)務中INSERT|UPDATE|DELETE|REPLACE句子操作的行數(shù)操控在2000以內(nèi)，以及WHERE子句中IN列表的傳參個數(shù)操控在500以內(nèi)。
2. 【主張】批量操作數(shù)據(jù)時，需求操控業(yè)務處理間隔時間，進行必要的sleep，一般主張值5-10秒。
3. 【主張】對于有auto_increment屬性字段的表的刺進操作，并發(fā)需求操控在200以內(nèi)。
4. 【強制】程序設計有必要考慮“數(shù)據(jù)庫業(yè)務阻隔級別”帶來的影響，包括臟讀、不可重復讀和幻讀。線上主張業(yè)務阻隔級別為repeatable-read。
5. 【主張】業(yè)務里包含SQL不超越5個（付出業(yè)務除外）。由于過長的業(yè)務會導致鎖數(shù)據(jù)較久，MySQL內(nèi)部緩存、銜接耗費過多等雪崩問題。
6. 【主張】業(yè)務里更新句子盡量基于主鍵或unique key，如update … where id=XX; 否則會發(fā)生間隙鎖，內(nèi)部擴展確定規(guī)模，導致系統(tǒng)功能下降，發(fā)生死鎖。
7. 【主張】盡量把一些典型外部調(diào)用移出業(yè)務，如調(diào)用webservice，拜訪文件存儲等，然后防止業(yè)務過長。
8. 【主張】對于MySQL主從推遲嚴格靈敏的select句子，請敞開業(yè)務強制拜訪主庫。

2.2.4 排序和分組

1. 【主張】減少運用order by，和業(yè)務溝通能不排序就不排序，或?qū)⑴判蚍诺匠绦蚨巳プ?。order by、group by、distinct這些句子較為耗費CPU，數(shù)據(jù)庫的CPU資源是極端名貴的。
2. 【主張】order by、group by、distinct這些SQL盡量運用索引直接檢索出排序好的數(shù)據(jù)。如where a=1 order by可以運用key(a,b)。
3. 【主張】包含了order by、group by、distinct這些查詢的句子，where條件過濾出來的結果集請保持在1000行以內(nèi)，否則SQL會很慢。

2.2.5 線上制止運用的SQL句子

1. 【高危】禁用update|delete t1 … where a=XX limit XX;這種帶limit的更新句子。由于會導致主從不一致，導致數(shù)據(jù)錯亂。主張加上order by PK。
2. 【高?！恐浦惯\用關聯(lián)子查詢，如update t1 set … where name in(select name from user where…);功率極端低下。
3. 【強制】禁用procedure、function、trigger、views、event、外鍵約束。由于他們耗費數(shù)據(jù)庫資源，下降數(shù)據(jù)庫實例可擴展性。推薦都在程序端完成。
4. 【強制】禁用insert into …on duplicate key update…在高并發(fā)環(huán)境下，會造成主從不一致。
5. 【強制】制止聯(lián)表更新句子，如update t1,t2 where t1.id=t2.id…。