SELECT * FROM t_user WHERE email='217@xxg.com'; --1.725 --加email索引之后 0.003
SELECT * FROM t_user WHERE email='316@xxg.com' LIMIT 1; 0.001 --加email索引之后 0.002
結論：用戶數據量很大的情況下 如果查詢加了limit 無索引 根據唯一列查詢 加索引和不加索引 查詢差距不大 會走主鍵 聚集索引 只要到上千萬或是上億的數據的時候才會有影響
盡量用戶唯一的字段查詢會很快
--按時間降序全表查詢 不加limit
SELECT * FROM t_user order by create_time desc --11.184
SELECT * FROM t_user order by create_time desc limit 1,10 --加limit 2.144
結論：在500萬測試數據,沒有時間索引的況下，直接order by create_time 會全表掃描 不建議如此寫會拖垮數據庫 必須用到降序的時候一定加上limit 限制返回條數
--創建create_time 索引之后
SELECT * FROM t_user order by create_time desc --11.156
SELECT * FROM t_user order by create_time desc limit 1,10 0.002
結論：創建create_time 時間索引 但是 直接order_by 時間 還是會導致全表掃描,加不加索引沒用，所以必須加上limit 受影響行數 才會走索引 explain SELECT * FROM t_user order by create_time desc limit 1,10 0.002 語句加 explain 查看是否走索引