mysql索引没起效

[哎呦喂哈]

status列上建了索引

EXPLAIN
SELECT * FROM sms_send_real_log_hisdata_20150801 WHERE STATUS = '1'

查询出索引无效是啥原因



status是状态列，里面的值都是0和1

[LongRui888]

用不用索引其中有一个因素就是 条件的选择性。 比如你有100w条记录，status = 1的有 60w，status = 0的有40w 那么你的语句就不会用索引，为什么呢？ 因为mysql的优化器会判断用索引和不用索引的开销，发现用了索引开销更大，所以就不用了。

[LongRui888]

另外，就是主要数据类型： SELECT * FROM sms_send_real_log_hisdata_20150801 WHERE STATUS = '1' 那么status最好是 文本型的，如果是数值型的话，可能会用不上索引。

[哎呦喂哈]

引用 1 楼 yupeigu 的回复:

用不用索引其中有一个因素就是 条件的选择性。
比如你有100w条记录，status = 1的有 60w，status = 0的有40w
那么你的语句就不会用索引，为什么呢？
因为mysql的优化器会判断用索引和不用索引的开销，发现用了索引开销更大，所以就不用了。

这样啊

那我这样建的索引岂不是status也不起作用了么
主要用这三列做group by的

SELECT SUM(sms_num),username,STATUS,sms_type FROM sms_send_real_log_hisdata_201508
GROUP BY username,STATUS,sms_type

[LongRui888]

引用 3 楼 caolong0210 的回复:

[quote=引用 1 楼 yupeigu 的回复:] 用不用索引其中有一个因素就是 条件的选择性。 比如你有100w条记录，status = 1的有 60w，status = 0的有40w 那么你的语句就不会用索引，为什么呢？ 因为mysql的优化器会判断用索引和不用索引的开销，发现用了索引开销更大，所以就不用了。

这样啊 那我这样建的索引岂不是status也不起作用了么 主要用这三列做group by的

SELECT SUM(sms_num),username,STATUS,sms_type FROM sms_send_real_log_hisdata_201508
GROUP BY username,STATUS,sms_type

[/quote] 那就应该4列建索引： username,STATUS,sms_type, sms_num 这样的好处是 数据已经排序了，直接从索引访问数据就可以了，不需要再去访问表

[ACMAIN_CHM]

以文本方式贴出 explain select ... show index from .. 以供分析。

[九月茅桃]

可能表数据量太少了，所以simple类型后，直接全表扫描了。

[哎呦喂哈]

引用 4 楼 yupeigu 的回复:

那就应该4列建索引：

username,STATUS,sms_type, sms_num

这样的好处是 数据已经排序了，直接从索引访问数据就可以了，不需要再去访问表

EXPLAIN
SELECT SUM(sms_num),STATUS,username,sms_type FROM sms_send_real_log_hisdata_201508
GROUP BY sms_type,STATUS,username

显示已使用索引

SELECT SUM(sms_num),STATUS,username,sms_type FROM sms_send_real_log_hisdata_201508
GROUP BY sms_type,STATUS,username

sql语句执行速度没上去是为啥。。

[LongRui888]

引用 6 楼 caolong0210 的回复:

[quote=引用 4 楼 yupeigu 的回复:] 那就应该4列建索引： username,STATUS,sms_type, sms_num 这样的好处是 数据已经排序了，直接从索引访问数据就可以了，不需要再去访问表

EXPLAIN
SELECT SUM(sms_num),STATUS,username,sms_type FROM sms_send_real_log_hisdata_201508
GROUP BY sms_type,STATUS,username

显示已使用索引

SELECT SUM(sms_num),STATUS,username,sms_type FROM sms_send_real_log_hisdata_201508
GROUP BY sms_type,STATUS,username

sql语句执行速度没上去是为啥。。[/quote] 其实正在要让查询快，索引的作用有效。 一般在oltp系统中，比如淘宝的交易系统，之所以速度挺快，原因是因为 都是对少量数据的操作，不管是更新、查询，这种场景下，索引就能起作用。 而你现在的是没有过滤条件，是整个表的所有数据，虽然建了索引，但也是对索引进行扫描，效率不会有太大的提升，这种就是索引作用不到的情况。

[LongRui888]

你的这种情况，如果你还需要进一步提升性能，可以考虑 先把数据结存到一个表里，然后查的时候，直接查，你可以看看 mysql性能优化 这本书，里面有很多 设计 上的改进。 其实性能的优化，不仅仅是索引，索引有时候能起到的作用还是很有限的，还是需要在 设计上 做改进。

[哎呦喂哈]

引用 7 楼 yupeigu 的回复:

其实正在要让查询快，索引的作用有效。 一般在oltp系统中，比如淘宝的交易系统，之所以速度挺快，原因是因为 都是对少量数据的操作，不管是更新、查询，这种场景下，索引就能起作用。 而你现在的是没有过滤条件，是整个表的所有数据，虽然建了索引，但也是对索引进行扫描，效率不会有太大的提升，这种就是索引作用不到的情况。

好吧、

SELECT SUM(sms_num),username,STATUS,sms_type FROM sms_send_real_log_hisdata_201508
WHERE send_time >'2015-08-01' AND send_time < '20150831'
GROUP BY username,STATUS, sms_type

你看我这种情况应该如何加索引

[LongRui888]

引用 9 楼 caolong0210 的回复:

[quote=引用 7 楼 yupeigu 的回复:] 其实正在要让查询快，索引的作用有效。 一般在oltp系统中，比如淘宝的交易系统，之所以速度挺快，原因是因为 都是对少量数据的操作，不管是更新、查询，这种场景下，索引就能起作用。 而你现在的是没有过滤条件，是整个表的所有数据，虽然建了索引，但也是对索引进行扫描，效率不会有太大的提升，这种就是索引作用不到的情况。

好吧、

SELECT SUM(sms_num),username,STATUS,sms_type FROM sms_send_real_log_hisdata_201508
WHERE send_time >'2015-08-01' AND send_time < '20150831'
GROUP BY username,STATUS, sms_type

你看我这种情况应该如何加索引[/quote] 把 send_time字段加在第一个位置： send_time,username,STATUS, sms_type 你这个是 date类型的吗，不是字符串类型吧

[哎呦喂哈]

引用 10 楼 yupeigu 的回复:

把 send_time字段加在第一个位置： send_time,username,STATUS, sms_type 你这个是 date类型的吗，不是字符串类型吧

是data类型。我先试试这个

[Rotel-刘志东]

直接走了全表扫描了