MYSQL 评论表结构优化

[Aluhao]

数据表结构

CREATE TABLE comments (

id bigint(20) unsigned NOT NULL AUTO_INCREMENT,

aid bigint(20) unsigned NOT NULL DEFAULT '0',

uid bigint(20) unsigned NOT NULL DEFAULT '0',

contents text NOT NULL,

likes int(10) unsigned NOT NULL DEFAULT '0',

comments int(10) unsigned NOT NULL DEFAULT '0',

time int(10) unsigned NOT NULL DEFAULT '0',

PRIMARY KEY (id),

KEY aid (aid),

KEY time (time)

) ENGINE=MyISAM DEFAULT CHARSET=utf8;

现在有 7 千万数据， 表大小 3.60 GB 索引大小 2.55 GB ； AID 是新闻的 ID ； UID 是评论用户； contents 是评论内容； 随着数据越来越多表越来越大，如果分表，业务逻辑很麻烦，又达不到需求，有什么好的优化方案？

我现在想把 contents 内容单独一个表存放，就是说这个评论表 增加一个表；

CREATE TABLE comments_data (

id bigint(20) unsigned NOT NULL DEFAULT '0',

contents text NOT NULL,

PRIMARY KEY (id)

) ENGINE=MyISAM DEFAULT CHARSET=utf8;

这样虽然能优化一些，但终究不是最终解决方案，不知道 V2 朋友们有没做过类似的数据结构优化；

[jetyang]

分表，按 aid 分表
likes、comments 看上去是收藏数和评论数，如果经常更新建议拆出去

[Leigg]

兄 dei，首先你这个肯定要做缓存的，至少把最近一周或一个月的新闻的评论放到缓存服务器上，至于分表的话我建议做水平分表，垂直分没什么作用，毕竟查的是评论这种占空间的文本内容。最后我想说你的这种结构用 mongo 很好做，mongo 可以把一条新闻下的所有用户的评论存为一条记录，算起来这个记录数怕不是要比 mysql 少多少倍。。

[sheldoner]

@Leigg 请教一下 “ mongo 可以把一条新闻下的所有用户的评论存为一条记录” 所有评论怎么存为一条记录

[Aluhao]

@Leigg 是呀，求方法

[qiayue]

@sheldoner @Aluhao mongo 存的是 bjson 文档，可以简单理解为 json 格式数据，把所有评论放到一个 json 里不就是一条记录么

[xudaiqing]

MySQL 不是很熟，但我记得 MyISAM 各方面都不如 Innodb 而且已经几乎停止开发了。
3.60 GB 数据量很小，一般的索引就够了。如果性能不行，内存太小或者索引和查询的设计有问题的的可能性比较大。
索引大小 2.55 GB 感觉太大了，我觉得索引可能有问题。
“索引虽然只建了 id 和 aid 二个” 对 id 建索引意义何在？

[Leigg]

@sheldoner 酱紫的，类 json 格式存储一条新闻下的所有评论，
{新闻 id：xxx, 评论数：xxx, 评论信息：[ {
评论 id:xxx,
评论文本:xxx，
评论用户:xxx,
回复楼层:xxx,
赞数:xxx,
},{},{} ]
}
评论信息的 value 按评论楼层排序，这是 mongo 中大概的字段设计模型，具体怎么设计要看业务需求。但肯定比 mysql 快，索引也省不少空间。楼主可以当做参考哈~

[iyaozhen]

几亿以下的数据都可以考虑表分区，按照 aid 或者时间分区，where 条件带上分区字段，索引正确很快。主要是业务代码不需要改动
然后数据库建议升级到 5.7 或者 8.0，使用 innodb

[hwiiago]

水平分表、mongo、缓存、冷热分离、#7 楼 es 方案，视具体业务场景选择。

[kran]

单文章评论不会急剧增长，应该考虑按照评论数分表，比如一千万。文章表存储评论表 id，新建文章时确定评论表 id，如果最大 id 评论表存储的数目大于一千万，就增一并新建相应评论表。完全不需要引入其他依赖。

[blueskit]

数据量不大应该并不迫切分表什么的。
建议从查询日志分析具体的慢查询类别、然后对症下药。
不管怎么说，加缓存可以先上

[msg7086]

@xudaiqing 主键索引。

[xudaiqing]

@msg7086 主键是自动强制索引的,单独拿出来说就怕是 id 的常规索引

[very9527]

content 的字段是不是太大了？

[enhancer]

@Aluhao 那就应该考虑根据评论表中的 [新闻 ID] 来分表，确保某条新闻，根据其新闻 ID 加载的评论都全部来自某张评论分表。

[sheldoner]

@qiayue 谢谢，我们用的是 redis，没太关注 mongo 的文档
@Leigg 像这样的话，系统启动，评论信息就初始化到 mongo 里面了。评论的东西感觉也有很大了，这样初始化，mongo 性能够吗，内存占用也会很高吧

[Leigg]

@sheldoner 可以通过配置“缓存大小”来优化，数据量到一定级别后且高并发查询和写入的话要做副本集或分片，像题主这种情况不至于高并发写入，做副本集应该足以应对。但是做分片可以避免单台实例过于臃肿的情况。

[MeteorCat]

@sheldoner mongo 不是什么灵丹妙药，大量数据加载进 mongo 之后内存很快吃光了，如果并发量并不是那么高[比如有的内容仅仅三五个人看一遍没必要上 mongo]，本地文件读取都行；还有另外一种优化方法，就是加载渲染内容的时候不一起加载评论[这也是一个普遍做法]，评论另外走 js 接口拼接到内容下面，判断用户是否拉到最下面准备读取评论

[houshengzi]

觉得应该优先考虑 MySQL partition

[sheldoner]

@Leigg
@MeteorCat