mysql索引优化问题

linjia828

上面的sql，如果建一个(summonerName ,userId )的索引是可以用到，查询时间从4.9s降到3.5s，但是查询的时候占用cpu使用率都是10%左右。

是不是数据库本身哪里设置有问题了，这样的一个语句占用这么大的cpu是个很大的问题的。

加上复合索引以后的执行计划：
mysql> explain select summonerName from lmo_player where 1 and userId = 34533051;  
+----+-------------+------------+-------+---------------+--------+---------+------+---------+--------------------------+
| id | select_type | table      | type  | possible_keys | key    | key_len | ref  | rows    | Extra                    |
+----+-------------+------------+-------+---------------+--------+---------+------+---------+--------------------------+
|  1 | SIMPLE      | lmo_player | index | userId        | userId | 768     | NULL | 4756048 | Using where; Using index |
+----+-------------+------------+-------+---------------+--------+---------+------+---------+--------------------------+

wanan_YLF

索引应该建userId，ummonerName吧？
而且是不是结果集很大啊？

linjia828

原帖由 wanan_YLF 于 2011-6-15 13:39 发表
索引应该建userId，ummonerName吧？
而且是不是结果集很大啊？

上面的sql，如果建一个(summonerName ,userId )的索引是可以用到，查询时间从4.9s降到3.5s，但是查询的时候占用cpu使用率都是10%左右。

是不是数据库本身哪里设置有问题了，这样的一个语句占用这么大的cpu是个很大的问题的。

加上复合索引以后的执行计划：
mysql> explain select summonerName from lmo_player where 1 and userId = 34533051;  
+----+-------------+------------+-------+---------------+--------+---------+------+---------+--------------------------+
| id | select_type | table      | type  | possible_keys | key    | key_len | ref  | rows    | Extra                    |
+----+-------------+------------+-------+---------------+--------+---------+------+---------+--------------------------+
|  1 | SIMPLE      | lmo_player | index | userId        | userId | 768     | NULL | 4756048 | Using where; Using index |
+----+-------------+------------+-------+---------------+--------+---------+------+---------+--------------------------+

wanan_YLF

额...可以用到是没错，可两个索引的执行计划是不一样的啊。全覆盖索引也不是这样用啊...
另外，我怀疑在这张表中userId = 34533051的结果集很大...

[ 本帖最后由 wanan_YLF 于 2011-6-15 14:24 编辑 ]

linjia828

原帖由 wanan_YLF 于 2011-6-15 14:12 发表
额...可以用到是没错，可两个索引的执行计划是不一样的啊。全覆盖索引也不是这样用啊...
另外，我怀疑在这张表中userId = 34533051的结果集很大...

结果集只有80条...

wanan_YLF

额...那怎么会不走userid这个索引...奇怪...
另外那个复合索引改掉的话，type类型是否会变为ref？

linjia828

mysql> explain select skinName, avg(`largest_critcal_strike`) as val, count(id) as times from lmo_player where 1 and YEARWEEK(lmo_player.creationTime,1) = YEARWEEK(now(),1) group by skinName;
+----+-------------+------------+------+---------------+------+---------+------+---------+----------------------------------------------+
| id | select_type | table      | type | possible_keys | key  | key_len | ref  | rows    | Extra                                        |
+----+-------------+------------+------+---------------+------+---------+------+---------+----------------------------------------------+
|  1 | SIMPLE      | lmo_player | ALL  | NULL          | NULL | NULL    | NULL | 4803138 | Using where; Using temporary; Using filesort |
+----+-------------+------------+------+---------------+------+---------+------+---------+----------------------------------------------+


另外这句改如何优化索引呢？lmo_player.creationTime是日期型，有人说改成字符型，然后 YEARWEEK(date(lmo_player.creationTime))这样会更优，可以走索引，是吗？

〇〇

where 1 and ?