問題場景：
一開始在某個字段加了普通索引，SQL語句查找該字段范圍內的數據。
開始加索引的時候是能使用上索引的，但是過了幾天，數據量增大，發現檢索語句沒有走索引了
准備測試表
- 創建測試表
CREATE TABLE `test_index` (
`id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT ,
`name` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '' ,
`age` tinyint(5) UNSIGNED NOT NULL DEFAULT 0 ,
`status` tinyint(1) UNSIGNED NOT NULL DEFAULT 1 ,
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
)
- 在age字段上加普通索引
ALTER TABLE `test_index`
ADD INDEX `age` (`age`) USING BTREE
- 插入3條測試數據
insert into test_index(name,age,create_time) values('Tom',12,time()),('Tobie',20,time()),('Jack',15,time())
- test_index表數據結構
測試是否走索引（總記錄數total-t,結果數result-r）：
total = 3;
測試一（t=3,r=0,走索引）：
測試二（t=3,r=1,走索引）：
測試三（t=3,r=2,走索引）：
測試四（t=3,r=3,不走索引）：
新增7條測試數據：
total = 10;
測試一（t=10,r=0,走索引）：
測試二（t=10,r=4,走索引）：
測試三（t=10,r=5,不走索引）：
調整test_index表,在字段num上建普通索引，新增100條測試數據：
CREATE TABLE `test_index` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`num` int(10) unsigned NOT NULL DEFAULT '0',
`create_time` int(10) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `num` (`num`) USING BTREE
)
total=100
測試一（t=100,r=15,走索引）：
測試三（t=100,r=18,走索引）：
測試四（t=100,r=19,不走索引）：
測試數據增加到1000條：
total = 1000；
測試一(t=1000,r=100,走索引)：
測試二(t=1000,r=150,走索引)：
測試三(t=1000,r=170,走索引)：
測試四(t=1000,r=171,不走索引)：
測試數據增加到10000條：
total = 10000；
測試一（t=10000,r=1000,不走索引）：
測試二（t=10000,r=900,走索引）：
測試三（t=10000,r=940,走索引）：
測試四（t=10000,r=941,不走索引）：
total = 100000
測試一（t=100000,r=3948,走索引）：
測試二（t=10000,r=3949,不走索引）：
不嚴謹總結：
自己還測了更大的數據，發現betweet...and的使用與單純的數據量無關，而與查找到的數據與總數據的比有關。
當總數據量較小時，有很大概率會走索引，此時查到的結果數可以允許比較大
但總數據量比較大之后，查找到的結果數據越小時，越大概率使用上索引
也就是說，如果有10w的數據，而你需要查的數據為200條，此時是走索引的。
但是，如果你查到的結果有5000條，那么，極大可能是不走索引的
稍嚴謹一些的總結：
查詢數據時，如果走普通索引，那么會產生回表操作，因為普通索引屬於非聚集索引，葉子節點存放的是主鍵字段的值，拿到主鍵字段后再去表中根據主鍵值找到對應的記錄。
因此，當數據量很大，而查詢數據也很大時，考慮到回表的消耗，就不走索引；
當數據量很大，而查詢數據很小，這個時候比起全表掃描，回表的消耗相對少，所以走索引
注意點：測試時，表中的字段不應該全是索引字段，至少應該存在1個非索引字段
如果有什么不對的地方，歡迎評論區指出