## 背景 生產上有個導報表功能，工作了很長一段時間一直都很穩，沒出現過什麼問題，最近運營同學突然反饋導出來的數據和實際的對不上，經過排查發現導出的數據有重覆，也有的沒導出來。 由於我們提前生成好數據（每天會truncate重新生成），所以導出的邏輯非常簡單，不需要關聯很多表撈數據，只需要從一張表查 ...
背景
生產上有個導報表功能，工作了很長一段時間一直都很穩，沒出現過什麼問題，最近運營同學突然反饋導出來的數據和實際的對不上，經過排查發現導出的數據有重覆，也有的沒導出來。
由於我們提前生成好數據（每天會truncate重新生成），所以導出的邏輯非常簡單，不需要關聯很多表撈數據，只需要從一張表查即可，這個表的數據量不大，發生問題時7800條左右，查詢的sql也非常簡單，可以選擇條件導出知道時間段的數據，如下：
SELECT * FROM t_report WHERE repayment_time > 1622390400000 AND repayment_time <= 1624032000000 limit 1000,1000
為了防止一次性導出太多數據，所以我們做了分頁，每次查1000條，並且repayment_time欄位上建了索引。
經過一頓排查後，發現程式沒啥問題，但數據也確實是重覆了，也漏了一些...
分析
我們對比了實際數據，確實有問題，有的數據出現兩次，有的沒出現。如下：
有一條數據在第6頁查出，在第8頁又被查出。我們再次確認了程式，還是沒問題，用arthas觀察了分頁的入參也都是正確的。
那麼直接拿sql出來到資料庫查詢呢？發現真有問題...，確實在第6頁和第8頁出現。那麼可以確定就是sql有問題了，這麼簡單的sql查數據居然重覆了...
仔細看數據可以發現，在第6頁的時候，查出來的數據是按照repayment_time欄位排序，而第8頁則是按照id進行排序，排序方式不同分頁查出來的數據肯定會不同。
問題已經定位到，就是在分頁過程中，mysql偷偷改了排序的規則。我們可以看不同頁的執行計劃如下，由於每天生成的數據不同，這裡我改了頁數。
那麼同樣的sql為什麼會使用不同的排序，生成不同的執行計劃呢？
我們知道mysql在使用索引的時候，是會根據數據的分佈進行的，也就是mysql會考慮索引的效果，如果效果好才使用。我們常說性別欄位不適合建索引，就是因為這種欄位的區分度很低，mysql寧願全表掃描也不會使用這種索引。使用show index from table可以查看索引信息，cardinality就是欄位的區分度，通常該值越大越適合建索引。
我們說到mysql會考慮到數據的分佈，雖然我們上面的repayment_time欄位是建索引，運營當時的查詢條件剛好覆蓋了整個表的數據，當翻到第8頁時，整個表總共也就8頁，就是要查全部數據了，mysql此時會放棄使用索引，進行全表掃描。
前面的頁使用到索引，預設會根據索引欄位進行排序，而後面頁沒使用索引，預設就是根據id進行排序。
不一定是最後一頁才生成不同的執行計劃，比如我們的表有10w條數據，可能查到95000條數據的時候，排序就變了，也就是說mysql認為幾乎要查全部數據，就會改變執行計劃。
解決方式也很簡單，我們可以顯示指定排序方式，這樣每次生成的執行計劃都是一樣的，如上的sql，改為：
SELECT * FROM t_report WHERE repayment_time > 1622390400000 AND repayment_time <= 1624032000000 order by repayment_time,id limit 1000,1000
註意加了order by需要考慮file sort問題，排序欄位沒有使用索引可能會導致性能問題。
分頁寫法開發有時候很容易漏掉order by，這種最好在需求階段就和產品確認清楚，這樣可以在開發和測試階段就通過數據驗證需求，當然開發也要考慮數據分佈，比如數據量，有多少重覆數據等，以後記得這個坑，避免再次掉入哦。
更多分享，歡迎關註我的github：https://github.com/jmilktea/jtea
