寫一手好SQL頗有必要

時間  2019-11-12
標籤 一手 sql 頗有 必要 欄目 SQL 简体版
原文   原文鏈接

  博主負責的項目主要採用阿里雲數據庫MySQL，最近頻繁出現慢SQL告警，執行時間最長的居然高達5分鐘。導出日誌後分析，主要緣由居然是沒有命中索引和沒有分頁處理。其實這是很是低級的錯誤，我不由後背一涼，團隊成員的技術水平亟待提升啊。改造這些SQL的過程當中，總結了一些經驗分享給你們，若是有錯誤歡迎批評指正。html

MySQL性能

最大數據量

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

文件系統 單文件大小限制
FAT32 最大4G
NTFS 最大64GB
NTFS5.0 最大2TB
EXT2 塊大小爲1024字節，文件最大容量16GB；塊大小爲4096字節，文件最大容量2TB
EXT3 塊大小爲4KB，文件最大容量爲4TB
EXT4 理論能夠大於16TB

《阿里巴巴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。雖然當時查詢速度還湊合，隨着數據不斷增加，有朝一日一定不堪重負。分庫分表是個週期長而風險高的大活兒，應該儘量在當前結構上優化，好比升級硬件、遷移歷史數據等等，實在沒轍了再分。對分庫分表感興趣的同窗能夠閱讀分庫分表的基本思想。redis

最大併發數

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

max_used_connections / max_connections * 100% = 3/100 *100% ≈ 3%

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

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的處理時間。apache

實施原則

  相比NoSQL數據庫，MySQL是個嬌氣脆弱的傢伙。它就像體育課上的女同窗，一點糾紛就和同窗鬧彆扭(擴容難)，跑兩步就氣喘吁吁(容量小併發低)，經常身體不適要請假(SQL約束太多)。現在你們都會搞點分佈式，應用程序擴容比數據庫要容易得多，因此實施原則是數據庫少幹活，應用程序多幹活。後端

  • 充分利用但不濫用索引，須知索引也消耗磁盤和CPU。
  • 不推薦使用數據庫函數格式化數據，交給應用程序處理。
  • 不推薦使用外鍵約束，用應用程序保證數據準確性。
  • 寫多讀少的場景，不推薦使用惟一索引，用應用程序保證惟一性。
  • 適當冗餘字段，嘗試建立中間表，用應用程序計算中間結果，用空間換時間。
  • 不容許執行極度耗時的事務，配合應用程序拆分紅更小的事務。
  • 預估重要數據表（好比訂單表）的負載和數據增加態勢，提早優化。

數據表設計

數據類型

  數據類型的選擇原則：更簡單或者佔用空間更小。緩存

  • 若是長度可以知足，整型儘可能使用tinyint、smallint、medium_int而非int。
  • 若是字符串長度肯定，採用char類型。
  • 若是varchar可以知足，不採用text類型。
  • 精度要求較高的使用decimal類型，也可使用BIGINT，好比精確兩位小數就乘以100後保存。
  • 儘可能採用timestamp而非datetime。
類型 佔據字節 描述
datetime 8字節 '1000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.999999
timestamp 4字節 '1970-01-01 00:00:01.000000' to '2038-01-19 03:14:07.999999'

相比datetime，timestamp佔用更少的空間，以UTC的格式儲存自動轉換時區。網絡

避免空值

  MySQL中字段爲NULL時依然佔用空間，會使索引、索引統計更加複雜。從NULL值更新到非NULL沒法作到原地更新，容易發生索引分裂影響性能。儘量將NULL值用有意義的值代替，也能避免SQL語句裏面包含is not null的判斷。

text類型優化

  因爲text字段儲存大量數據，表容量會很早漲上去，影響其餘字段的查詢性能。建議抽取出來放在子表裏，用業務主鍵關聯。

索引優化

索引分類

  1. 普通索引：最基本的索引。
  2. 組合索引：多個字段上創建的索引，可以加速複合查詢條件的檢索。
  3. 惟一索引：與普通索引相似，但索引列的值必須惟一，容許有空值。
  4. 組合惟一索引：列值的組合必須惟一。
  5. 主鍵索引：特殊的惟一索引，用於惟一標識數據表中的某一條記錄，不容許有空值，通常用primary key約束。
  6. 全文索引：用於海量文本的查詢，MySQL5.6以後的InnoDB和MyISAM均支持全文索引。因爲查詢精度以及擴展性不佳，更多的企業選擇Elasticsearch。

索引優化

  1. 分頁查詢很重要，若是查詢數據量超過30%，MYSQL不會使用索引。
  2. 單表索引數不超過5個、單個索引字段數不超過5個。
  3. 字符串可以使用前綴索引，前綴長度控制在5-8個字符。
  4. 字段惟一性過低，增長索引沒有意義，如：是否刪除、性別。
  5. 合理使用覆蓋索引，以下所示：
select login_name, nick_name from member where login_name = ?

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

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<Integer> batchIdList = queryList('select id FROM `coupon` WHERE expire_date <= #{currentDate} and status = 1 limit #{(pageNo-1) * PAGE_SIZE},#{PAGE_SIZE}');
    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優化

  1. IN適合主表大子表小，EXIST適合主表小子表大。因爲查詢優化器的不斷升級，不少場景這二者性能差很少同樣了。
  2. 嘗試改成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，則將前面的結果集做爲循環數據，再次到後一個表中查詢數據。

  1. 驅動表和被驅動表儘量增長查詢條件，知足ON的條件而少用Where，用小結果集驅動大結果集。
  2. 被驅動表的join字段上加上索引，沒法創建索引的時候，設置足夠的Join Buffer Size。
  3. 禁止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數據庫，他們已經足夠成熟並被普遍採用，能解決特定場景下的性能瓶頸。

分類 數據庫 特性
鍵值型 Memcache 用於內容緩存，大量數據的高訪問負載
鍵值型 Redis 用於內容緩存，比Memcache支持更多的數據類型，並能持久化數據
列式存儲 HBase Hadoop體系的核心數據庫，海量結構化數據存儲，大數據必備。
文檔型 MongoDb 知名文檔型數據庫，也能夠用於緩存
文檔型 CouchDB Apache的開源項目，專一於易用性，支持REST API
文檔型 SequoiaDB 國內知名文檔型數據庫
圖形 Neo4J 用於社交網絡構建關係圖譜，推薦系統等

參考(部分摘抄的文字版權屬於原做者)：

https://www.jianshu.com/p/6864abb4d885

雞湯：你既然已經作出了選擇，又何須去問爲何選擇。 ——衛莊

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程