开发一个小应用，用户可以提出问题，等待其他人来回答，进而可以互相交流，用户也能一定概率收到别人提出都问题。mysql数据库设计时将提出的问题和回答消息都放在了一张表格里(比较失败)，在程序中需要查询当前未读消息和问题，使用了嵌套查询语句进行查询。刚开始时没有问题，但是过了大概1个月左右，应用变得非常慢，以为是数据库表格数据太大，通过查询，表格才4000多数据，于是通过日志进行了分析。
Processing FloaterController#get_params (for 112.95.145.186 at -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 [/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.如果数据关系复杂，就分几张表存储。千万不可将本来关系复杂的数据存于一张表，这样在数据量大的时候就成为效率瓶颈。
