在傳統的分頁思路影響下，很多人都形成了對於分頁的固定理解，也就是給出select語句，先用count()函式計算出總的條目，除與每個頁面大小pagesize，然後用ceil取整，得出總的頁數，用limit去查詢每一頁的結果。
這種做法的確帶來了很多好處，它可以讓前端馬上知道查詢的總記錄數，並且馬上可以計算出頁碼和總頁數。事實上這樣的做法在表的記錄較少的情況下尚可，一旦行數超過一定的數量，查詢效能會下降得非常厲害，原因在於count()和limit的查詢方式。
count()的作用是統計表的記錄數，理想情況下的count()並不慢，例如select count(*) from `table`這樣的查詢是非常快的，因為沒有任何查詢條件的count() mysql引擎會直接呼叫表明細的總記錄值，無需直接地對錶進行查詢，但是一旦帶上條件，例如select count(*) from `table` where `id` <> 1，哪怕是提供很小的條件，也會改變mysql對count()的查詢機制，這時引擎無法確定哪些記錄是小於1，哪些記錄是1，只能進行全表掃瞄，這是乙個很耗時的過程，即使語句觸發了索引，在百萬級別的表上都會耗時超過0.2秒，最糟糕的情況是如果沒有觸發索引，將會達到2-3秒的查詢耗時。
優化count()，
第一種，自然是最簡便的盡量在設計資料庫的時候避免帶條件的count()語句。
第二種，根據主鍵id去減少全表掃瞄的行，例如某錶有100000條記錄，select count(*) from `table` where `id` > 90000 and `type` = 2這樣的語句只會從第90000條記錄開始掃瞄後面剩下的10000條記錄，速度會快上很多，同理，select count(*) from `table` where `id` < 10000 and `type` = 2語句只會掃瞄前面10000的記錄.
優化limit，
第一種，用between and 代替limit
第二種，取消offset值，像select count(*) from `table` limit 12000,10這樣的語句可以用select count(*) from `table` where `id`>12000 limit 10去代替。
mysql的分頁優化 mysql分頁優化
有個200多萬的使用者表，顯示列表時非常慢，查了一下原來使用了limit進行分頁。前幾頁用時很少 但是後面頁數就簡直不可忍了，實際的業務邏輯還有排序，就更慢了 試試用查詢時用帶索引的鍵來確定範圍。最大的id是103948598 時間和用limit比相差幾千倍啊！使用explain 檢視一下 mysq...
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官方提供了一些測試資料庫，...