關于SQL優(yōu)化的思路，一般都是使用執(zhí)行計劃看看是否用到了索引，主要可能有兩大類情況：

對業(yè)務字段建立了二級聯(lián)合索引，但是MySQL錯誤地覺得走主鍵聚族索引全表掃描效率更高，而沒有走二級索引

走二級索引，但是引起了幾萬、幾十萬的回表，此時還不如利用聚簇索引進行正序或者倒序的全表掃描，配合limit n，全表掃描只需要掃到符合條件的n條就停止

案例二：億級商品按類別/子類別查詢的SQL優(yōu)化-force index強制走某索引

也就是說這里的問題，

其實如果就算MySQL判斷走錯了索引，但是，因為只limit 10，如果能在全表掃描的過程中很快的就找到了滿足條件的10條元素，那么就能很快的截斷執(zhí)行流程并直接返回，從而避免對整張表一掃到底，結果還沒有湊齊滿足條件的10條元素

案例三：十億級評論表單商品幾十萬評論的深分頁問題-優(yōu)先主鍵全表掃描

案例四：千萬級數(shù)據(jù)刪除導致的慢查詢

???????

上面就是核心問題，就是每條數(shù)據(jù)都要去undo log中往前追溯，找屬于自己能看到的版本對應的數(shù)據(jù)，一條兩條可能速度不影響，如果上千萬的數(shù)據(jù)都是這種，那么就影響很大了