前提
项目是一个Android APP，里面做了聊天的功能。服务器上的数据库用的是MySQL。
-- update 2014-06-06 --
会话的类型有两种，一种是短会话，聊天记录可能在20条以内，这个会话就结束了；另一种是长会话，就是类似QQ这种，想聊多久都行。不知道能不能在这上面做优化。
问题
所有聊天记录都会存在服务器上（客户端也有，但只存储最近一段时间的记录），对于在服务器上如何存储这些聊天记录，现在想到的两套方案：
- 为每个会话在数据库建一张表，每条聊天记录都存在对应的表里，但是这样做的话会让数据库里的表越建越多（因为APP的需求原因，所有聊天记录都要是随时可查的），是不是到后面会对数据库性能产生很大影响？
- 为每个会话建一个文本文件，每条聊天记录都存在对应的文件里，但是这样的话服务器上的磁盘空间会有压力，而且对磁盘文件进行读写的性能肯定要比数据库差。
如果是要在上面两套方案中间取舍应该怎么选？或者有没有更好的解决方案？
ps：之所以想要在两套方案之间选一个，是因为实现起来比较简单
建一个表不行吗？，如果超过多少就自动创建一个分表
里面记录每天聊天记录的信息，这样查询也方便，操作也方便还可以提前加载到缓存中
想知道 用mysql 如何分组 取数据 出来。
可以用rethinkdb或者mongodb这种存储。因为消息对acid要求很弱，不如采用一个容易scale的存储技术。另外可以写程序自动把3个月前的数据dump到另一个集群，控制数据规模
文件是不必考虑的，磁盘性能会让系统的效率lag无比。
可以考虑用两个表，room表记录会话，content表记录内容。content中的room_id字段用来标记会话的id。
此类记录储存不用mysql的话，就如楼上所说有更专业的数据库。
但如果用mysql的话，且只考虑两人聊天的话，不知下列方法是否可行，反正自己的小程序目前这么用的：
－msg table(msg_id, msg_user_id, msg_chat_id, ...）
－chat table(chat_id, chat_user_id_a, chat_user_id_b, ...)
通过简单的sql query就可以实现任何两人之间的chat记录查询。
注：可以选择两人之间chat_id始终唯一，也可以选择另起chat_id，unique index实现。
当然，对于长久chat，里面的msg信息可以选择存到本地，然后记录下当前最新的msg_id，
下次query就不用遍历全部的msg了。
就算本地记录被清除，可以采用下拉更新的方式，每次query一小部分，以一定数量的msg record或者时间为界限。
最后，作为小白程序员，总觉得mysql对这类应用后期不太容易scale，恳请指教！