用過mysql的人肯定知道，mysql提供了原生的分頁功能-----limit關鍵字。limit 子句可以被用於強制 select 語句返回指定的記錄數。limit 接受乙個或兩個數字引數。引數必須是乙個整數常量。如果給定兩個引數，第乙個引數指定第乙個返回記錄行的偏移量，第二個引數指定返回記錄行的最大數目。tips：初始記錄行的偏移量是 0(而不是 1)。
但是我再實際的專案過程中使用limit子句時，在分頁數目很大的情況下(幾萬頁)，後面的翻頁的速度明顯慢於前面，特別好奇這個現象的原因，於是explain了一下，才發現mysql limit 10000, 20的意思掃瞄滿足條件的10020行，扔掉前面的10000行，返回最後的20行。如下所示：
explain select * from exp_platform order by id desc limit 10000,5
***************** 1. row **************
id: 1
select_type: ******
table: message
type: index
possible_keys: null
key: primary
key_len: 4
ref: null
rows: 10020
extra:
1 row in set (0.00 sec)
這相當於越往後面翻頁越相當於全表掃瞄，這樣在乙個高併發的應用下，效能肯定是hold不住的。但是limit n這樣的語句效能是沒有問題的，因為只掃瞄n行。於是就想找解決辦法，如下：
solution1:使用limit n
select * from exp_platform where id >= 9500 limit 5
solution2:使用子查詢
select * from exp_platform where id >= (select id from exp_platform order by id limit 10000, 1) limit 20
子查詢是在索引上完成的，而普通查詢是在資料檔案上完成的，通常來說，索引檔案要比資料檔案小很多，所以操作起來更有效
solution3:使用join分頁方式，這個沒有嘗試過，有機會可以試試。
實際可以利用類似策略模式的方式去處理分頁，比如判斷如果是一百頁以內，就使用最基本的分頁方式，大於一百頁，則使用子查詢的分頁方式。
mysql主鍵id不連續
唯一鍵衝突 事務回滾 批量插入時申請主鍵的策略造成mysql中自增主鍵不連續 批量申請自增主鍵時它的申請數量是乘2遞增的，比如插入4條資料，第一條申請1個主鍵 第二個申請2個滿足第二和三條資料插入時使用，第四條資料插入時還需要再申請一次，這次會分配4個主鍵，但是只用了1個，有3個就浪費了，並出現了i...
MySQL自增id不連續問題
專案中有一張表是記錄人員，在每個新使用者呼叫介面認證通過了之後，會有乙個往該錶插入這個新使用者資訊的操作。1 唯一鍵衝突是導致自增主鍵id不連續的第一種原因 2 事務回滾是導致自增主鍵id不連續的第二種原因 3 批量申請自增id的策略是導致自增主鍵id不連續的第三種原因 在這篇文章中提到了mysql...
mysql分頁概念 MySQL 分頁
分頁的基本原理 mysql explain select from message order by id desc limit 10000,20 1.row id 1 select type table message type index possible keys null key prima...