| root@127.0.0.1 : sitevipdb 09:24:53> alter table game_shares_buy_list add index ind_game_shares_buy_list_price(price); Query OK, 0 rows affected (5.79 sec) |
可以看到优化器虽然注意到了我们新加的索引，但是最终还是选择了primary来扫描；
所以这个时候我们加上去的索引没有产生效果，数据库负载依然很高，如果强制走price上的索引，效果会这样：
| root@127.0.0.1 : sitevipdb 09:35:38> SELECT * FROM `sitevipdb`.`game_shares_buy_list` WHERE price>='2.0′ ORDER BY tran_id DESC LIMIT 10; 。。。。。 10 rows in set (7.06 sec) root@127.0.0.1 : sitevipdb 09:36:00> SELECT * FROM `sitevipdb`.`game_shares_buy_list` force index(ind_game_shares_buy_list_price) WHERE price>='2.0′ ORDER BY tran_id DESC LIMIT 10; 。。。。 10 rows in set (1.01 sec) |
可以看到如果强制走索引，时间已经明显下降了，但是还是有些慢，能不能在快一点？其实我们需要扫描的记录只有10条，但查询在取得这10条记录的时候需要扫描大量无效的记录
怎么降低这个数据：其实只要改写一下sql就可以，我们先从索引中得到满足条件的10个id，在回表进行关联：
| root@127.0.0.1 : sitevipdb 09:44:45> select * from game_shares_buy_list t1, -> ( SELECT tran_id FROM sitevipdb.game_shares_buy_list WHERE price>='2.0′ ORDER BY tran_id DESC LIMIT 10) t2 -> where t1.tran_id=t2.tran_id; 10 rows in set (0.00 sec) |
可以看到执行时间已经不在秒级别了，和客户电话沟通后，很愿意这样改写sql。
—这里看到是order by tran_id是要额外排序的，索引也可以这样来建立消除排序(tran_id,price)这样可以消除排序，同时可以利用order by desc/asc +limit M,N的优化。
优化点二：
| CREATE TABLE `game_session` ( `session_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT , `session_expires` int(10) unsigned NOT NULL DEFAULT '0′, `client_ip` varchar(16) DEFAULT NULL, `session_data` text, ……………………. PRIMARY KEY (`session_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; |
查询为select `session_data`, `session_expires` from `game_session` where session_id='xxx'出现大量等待情况
同时该表的insert，也有等待的现象；
可以看到这个表结构设计是有些问题的，咨询了客户后，可以改为下面结构：
