如何寫好sql？

MySQL性能

最大數據量

拋開數據量和併發數，談性能都是耍流氓。MySQL沒有限制單表最大記錄數，它取決於操做系統對文件大小的限制。

《阿里巴巴Java開發手冊》提出單錶行數超過500萬行或者單表容量超過2GB，才推薦分庫分表。性能由綜合因素決定，拋開業務複雜度，影響程度依次是硬件配置、MySQL配置、數據表設計、索引優化。500萬這個值僅供參考，並不是鐵律。 博主曾經操做過超過4億行數據的單表，分頁查詢最新的20條記錄耗時0.6秒，SQL語句大體是

prePageMinId是上一頁數據記錄的最小ID。 雖然當時查詢速度還湊合，隨着數據不斷增加，有朝一日一定不堪重負。分庫分表是個週期長而風險高的大活兒，應該儘量在當前結構上優化，好比升級硬件、遷移歷史數據等等，實在沒轍了再分。對分庫分表感興趣的同窗能夠閱讀分庫分表的基本思想。 最大併發數

併發數是指同一時刻數據庫能處理多少個請求，由max_connections和max_user_connections決定。max_connections是指MySQL實例的最大鏈接數，上限值是16384，max_user_connections是指每一個數據庫用戶的最大鏈接數。 MySQL會爲每一個鏈接提供緩衝區，意味着消耗更多的內存。若是鏈接數設置過高硬件吃不消，過低又不能充分利用硬件。通常要求二者比值超過10%，計算方法以下：

查看最大鏈接數與響應最大鏈接數：

在配置文件my.cnf中修改最大鏈接數

查詢耗時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個字符。 字段惟一性過低，增長索引沒有意義，如：是否刪除、性別。 合理使用覆蓋索引，以下所示：

login_name, nick_name兩個字段創建組合索引，比login_name簡單索引要更快。 SQL優化

分批處理

博主小時候看到魚塘挖開小口子放水，水面有各類漂浮物。浮萍和樹葉總能順利經過出水口，而樹枝會擋住其餘物體經過，有時還會卡住，須要人工清理。MySQL就是魚塘，最大併發數和網絡帶寬就是出水口，用戶SQL就是漂浮物。 不帶分頁參數的查詢或者影響大量數據的update和delete操做，都是樹枝，咱們要把它打散分批處理，舉例說明： 業務描述：更新用戶全部已過時的優惠券爲不可用狀態。 SQL語句：

若是大量優惠券須要更新爲不可用狀態，執行這條SQL可能會堵死其餘SQL，分批處理僞代碼以下：

操做符<>優化

一般<>操做符沒法使用索引，舉例以下，查詢金額不爲100元的訂單：

若是金額爲100的訂單極少，這種數據分佈嚴重不均的狀況下，有可能使用索引。鑑於這種不肯定性，採用union聚合搜索結果，改寫方法以下：

OR優化

在Innodb引擎下or沒法使用組合索引，好比：

OR沒法命中mobile_no + user_id的組合索引，可採用union，以下所示：

此時id和product_name字段都有索引，查詢才最高效。 IN優化

IN適合主表大子表小，EXIST適合主表小子表大。因爲查詢優化器的不斷升級，不少場景這二者性能差很少同樣了。 嘗試改成join查詢，舉例以下：

採用JOIN以下所示：

不作列運算

一般在查詢條件列運算會致使索引失效，以下所示： 查詢當日訂單

date_format函數會致使這個查詢沒法使用索引，改寫後：

避免Select all

若是不查詢表中全部的列，避免使用SELECT *，它會進行全表掃描，不能有效利用索引。 Like優化

like用於模糊查詢，舉個例子（field已創建索引）：

這個查詢未命中索引，換成下面的寫法：

去除了前面的%查詢將會命中索引，可是產品經理必定要先後模糊匹配呢？全文索引fulltext能夠嘗試一下，但Elasticsearch纔是終極武器。 Join優化

join的實現是採用Nested Loop Join算法，就是經過驅動表的結果集做爲基礎數據，經過該結數據做爲過濾條件到下一個表中循環查詢數據，而後合併結果。若是有多個join，則將前面的結果集做爲循環數據，再次到後一個表中查詢數據。 驅動表和被驅動表儘量增長查詢條件，知足ON的條件而少用Where，用小結果集驅動大結果集。 被驅動表的join字段上加上索引，沒法創建索引的時候，設置足夠的Join Buffer Size。 禁止join鏈接三個以上的表，嘗試增長冗餘字段。 Limit優化

limit用於分頁查詢時越日後翻性能越差，解決的原則：縮小掃描範圍，以下所示：

先篩選出ID縮小查詢範圍，寫法以下：

若是查詢條件僅有主鍵ID，寫法以下：

若是以上方案依然很慢呢？只好用遊標了，感興趣的朋友閱讀JDBC使用遊標實現分頁查詢的方法

其餘數據庫

做爲一名後端開發人員，務必精通做爲存儲核心的MySQL或SQL Server，也要積極關注NoSQL數據庫，他們已經足夠成熟並被普遍採用，能解決特定場景下的性能瓶頸。