请教大佬，我这 SQL 写的有没有问题？

[cl903254852]

article(文章表)：

article_content(文章内容表)：

article_tag(标签表)：

article_type(分类表)：

---

其中 article(文章表)、article_content(文章内容表) 是一对一关系

article(文章表)、article_tag(标签表) 是多对多关系，关系表 tag_article 如下：

article(文章表)、article_type(分类表) 也是多对多关系，关系表 type_article 如下：

---

需求

查询所有文章，包含以下数据：

• id：文章 id
• title：文章标题
• tag_id：当前文章下的所有标签 id
• tag_name：当前文章下的所有标签名
• type_id：当前文章的分类 id
• type_name：当前文章的分类名称

然后我自己写的 SQL 是这样的：

SELECT 
a.id, 
a.title,
GROUP_CONCAT( distinct t.tag_id),
GROUP_CONCAT( distinct type.type_id),
GROUP_CONCAT( distinct a_tag.tag_name),
GROUP_CONCAT( distinct a_type.type_name)
FROM article a  
JOIN tag_article t ON a.id=t.article_id
JOIN type_article type ON a.id = type.article_id 
JOIN article_tag a_tag ON a_tag.id=t.tag_id
JOIN article_type a_type ON a_type.id=type.type_id
GROUP BY a.id;

结果：

结果也能出来，但我心里总有点不踏实。

各位大佬，我这 SQL 写的有没有问题？或者不严谨的地方？

ps:鄙人也是刚入门 Mysql，轻喷☹️

[zeraba]

先恢复一对一，再 join，笛卡尔积很可怕，比如文章对应的标签，先按照文章 id group by 再 concat 最后关联就都没有重复了

[wangyzj]

@cl903254852 酱紫俩表就解决问题了，基本上一次 update 操作，复杂的都没有了，text 可以做全文检索，虽然不咋滴
多对多的话把 acticle_type_id 字段做成 list 结构，标签我觉得就不用做表了

[cl903254852]

@gIrl1990 可以不讨论这个吗，你就当产品是白痴，他就这么设计的。我提问题只是想知道这个 SQL 有没有更好的写法😹😹😹

[cl903254852]

@wongyusing 原谅我的无知，我才开始学 mysql。把文章内容分出去，是考虑到如果数据量很大，而前端列表里不需要展示文章内容，只有在详情里才会查文章内容，这样性能应该会更好，type 这个是我没考虑周全 受教了~。

[hosaos]

分多次查询
1、先单表查询文章
2、根据文章 id 查询文章内容、标签、类型

连表查 等你数据多了就炸了

[akira]

典型的学院派，没啥大问题。

[greed1is9good]

@gIrl1990 估计他的标签应该是和关键字差不多意思吧，其实通常的做法是文章表有个关键字（标签）字段，show 文章的时候关键字（标签）做成查询链接，点击后查询出包含比关键字（标签）的内容。

[cl903254852]

@akira 哈哈 我是看视频学的

[cl903254852]

@greed1is9good 是的

[cl903254852]

@hosaos 大佬意思是连表查，如果连的表多，在数据量大的情况下容易爆炸。 但分多次查，也会导致性能下降吧，我的想法是如果能一次查出来最好，用子查询会降低性能。。。 不知道这样想对不对

[wongyusing]

@cl903254852 你用的是 select * from xxxx 吗？
你指定一下字段就行啦，这个不影响速度的啊。

[hosaos]

@cl903254852 数据量大的情况下 多次查询优于联表查