mysql关注表_浅谈关于粉丝关注者的MySQL数据库关系表结
构设计
前⽅⼤量硬核内容 请谨慎观看
分布式架构是什么意思最近在做ONEMC的前后端开发⼯作，前端⾮⽤户区基本OK了，但⽤户区显然还有⼀⼤堆问题等待我去解决。DedeCMS原有的数据库结构不算特别完美，有很多表出现了⾮常不能理解的字段(⽐如可以⽤left join的地⽅ ⾮加个⽤户名字段...)，这些问题我是不打算直接去解决的，⼀是为了防⽌修改数据库结构导致的程序异常；⼆是，我确实不知道如何下⼿。
前段时间把评论系统完⼯了，为了区分主楼和回复层，我添加了⼀个“ParentCID”字段来解决这个问题，还算完美。
我的设计
不过最让⼈头疼的还是粉丝/关注者的数据库结构设计，我参考了DedeCMS的设计，他并没有原版的“关注结构”，只有⼀个好友表，它使⽤了⼀种⽬前算是极其复杂的设计。
本⽂讨论的⼏种⽅式都是针对⼤⽹站的，虽然我⼀个草根站长并不会运营出那么⼤的⽹站，但是研究还是要有的，只不过给了我很多旁路
没必要去优化⾄极限。⽹站⼈少，设计复杂的数据库结构反⽽可以帮助把体验搞得好⼀点。
stract每种⽅案的SQL指令都附在⽂章尾部了，欢迎尝试每种⽅案的效率。本⽂介绍的前⼏种⽅案都是来⾃于⽹络 本⼈稍作修改理解⽽成的。⽅案A：DedeCMS默认好友表
优化 |效率  |简洁 ⾮常繁琐
这种结构优点很多，⽐如说⽅便统计、筛选各种数据。可这种表缺点也很明显，当关注你(DedeCMS中指单⽅⾯加好友)的⼈数超过⼀定数量后，会显得数据冗杂⼗分的严重，因为每⼀次关注都要增加⼀⾏，我们假设微博上有⼀千个粉丝过千万的⼤明星、上万个粉丝过百万的
⼈，那么单个表就要有成百上千亿的数据，那么就不得不做分表处理。
⽅案B：单⾏设计
优化 |效率 |简洁
先说说他的设计原理，每⼀个⽤户的粉丝/关注数据存储在⼀个字段内，使⽤";"或者其他分隔符分隔开每个⽤户(或者json存储)。dialogue视频
恕我直⾔，这是我见过最奇怪的设计 没有之⼀。解决了冗杂数据的问题，但是增加了更多问题，刚开始还好，等到某⼈粉丝多多多多了时，“粉丝数据”字段的⼤⼩可能会达到MB级别，这时使⽤PHP进⾏操作就显得⼗分的吃⼒，⼗分的占⽤CPU。
⽽且，如果你要看⼀个⽤户是否关注/被你关注，也是⼗分⿇烦的，全读出来就很占⽤资源了。
⽅案C：列表设计
优化  |效率    |简洁
这是我打算⽤在ONEMC上的设计，感觉不错，⽽且⽅便拓展修改。设计原理：每增加/删除⼀位粉丝就插⼊/删除⼀条数据，记录被关注者和关注者。也可以通过SQL指令查询互关情况。
其中的“状态”字段可以有三种(0.关注 1.互关 2.悄悄关注)也可以拓展或者不⽤这个字段。
缺点：每⼀个⼈关注另⼀个⼈都要插⼊⼀条数据，同⽅案A，但是互关可以先查询 然后按情况进⾏ 也算优化了。
除了这些，还可以⽤到Redis的Hash数据类型，但是较为⿇烦 理解上也⽐较复杂，况且本⽂主要讨论MySQL，所以就不再多说了。最近会研究出⼀种适合中⼩型⽹站的设计⽅案 预计时基于这⼏种⽅案修改，欢迎⼤佬关注、指正批评。
mysql安装包有多大总结
不管哪种⽅案，都有它存在的道理和适⽤⼈，这篇⽂章只是浅谈了⼀些问题，真正要做那么⼤的⽹站时，也终归避不开亿级的数据，如何优化 就看你们的了。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⼤讲堂
博客：p
本⽂所提到的ONEMC：1mc.site

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。