开发一个小应用,用户可以提出问题,等待其他人来回答,进而可以互相交流,用户也能一定概率收到别人提出都问题。mysql数据库设计时将提出的问题和回答消息都放在了一张表格里(比较失败),在程序中需要查询当前未读消息和问题,使用了嵌套查询语句进行查询。刚开始时没有问题,但是过了大概1个月左右,应用变得非常慢,以为是数据库表格数据太大,通过查询,表格才4000多数据,于是通过日志进行了分析。
Processing FloaterController#get_params (for 112.95.145.186 at 2011-04-14 17:12:50) [GET]
Session ID: BAh7CToOcmV0dXJuX3RvMDoMY3NyZl9pZCIlNTZiZTFkNWQyMmFhODI5NTU5
MTY1YmZhYWU4MWY1OTEiCmZsYXNoSUM6J0FjdGlvbkNvbnRyb2xsZXI6OkZs
YXNoOjpGbGFzaEhhc2h7AAY6CkB1c2VkewA6DHVzZXJfaWRpAln3--76893a47ec732df5617b5d1d70215e0b5b6df515
Parameters: {"action"=>"get_params", "controller"=>"floater", "isGetMessage"=>"1"}
Completed in 24.57103 (0 reqs/sec) | Rendering: 0.00021 (0%) | DB: 24.55177 (99%) | 200 OK [http://www.baicao.cc/floater/get_params?isGetMessage=1]
这个查询居然要24.57秒,于是把数据库导入本地进行debug日志分析,发现是下面两条数据库语句执行非常耗时
mysql> SELECT count(*) AS count_all FROM `floater_messages` WHERE ((owner_id=42926 and reply_to_id=0) or id in(select max(id) from floater_messages where owner_id=42926 and reply_to_id > 0 group by reply_to_id));
+-----------+
| count_all |
+-----------+
| 25 |
+-----------+
1 row in set ([color=red]7.39[/color] sec)
mysql> SELECT * FROM `floater_messages` WHERE ((owner_id=42926 and reply_to_id=0 and readed=0) or id in(select max(id) from floater_messages where owner_id=42926 and reply_to_id > 0 and readed=0 group by reply_to_id)) LIMIT 10;
Empty set ([color=red]9.82 sec[/color])
对于这样的问题,可以有一下两种方法解决:
1.将嵌套语句拆开查询,多次查询的结果通过自己写程序合并。这种方法适合于出了问题以后应急,写完的代码不优雅,尤其在优雅的rails上,所以问题规避了以后,另外找时间找办法彻底解决问题。
2.如果数据关系复杂,就分几张表存储。千万不可将本来关系复杂的数据存于一张表,这样在数据量大的时候就成为效率瓶颈。
Processing FloaterController#get_params (for 112.95.145.186 at 2011-04-14 17:12:50) [GET]
Session ID: BAh7CToOcmV0dXJuX3RvMDoMY3NyZl9pZCIlNTZiZTFkNWQyMmFhODI5NTU5
MTY1YmZhYWU4MWY1OTEiCmZsYXNoSUM6J0FjdGlvbkNvbnRyb2xsZXI6OkZs
YXNoOjpGbGFzaEhhc2h7AAY6CkB1c2VkewA6DHVzZXJfaWRpAln3--76893a47ec732df5617b5d1d70215e0b5b6df515
Parameters: {"action"=>"get_params", "controller"=>"floater", "isGetMessage"=>"1"}
Completed in 24.57103 (0 reqs/sec) | Rendering: 0.00021 (0%) | DB: 24.55177 (99%) | 200 OK [http://www.baicao.cc/floater/get_params?isGetMessage=1]
这个查询居然要24.57秒,于是把数据库导入本地进行debug日志分析,发现是下面两条数据库语句执行非常耗时
mysql> SELECT count(*) AS count_all FROM `floater_messages` WHERE ((owner_id=42926 and reply_to_id=0) or id in(select max(id) from floater_messages where owner_id=42926 and reply_to_id > 0 group by reply_to_id));
+-----------+
| count_all |
+-----------+
| 25 |
+-----------+
1 row in set ([color=red]7.39[/color] sec)
mysql> SELECT * FROM `floater_messages` WHERE ((owner_id=42926 and reply_to_id=0 and readed=0) or id in(select max(id) from floater_messages where owner_id=42926 and reply_to_id > 0 and readed=0 group by reply_to_id)) LIMIT 10;
Empty set ([color=red]9.82 sec[/color])
对于这样的问题,可以有一下两种方法解决:
1.将嵌套语句拆开查询,多次查询的结果通过自己写程序合并。这种方法适合于出了问题以后应急,写完的代码不优雅,尤其在优雅的rails上,所以问题规避了以后,另外找时间找办法彻底解决问题。
2.如果数据关系复杂,就分几张表存储。千万不可将本来关系复杂的数据存于一张表,这样在数据量大的时候就成为效率瓶颈。