徐州微信网站建设标题关键词优化技巧
这里的多级，本质上其实也就二级，例如微博的评论，
一级评论： 对微博的评论
二级评论： 对微博下的评论的回复评论 ，这里包括二种 1. 回复的是一级评论， 2, 回复的是二级评论
效果如下
表数据
查询文章评论时：
SELECT * from comment where article_id = '1' and comment_level = 1 ORDER BY top_status desc ,create_time desc结果：
1 aaa 张三 1 标题党 1 一级评论(评论文章) 1 0 0 2019-04-26 17:37:48
查看评论下的回复时：
SELECT * from comment where parent_comment_id = '1' and article_id = '1' and comment_level = 2 ORDER BY create_time desc
结果：
3 aaa 张三 1 标题党 1 aaa 2 bbb 2 回复二级评论 1 0 0 2019-04-26 17:40:04
2 bbb 李四 1 标题党 1 aaa 2 回复一级评论 1 0 0 2019-04-26 17:38:53
上面查询评论都是按照时间 create_time 倒叙，如果要改成微博的那种按照热度的 或者点赞量的
只需要把create_time 改成 praise_num
-----------------------------------------------------------------------表结构如下--------------------------------------------------------------------------------------------
id 评论id 可以设置为自增主键 也可设置为uuid
user_id 评论人userId
user_name 评论人昵称 ，记录当时评论的时候用户的昵称，如果用户昵称修改，评论展示也变的话 不需要设置该字段
article_id 在哪篇篇文章下评论的
article_title 文章标题，记录当时评论的时候文章标题，查看我的评论或者 评论我的时，文章动态获取的话 不需要设置该字段
parent_comment_id 父级评论id
parent_comment_user_id 父级评论的userid
reply_comment_id 被回复的评论id
reply_comment_user_id 被回复的评论的userid
comment_level 评论级别 ，回复文章的是一级评论 ，其它的都是二级评论
content 评论内容
status 评论状态，评论被删除了 都是 逻辑删除，不会真实删除
praise_num 评论的点赞数量
top_status 评论是否置顶
create_time 评论创建时间
表结构为
CREATE TABLE `comment` (`id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '评论id',`user_id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '评论人userId',`user_name` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '评论人名称',`article_id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '评论的文章id',`article_title` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '评论的文章标题',`parent_comment_id` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '父评论id',`parent_comment_user_id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '父评论的用户id',`reply_comment_id` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '被回复的评论id',`reply_comment_user_id` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '被回复的评论用户id',`comment_level` tinyint(4) NOT NULL DEFAULT '1' COMMENT '评论等级[ 1 一级评论 默认 ，2 二级评论]',`content` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '评论的内容',`status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态 (1 有效，0 逻辑删除)',`praise_num` int(11) NOT NULL DEFAULT '0' COMMENT '点赞数',`top_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '置顶状态[ 1 置顶，0 不置顶 默认 ]',`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',PRIMARY KEY (`id`),KEY `idx_article_id` (`article_id`) USING BTREE,KEY `idx_user_id` (`user_id`) USING BTREE,KEY `idx_create_time` (`create_time`),KEY `idx_parent_comment_id` (`parent_comment_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='文章评论表';
1. 编码设置为 utf8mb4 是为了支持 emoji 标签
2. id 根据需求可以设置为自增 或者 uuid
3. user_name 字段 和 article_name 字段 根据需要来是否设置为表字段。如果为表字段 就不用连表查询，但是 记录的都是当时评论的时候的用户名和 文章标题。 好在用户昵称和文章标题变化 但是 对应的 id 是不变的，也可以关联查询到。
4. 文章id ，用户id 创建时间，父评论id 设置索引 在查询时都能有效利用索引
5. 评论删除功能，其实都不是 真实物理删除，只是设置不可见，（支持消息中心以及 我的评论 ）