前方大量硬核内容 请谨慎观看
最近在做ONEMC的前后端开发工作，前端非用户区基本OK了，但用户区显然还有一大堆问题等待我去解决。DedeCMS原有的数据库结构不算特别完美，有很多表出现了非常不能理解的字段(比如可以用left join的地方 非加个用户名字段...)，这些问题我是不打算直接去解决的，一是为了防止修改数据库结构导致的程序异常；二是，我确实不知道如何下手。
前段时间把评论系统完工了，为了区分主楼和回复层，我添加了一个“ParentCID”字段来解决这个问题，还算完美。我的设计
不过最让人头疼的还是粉丝/关注者的数据库结构设计，我参考了DedeCMS的设计，他并没有原版的“关注结构”，只有一个好友表，它使用了一种目前算是极其复杂的设计。
本文讨论的几种方式都是针对大网站的，虽然我一个草根站长并不会运营出那么大的网站，但是研究还是要有的，只不过给了我很多旁路 没必要去优化至极限。网站人少，设计复杂的数据库结构反而可以帮助把体验搞得好一点。
每种方案的SQL指令都附在文章尾部了，欢迎尝试每种方案的效率。本文介绍的前几种方案都是来自于网络 本人稍作修改理解而成的。
方案A：DedeCMS默认好友表
优化⭐|效率⭐⭐⭐|简洁⭐非常繁琐
这种结构优点很多，比如说方便统计、筛选各种数据。可这种表缺点也很明显，当关注你(DedeCMS中指单方面加好友)的人数超过一定数量后，会显得数据冗杂十分的严重，因为每一次关注都要增加一行，我们假设微博上有一千个粉丝过千万的大明星、上万个粉丝过百万的人，那么单个表就要有成百上千亿的数据，那么就不得不做分表处理。
方案B：单行设计
优化⭐|效率⭐|简洁⭐⭐⭐⭐⭐
先说说他的设计原理，每一个用户的粉丝/关注数据存储在一个字段内，使用";"或者其他分隔符分隔开每个用户(或者json存储)。
恕我直言，这是我见过最奇怪的设计 没有之一。解决了冗杂数据的问题，但是增加了更多问题，刚开始还好，等到某人粉丝多多多多了时，“粉丝数据”字段的大小可能会达到MB级别，这时使用PHP进行操作就显得十分的吃力，十分的占用CPU。
而且，如果你要看一个用户是否关注/被你关注，也是十分麻烦的，全读出来就很占用资源了。
方案C：列表设计
优化⭐⭐|效率⭐⭐⭐⭐|简洁⭐⭐
这是我打算用在ONEMC上的设计，感觉不错，而且方便拓展修改。设计原理：每增加/删除一位粉丝就插入/删除一条数据，记录被关注者和关注者。也可以通过SQL指令查询互关情况。
其中的“状态”字段可以有三种(0.关注 1.互关 2.悄悄关注)也可以拓展或者不用这个字段。
缺点：每一个人关注另一个人都要插入一条数据，同方案A，但是互关可以先查询 然后按情况进行 也算优化了。
除了这些，还可以用到Redis的Hash数据类型，但是较为麻烦 理解上也比较复杂，况且本文主要讨论MySQL，所以就不再多说了。最近会研究出一种适合中小型网站的设计方案 预计时基于这几种方案修改，欢迎大佬关注、指正批评。
总结
不管哪种方案，都有它存在的道理和适用人群，这篇文章只是浅谈了一些问题，真正要做那么大的网站时，也终归避不开亿级的数据，如何优化 就看你们的了。
小网站的话，不管你如何负优化，面对的也只不过是那些几千几万最多几十万条的数据，不管如何查询也在1秒内，与其杞人忧天不如考虑考虑如何运营网站。
真优化不了的话，也可以通过购买高配置的服务器临时解决这个问题。没技术就靠钱咯……
最后分享一个SQL中left join的用法，比如你要获取一篇文章[id：123456]的作者和文章标题、内容，但在数据库文章表中记录的作者是UID(方便存储、避免改名等特殊情况) 这时就要用到left join。
语法：select a.标题,a.内容,b.用户名 from 文章表 as a left join 用户表 as b on b.用户ID=a.发布者ID where a.文章ID=123456
*为了方便初学者学习 本文中所有数据库字段和语法都使用了中文 建议实际开发时全部替换为英文 避免出现编码问题。
Bilibili@HT大神
知乎/酷安同上
微信公众号：HT大讲堂
博客：htblog.top
本文所提到的ONEMC：1mc.site
