@jiangzhuo 软 nat 和硬 nat 的区别吧

@input2output 这篇文章的观点好像是不对的。说是 close 的时候，可能有 buffer 没有落盘？可是 go 的 write 操作没有应用层 buffer 的，直接就是 write 系统调用写到 page cache 了，这时候就算进程挂了，内核也应该会自动落盘。

@msg7086 整个帖子看下来，感觉就是三个原因不用 join 。

1. 开发人员水平参差不齐
2. mysql“垃圾”
3. 业务扩展性

都这么纠结了，是不是直接用 nosql 会更好。

@msg7086 正常来说几百 GB 的数据表，查出来的关联 id 才几万个？我用 join 可不是扫全表的关联关系啊。

@msg7086 几万只是随便说的一个数字，如果数据量更大呢，然后要在内存里组装一个巨大的 sql 出来吗？还有和直接子查询 select xxxxxx from article where id in(select xxx)好像没啥区别，楼主说也不能用子查询。

@CRVV 老哥，你这个表结构， [SELECT id FROM tag WHERE name = XXX 取出 tag_id] 这一句可以取出几万个 id，用这几万个 id 再去 in 查询后面的数据这不止是慢吧。

@CRVV 感谢老哥的回答，老哥你说的对。其实我不是很在意一对多还是多对多，就是想说用 mysql 设计成这样的关系，当查询条件涉及到多个表的字段，不用 join 就没法实现我想要的功能。而不是一刀切的不能用 join，不能用 join 的话，肯定就不会这么设计，直接用 nosql 了。

@huijiewei 哈哈哈哈哈哈，确实看不懂，可能你用的是 mysql pro max，我用了个 mysql se

@newtype0092 对，是这样的。

@huijiewei 你的 article 表可以 in 查询 tag_id? 这么神奇的吗？手动狗头

@huijiewei 不用 join 我是实现不了，请教下这个怎么拆成 3 个 sql 还能满足需求。

@magicnian 你说的部分数据放到 mongo，如果查询字段同时有 mongo 和 mysql 的字段岂不是炸裂。我倒是觉得数据量大了，把查询的关键字段都放到 es 或者 nosql，然后用主键去 mysql 查详情就好。

@magicnian 这种关联关系挺常见的，所以最终归宿都是 nosql ？

请教下楼上的大佬不用 join 怎么实现以下需求？用关系型数据库存文章，每篇文章包含多个标签（一对多），每篇文章包含多个作者（一对多），后台管理页面需要按作者和标签检索并分页。

While games and artificial intelligence and machine learning developers care deeply about graphics, video and image processing doesn't interest Torvalds much. He used:

"Some random Sapphire RX580 graphics card. It's overkill for what I do (desktop use, no games)."



显卡是 RX580

@meisen imac 4k 分辨率是 4096 x 2304，和 1080 、720 都不是整除，岂不是全屏看视频基本都会模糊了。。。

看评论看晕了，啥结论都有。

蹲一个结论，不等比缩放全屏看视频到底有没有观感影响。😂

@learnshare 为什么我选择不上 YPbPr，P3 可以选上。 显示器一重启就变回 RGB 了。

@reus 确实是不一样，但是楼主读 udp 消息为什么要用 ReadFull 呢，buf 给少了会丢数据（就算是加了 bufio.Reader 也是不符合场景的，造成一次消息多次读取，本来都是用 udp 了还要自己做消息分隔符，而且消息的内容长度必须是预设 buf 的整数倍，不然会后那点消息会被卡住），如果一开始预设 buf 给多了也会卡住。

所以读 udp 直接用 ReadFrom 给一个满足业务需求的 buf 大小就行了。