有個200多萬的使用者表，顯示列表時非常慢，查了一下原來使用了limit進行分頁。
前幾頁用時很少
但是後面頁數就簡直不可忍了，實際的業務邏輯還有排序，就更慢了
試試用查詢時用帶索引的鍵來確定範圍。
最大的id是103948598
時間和用limit比相差幾千倍啊！
使用explain 檢視一下
mysql> explain select * from users limit 2000000,50;
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra |
| 1 | ****** | users | all | null | null | null | null | 2839456 | |
1 row in set
mysql> explain select * from users where uid <= 103948598 and uid > 103948598 -50;
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra |
| 1 | ****** | users | range | primary | primary | 8 | null | 98 | using where |
1 row in set
可以看到 limit是掃瞄了所有行，再按照需要返回指定範圍的行，而使用uid時僅僅是掃瞄了指定範圍的行。
所以用uid來確定範圍就很穩定，而limit時，隨著頁數變大，就變的很慢了。
另外還可以使用快取來優化，請見redispage
mysql 分頁優化 Mysql 查詢分頁優化
全表掃瞄，速度極慢 limit 語句的查詢時間與起始記錄的位置成正比 mysql 的 limit 語句是很方便，但是對記錄很多的表並不適合直接使用 建立測試表 drop table if exists t user create table test t user id int 10 unsigne...
mysql 分頁優化 MySQL分頁優化實驗與總結
前言 分頁的sql優化是日常開發中經常遇到的問題，筆者在此做乙個經驗總結，並附上相應的實驗過程。實驗準備 若不想親自實驗的，可以直接跳過這一節。但還是建議大家做一下實驗，眼見為實。1.安裝測試資料庫 本次實驗使用的資料是mysql官方提供的employee資料庫，mysql官方提供了一些測試資料庫，...
mysql巢狀分頁 MySQL分頁優化
最近，幫同事重寫了乙個mysql sql語句，該sql語句涉及兩張表，其中一張表是字典表 需返回乙個字段 另一張表是業務表 本身就有150個字段，需全部返回 當然，欄位的個數是否合理在這裡不予評價。平時，返回的資料大概5w左右，系統尚能收到資料。但12月31日那天，資料量大概20w，導致sql執行時...