目前表结构大致如下
comment:
id int(11), //自增主键
uid int(11), //发评论人id
aid int(11), //文章id
content text,
hot int(11),
time datetime
用的innodb引擎，索引大小 15G，数据大小 25G
应用场景：
hot更新非常频繁，文章详情页会按aid筛选并按hot和time排序取前n条评论。
前端已经对每条评论数据做了缓存，大部分读操作都命中缓存了，只有hot排序取条时要读mysql，但也对结果做了短时间的缓存。
后台有like关键词搜索评论内容的功能，也有按uid和aid精确查找的功能
自己的一点思路：
将content字段单独拆到新表用id与之关联，让comment表变小从而提高hot排序的效率
对于分表我比较保守，担心分了以后筛选排序操作会变困难还有其它方面的优化请大家补充
comment:
id int(11), //自增主键
uid int(11), //发评论人id
aid int(11), //文章id
content text,
hot int(11),
time datetime
用的innodb引擎，索引大小 15G，数据大小 25G
应用场景：
hot更新非常频繁，文章详情页会按aid筛选并按hot和time排序取前n条评论。
前端已经对每条评论数据做了缓存，大部分读操作都命中缓存了，只有hot排序取条时要读mysql，但也对结果做了短时间的缓存。
后台有like关键词搜索评论内容的功能，也有按uid和aid精确查找的功能
自己的一点思路：
将content字段单独拆到新表用id与之关联，让comment表变小从而提高hot排序的效率
对于分表我比较保守，担心分了以后筛选排序操作会变困难还有其它方面的优化请大家补充
剩下的是精确检索，在你的描述中， aid 多次出出现了，建议考虑按这个分区，这样检索的时候通控制在某个小数据量的分区上
对于 按hot和time排序取前n条评论 的问题， 如果你的 host 更新通常是新的，那就是和 time 最新有关联，那么按照 time 分表可以考虑，这样需要的数据都在近期的表中
对于是否要分表我比较纠结，感觉1亿数据量对mysql来说不算非常大，更担心是分完表对业务的负面影响会大于收益，可能以后的操作都要引入一些中间件才能完成了，也可能我的思路有点保守了