效率分析關鍵詞：explain + SQL語句


一，最常見MYSQL最基本的分頁方式limit：

select * from `table` order by id desc limit 0, 20

在中小資料量的情況下，這樣的SQL足夠用了，唯一需要注意的問題就是確保使用了索引。隨著資料量的增加，頁數會越來越多,在資料慢慢增長的過程中，可能就會出現limit 10000,20這樣的情況，limit 10000,20的意思掃描滿足條件的10020行，扔掉前面的10000行，返回最後的20行，問題就在這裡，如果是limit 100000,100，需要掃描100100行，在一個高併發的應用裡，每次查詢需要掃描超過10W行，效能肯定大打折扣。

這種方式有幾個不足：較大的偏移(OFFSET)會增加結果集，小比例的低效分頁足夠產生磁碟I/O瓶頸，需要掃描的行多。

簡單的解決方法:不顯示記錄總數，沒使用者在乎這個數字;不讓使用者訪問頁數比較大的記錄，重定向他們;避免count(*) ,不顯示總數，讓使用者通過“下一頁”來翻頁 ,快取總數;單獨統計總數，在插入和刪除時遞增/遞減

二，第二種就是分表，計算HASH值。

Mysql分表準則
在大量使用mysql時，資料量大、高訪問時，為了提高效能需要分表處理，簡介下mysql分表的標準，後續會繼續補充

環境：
業務型別：OLTP
硬體：
cpu：8cpu 2.4GHZ
mem：48G
磁碟：raid5 6×sas

什麼樣的表需要拆分：根據表的體積、表的行數、訪問特點來衡量表是否需要拆分

一.拆分標準是：
  1.表的體積大於2G或行數大於1000w,以單表主鍵等簡單形式訪問資料，這個時候需要分表
  2.表的體積大於2G或行數大於500W,以兩表jion，小範圍查詢（結果集小100行）等形式訪問資料，這個時候需要分表
  3.表的體積大於2G或行數大於200w,以多表join，範圍查詢，order by，group by，高頻率等複雜形式訪問資料，尤其DML，這個時候需要分表
  4.表的欄位中含有text等大欄位的、varchar(500)以上的、很少使用的字元型欄位拆分成父子表,這種分表可以和以上聯合使用
  5.資料有時間過期特性的，需要做資料分表歸檔處理

只要達到上面任何一個標準，都需要做分表處理

二.分表方法：
  1.冷熱資料分表：適用小訪問量，冷資料很少使用
     1.1 單表字段很多，把頻繁使用整型欄位的和非頻繁使用的字元型欄位或大欄位拆到兩個表中
     1.2 表資料具有時間過期性，把過期資料拆分到歷史表裡或者按時間梯度分表
  2.橫向分表：適用大訪問量
     2.1 如雜湊等分切表或其他基於對某數字取餘的切表，優點是方便資料分佈，缺點是無法再擴充套件
     2.2 按主鍵id遞增分表，比如每100w個id一個分表，優點是方便擴充套件，缺點是壓力不均
     2.3 按日期分表，比如每天、每月、每年一個分表，優點是方便擴充套件，缺點是壓力不均

說明

1.表的體積如何預估

CREATE TABLE `td_skate` (
      `valid` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT '值id',
      `propertyid` BIGINT(20) NULL DEFAULT NULL COMMENT '屬性id',
      `text` VARCHAR(400) NULL DEFAULT NULL,
      `entext` VARCHAR(400) NULL DEFAULT NULL,
      `picurl` VARCHAR(200) NULL DEFAULT NULL COMMENT '屬性值說明圖片，儲存圖片相對地址',
      `isother` BIGINT(20) NULL DEFAULT NULL COMMENT '是否是other值， 0  否  1  是',
      `createtime` DATETIME NULL DEFAULT NULL COMMENT '建立時間',
      `createuser` BIGINT(20) NULL DEFAULT NULL COMMENT '建立使用者',
      `lastmodify` DATETIME NULL DEFAULT NULL COMMENT '最後修改時間',
      `updatetimeuser` BIGINT(20) NULL DEFAULT NULL COMMENT '最後修改人',
      `deletetime` DATETIME NULL DEFAULT NULL COMMENT '刪除時間',
      `deleteuser` BIGINT(20) NULL DEFAULT NULL COMMENT '刪除人',
      `description` VARCHAR(4000) NULL DEFAULT NULL COMMENT '產品描述',
      `isdelete` INT(11) NULL DEFAULT '0',
      PRIMARY KEY (`valid`),
      INDEX `fk_td_prodline_attrval_td_prodline_attr` (`propertyid`),
      CONSTRAINT `fk_td_prodline_attrval_td_prodline_attr` FOREIGN KEY (`propertyid`) REFERENCES `td_prodline_attr` (`propertyid`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=2491650;
 

把表的所有欄位佔用位元組數相加，再乘以預估行數就是表的體積，比如上面的表，預估有1000W，那他的體積是
（8+8+400+400+200+8+8+8+8+8+8+8+4000+8）×10000000=50.8G，可以看到這個表設計非常不合理，可以修改如下：
int替代bigint
timestamp替代datetime
狀態位isdelete用tinyint替代
根據業務特點看能否把varchar(4000)放到一個字表中
優化後表大小：（4+4+400+400+200+4+4+4+4+4+4+4+1）×10000000=10.37G，如果要進一步提升效能，需要刪除外來鍵，分表，保證單表在2G以下。
如果需要檢視description資訊，通過主鍵關聯檢視子表，只會掃描有效的子表資訊， 效能將會提升非常大。  


2.表的行數預估就很簡單，根據業務特點，訪問量等預估.


三，第三種是偏移：

SELECT * FROM `table` WHERE id <= (SELECT id FROM `table` ORDER BY id desc LIMIT ".($page-1)*$pagesize.", 1) ORDER BY id desc LIMIT $pagesize
 

或者

select * FROM `table` AS t1 JOIN (SELECT id FROM `table` ORDER BY id desc LIMIT 900,1) AS t2 WHERE t1.id<=t2.id order by t1.id desc limit 5

原理就是記錄住當前頁id的最大值和最小值，計算跳轉頁面和當前頁相對偏移，由於頁面相近，這個偏移量不會很大，這樣的話m值相對較小，大大減少掃 描的行數。其實傳統的limit m,n，相對的偏移一直是第一頁，這樣的話越翻到後面，效率越差，而上面給出的方法就沒有這樣的問題。
比如還是SELECT * FROM `table` ORDER BY id DESC，按id降序分頁，每頁20條，當前是第10頁，當前頁條目id最大的是9527，最小的是9500，如果我們只提供”上一頁”、”下一頁”這樣 的跳轉（不提供到第N頁的跳轉），那麼在處理”上一頁”的時候SQL語句可以是：

SELECT * FROM `table` WHERE id > 9527 ORDER BY id  ASC LIMIT 20;
 

處理”下一頁”的時候SQL語句可以是：

SELECT * FROM `table` WHERE id < 9500 ORDER BY id  DESC LIMIT 20;

不管翻多少頁，每次查詢只掃描20行。
缺點是隻能提供”上一頁”、”下一頁”的連結形式，但是我一般來說非常喜歡”<上一頁 1 2 3 4 5 6 7 8 9 下一頁>”這樣的連結方式，怎麼辦呢？
如果LIMIT m,n不可避免的話，要優化效率，只有儘可能的讓m小一下，我們擴充套件前面做法，還是SELECT * FROM `table` ORDER BY id DESC，按id降序分頁，每頁20條，當前是第10頁，當前頁條目id最大的是9527，最小的是9500，比如要跳到第8頁，我看的SQL語句可以這 樣寫：

SELECT * FROM `table` WHERE id > 9527 ORDER BY id ASC LIMIT 20,20;

跳轉到第13頁：

SELECT * FROM `table` WHERE id < 9500 ORDER BY id DESC LIMIT 40,20;

注意SQL語句裡面的ASC和DESC，如果是ASC取出來的結果，顯示的時候記得倒置一下。
整體來說在面對百萬級資料的時候如果使用上面第三種方法來優化，系統性能上是能夠得到很好的提升，在遇到複雜的查詢時也儘量簡化，減少運算量。 同時也儘量多的使用記憶體快取，有條件的可以考慮分表、分庫、陣列之類的大型解決方案了。