如何去寫一手好SQL ？
作者：編碼磚家
http：//
cnblogs。com/xiaoyangjia
/p/11267191。html
MySQL效能
最大資料量
最大併發數
查詢耗時0。5秒
實施原則
資料表設計
資料型別
避免空值
text型別
索引最佳化
索引分類
最佳化原則
SQL最佳化
分批處理
不做列運算
避免Select *
運算子<>最佳化
OR最佳化
IN最佳化
LIKE最佳化
JOIN最佳化
LIMIT最佳化
其他資料庫
博主負責的專案主要採用阿里雲資料庫MySQL，最近頻繁出現慢SQL告警，執行時間最長的竟然高達5分鐘。匯出日誌後分析，主要原因竟然是沒有命中索引和沒有分頁處理。其實這是非常低階的錯誤，我不禁後背一涼，團隊成員的技術水平亟待提高啊。改造這些SQL的過程中，總結了一些經驗分享給大家，如果有錯誤歡迎批評指正。
MySQL效能
最大資料量
拋開資料量和併發數，談效能都是耍流氓。MySQL沒有限制單表最大記錄數，它取決於作業系統對檔案大小的限制。
《阿里巴巴Java開發手冊》提出單錶行數超過500萬行或者單表容量超過2GB，才推薦分庫分表。效能由綜合因素決定，拋開業務複雜度，影響程度依次是硬體配置、MySQL配置、資料表設計、索引最佳化。500萬這個值僅供參考，並非鐵律。
博主曾經操作過超過4億行資料的單表，分頁查詢最新的20條記錄耗時0。6秒，SQL語句大致是
select field_1，field_2 from table where id < #{prePageMinId} order by id desc limit 20
，prePageMinId是上一頁資料記錄的最小ID。
雖然當時查詢速度還湊合，隨著資料不斷增長，有朝一日必定不堪重負。分庫分表是個週期長而風險高的大活兒，應該儘可能在當前結構上最佳化，比如升級硬體、遷移歷史資料等等，實在沒轍了再分。對分庫分表感興趣的同學可以閱讀分庫分表的基本思想。
最大併發數
併發數是指同一時刻資料庫能處理多少個請求，由max_connections和max_user_connections決定。max_connections是指MySQL例項的最大連線數，上限值是16384，max_user_connections是指每個資料庫使用者的最大連線數。
MySQL會為每個連線提供緩衝區，意味著消耗更多的記憶體。如果連線數設定太高硬體吃不消，太低又不能充分利用硬體。一般要求兩者比值超過10%，計算方法如下：
max_used_connections / max_connections * 100% = 3/100 *100% ≈ 3%
檢視最大連線數與響應最大連線數：
show variables like ‘%max_connections%’；
show variables like ‘%max_user_connections%’；
在配置檔案my。cnf中修改最大連線數
［mysqld］
max_connections = 100
max_used_connections = 20
查詢耗時0。5秒
建議將單次查詢耗時控制在0。5秒以內，0。5秒是個經驗值，源於使用者體驗的3秒原則。如果使用者的操作3秒內沒有響應，將會厭煩甚至退出。響應時間=客戶端UI渲染耗時+網路請求耗時+應用程式處理耗時+查詢資料庫耗時，0。5秒就是留給資料庫1/6的處理時間。
實施原則
相比NoSQL資料庫，MySQL是個嬌氣脆弱的傢伙。它就像體育課上的女同學，一點糾紛就和同學鬧彆扭（擴容難），跑兩步就氣喘吁吁（容量小併發低），常常身體不適要請假（SQL約束太多）。如今大家都會搞點分散式，應用程式擴容比資料庫要容易得多，所以實施原則是
資料庫少幹活，應用程式多幹活
。
充分利用但不濫用索引，須知索引也消耗磁碟和CPU。
不推薦使用資料庫函式格式化資料，交給應用程式處理。
不推薦使用外來鍵約束，用應用程式保證資料準確性。
寫多讀少的場景，不推薦使用唯一索引，用應用程式保證唯一性。
適當冗餘欄位，嘗試建立中間表，用應用程式計算中間結果，用空間換時間。
不允許執行極度耗時的事務，配合應用程式拆分成更小的事務。
預估重要資料表（比如訂單表）的負載和資料增長態勢，提前最佳化。
資料表設計
資料型別
資料型別的選擇原則：更簡單或者佔用空間更小。
如果長度能夠滿足，整型儘量使用tinyint、smallint、medium_int而非int。
如果字串長度確定，採用char型別。
如果varchar能夠滿足，不採用text型別。
精度要求較高的使用decimal型別，也可以使用BIGINT，比如精確兩位小數就乘以100後儲存。
儘量採用timestamp而非datetime。
相比datetime，timestamp佔用更少的空間，以UTC的格式儲存自動轉換時區。
避免空值
MySQL中欄位為NULL時依然佔用空間，會使索引、索引統計更加複雜。從NULL值更新到非NULL無法做到原地更新，容易發生索引分裂影響效能。儘可能將NULL值用有意義的值代替，也能避免SQL語句裡面包含is not null的判斷。
text型別最佳化
由於text欄位儲存大量資料，表容量會很早漲上去，影響其他欄位的查詢效能。建議抽取出來放在子表裡，用業務主鍵關聯。
索引最佳化
索引分類
普通索引：最基本的索引。
組合索引：多個欄位上建立的索引，能夠加速複合查詢條件的檢索。
唯一索引：與普通索引類似，但索引列的值必須唯一，允許有空值。
組合唯一索引：列值的組合必須唯一。
主鍵索引：特殊的唯一索引，用於唯一標識資料表中的某一條記錄，不允許有空值，一般用primary key約束。
全文索引：用於海量文字的查詢，MySQL5。6之後的InnoDB和MyISAM均支援全文索引。由於查詢精度以及擴充套件性不佳，更多的企業選擇Elasticsearch。
索引最佳化
分頁查詢很重要，如果查詢資料量超過30%，MYSQL不會使用索引。
單表索引數不超過5個、單個索引欄位數不超過5個。
字串可使用字首索引，字首長度控制在5-8個字元。
欄位唯一性太低，增加索引沒有意義，如：是否刪除、性別。
合理使用覆蓋索引，如下所示：
select login_name， nick_name from member where login_name = ？
login_name， nick_name兩個欄位建立組合索引，比login_name簡單索引要更快。索引最佳化可以參考：
MySQL索引最佳化分析
SQL最佳化
分批處理
博主小時候看到魚塘挖開小口子放水，水面有各種漂浮物。浮萍和樹葉總能順利通過出水口，而樹枝會擋住其他物體透過，有時還會卡住，需要人工清理。MySQL就是魚塘，最大併發數和網路頻寬就是出水口，使用者SQL就是漂浮物。
不帶分頁引數的查詢或者影響大量資料的update和delete操作，都是樹枝，我們要把它打散分批處理，舉例說明：
業務描述：更新使用者所有已過期的優惠券為不可用狀態。
SQL語句：
update status=0 FROM `coupon` WHERE expire_date <= #{currentDate} and status=1；
如果大量優惠券需要更新為不可用狀態，執行這條SQL可能會堵死其他SQL，分批處理虛擬碼如下：
int pageNo = 1；
int PAGE_SIZE = 100；
while（true） {
List
if （CollectionUtils。isEmpty（batchIdList）） {
return；
}
update（‘update status = 0 FROM `coupon` where status = 1 and id in #{batchIdList}’）
pageNo ++；
}
運算子<>最佳化
通常<>運算子無法使用索引，舉例如下，查詢金額不為100元的訂單：
select id from orders where amount ！= 100；
如果金額為100的訂單極少，這種資料分佈嚴重不均的情況下，有可能使用索引。鑑於這種不確定性，採用union聚合搜尋結果，改寫方法如下：
（select id from orders where amount > 100）
union all
（select id from orders where amount < 100 and amount > 0）
OR最佳化
在Innodb引擎下or無法使用組合索引，比如：
select id，product_name from orders where mobile_no = ‘13421800407’ or user_id = 100；
OR無法命中mobile_no + user_id的組合索引，可採用union，如下所示：
（select id，product_name from orders where mobile_no = ‘13421800407’）
union
（select id，product_name from orders where user_id = 100）；
此時id和product_name欄位都有索引，查詢才最高效。
IN最佳化
IN適合主表大子表小，EXIST適合主表小子表大。由於查詢最佳化器的不斷升級，很多場景這兩者效能差不多一樣了。
嘗試改為join查詢，舉例如下：
select id from orders where user_id in （select id from user where level = ‘VIP’）；
採用JOIN如下所示：
select o。id from orders o left join user u on o。user_id = u。id where u。level = ‘VIP’；
不做列運算
通常在查詢條件列運算會導致索引失效，如下所示：
查詢當日訂單
select id from order where date_format（create_time，‘%Y-%m-%d’） = ‘2019-07-01’；
date_format函式會導致這個查詢無法使用索引，改寫後：
select id from order where create_time between ‘2019-07-01 00：00：00’ and ‘2019-07-01 23：59：59’；
避免Select all
如果不查詢表中所有的列，避免使用SELECT *，它會進行全表掃描，不能有效利用索引。
Like最佳化
like用於模糊查詢，舉個例子（field已建立索引）：
SELECT column FROM table WHERE field like ‘%keyword%’；
這個查詢未命中索引，換成下面的寫法：
SELECT column FROM table WHERE field like ‘keyword%’；
去除了前面的%查詢將會命中索引，但是產品經理一定要前後模糊匹配呢？全文索引fulltext可以嘗試一下，但Elasticsearch才是終極武器。
Join最佳化
join的實現是採用Nested Loop Join演算法，就是透過驅動表的結果集作為基礎資料，透過該結資料作為過濾條件到下一個表中迴圈查詢資料，然後合併結果。如果有多個join，則將前面的結果集作為迴圈資料，再次到後一個表中查詢資料。
驅動表和被驅動表儘可能增加查詢條件，滿足ON的條件而少用Where，用小結果集驅動大結果集。
被驅動表的join欄位上加上索引，無法建立索引的時候，設定足夠的Join Buffer Size。
禁止join連線三個以上的表，嘗試增加冗餘欄位。
Limit最佳化
limit用於分頁查詢時越往後翻效能越差，解決的原則：縮小掃描範圍，如下所示：
select * from orders order by id desc limit 100000，10
耗時0。4秒
select * from orders order by id desc limit 1000000，10
耗時5。2秒
先篩選出ID縮小查詢範圍，寫法如下：
select * from orders where id > （select id from orders order by id desc limit 1000000， 1） order by id desc limit 0，10
耗時0。5秒
如果查詢條件僅有主鍵ID，寫法如下：
select id from orders where id between 1000000 and 1000010 order by id desc
耗時0。3秒
如果以上方案依然很慢呢？只好用遊標了，感興趣的朋友閱讀JDBC使用遊標實現分頁查詢的方法
其他資料庫
作為一名後端開發人員，務必精通作為儲存核心的MySQL或SQL Server，也要積極關注NoSQL資料庫，他們已經足夠成熟並被廣泛採用，能解決特定場景下的效能瓶頸。
參考
https：//www。
jianshu。com/p/6864abb4d
885