@szzhiyang #19 不需要同步和重复修改的文件，按照这个应用的默认保存位置放（这种情况下大概率也是文档文件夹下），如果是临时存放的文件，比如改完发送给别人之后再也不用的文件，就统一扔在下载（ download ）文件夹下，一段时间会手动清理下载文件夹下的文件到回收站，回收站的文件存放 3 个月后系统自动删除。
使用 OneDrive 文件夹不只是同步，还有因为 office365 打开 OneDrive 文件夹下的文件可以打开自动保存功能，并且有非常完备的历史记录功能，可以快速回退版本。

@szzhiyang #16 我已经给你恢复了，请看 15 楼

另外实际上一些 IDE 会默认把工作空间放到文档这个目录下，所以你说在另外的地方放文档，最后也会变成这个乱糟糟的样子，我自己管理还不如就交给应用默认设置了，我自己再通过 everything 之类的软件直接搜索打开不是更方便。至于需要多次操作和共享的文件，统一在 OneDrive 文件夹下

@szzhiyang #11 我只针对你的提问给出回答啊，你的提问是“请问习惯在用户文件夹管理文件的 V 友是如何处理图中所示的文件夹的？”，我给出的回答是隐藏掉不是自己创建的文件夹，这很难理解吗？
而我在什么地方存文件根本就不是你要的问题啊

@szzhiyang #8 我觉得我的回答已经说的很清楚了啊，隐藏后没有特殊目的就没必要显示这些文件夹了，而且本身你的问题就是如何处理这些文件夹，比起你一个个应用改设置，转移文件，只需要对这一堆文件夹右键设置隐藏这一个操作就能一劳永逸。我也不明白你是怎么从我的回答中看出我让你反复隐藏 /显示这些文件夹的。也不是很理解这样的操作怎么就把简单的事情复杂化了。

直接右键隐藏，所谓眼不见心不烦，而且真的要用的时候还能直接通过设置改回来 /通过路径直接访问，也不会出什么 BUG。

@daydaydayup #9 如果微信是独立密码，那不考虑一下身边人作案？毕竟如果是微信密码泄露这种大瓜，网上不可能一点风声没有啊。

微信是不会同步聊天记录的，所以换新设备才需要自行传输聊天数据，另外实际上微信登陆新设备是需要二次验证的，比如短信或者再一堆列表中选中微信上的好友，至于盗号的人是怎么绕过去的，我也觉得很神奇。另外都通过密码登录了，楼主不考虑一下自己的密码是怎么泄露了的吗？

ios 直接放弃这些管家 APP 了，没什么用只是提示标记，还是会响铃，打断操作。直接上移动的骚扰拦截，非常舒心，还能直接屏蔽号段

关注一下

@wly19960911 #72 登陆提示？登陆不进去就直接告诉你账号和密码吧

@chitanda #16 嗯嗯，谢谢，我已经明白这个文档的意思了。

当然以是否为主键判断，在多表查询中可能不适用，因为 group by a.id 中的 id 字段，在 a 表中是主键，但是在 b 表中只是外键，外键是可以不唯一的，就会产生一对多的情况，导致数据的丢失。而实际，如果 2 张互相关联的表的主键是相同的一个字段，完全就可以把这 2 张表整合成一张表，而不是像我一样故意设计成 2 张表。
如果我这样理解没有问题，那我应该是明白这个 only_full_group_by 的意思了，而导致我 SQL 报错的原因只是数据库在执行前不知道我的数据对应关系，导致这种特定情况下正确的 SQL 被认为存在问题（按我理解，这个报错等级应该归在 warning 而非 error ），但是 SQL 是不像 Java 这类语言一样即使 Warning 也可以正常运行，这大概也是官方给出 ANY_VALUE()这个函数的理由吧。
@Wolfsin #13

@liprais #12 那么其实数据库也并不知道 group by 的字段在数据库中究竟是什么定位对吧，因为只要 group by 中的字段是主键，就会产生我说的情况，即数据并不会因为 group by 而丢失，这个情况下 select 中选取非唯一的字段是没有任何问题的。
而当 group by 非主键的情况，才应该考虑是不是会产生因为 group by 而导致的数据丢失，即 Mysq 这个 sql_mode=only_full_group_by 模式考虑到的场景。

@liprais #10 我明白这个情况下的 group by，Mysql 低版本能给出结果是不合理的，这篇文章已经替我解答了这个疑问
https://blog.csdn.net/liufei198613/article/details/82979034
所以我想明确上面那位朋友说的唯一性的定义，实际在我这边，a 和 b 是一对一的关系，即不存在一个 a 对应多个 b 的情况，即您上面举例的情况在我的表中并不存在。

@chitanda #7 您好，谢谢您的回复，那个我先问一下您回复中的唯一是什么意思，因为感觉有歧义，是指

id=1 name=1

这样的一个 id 对应的 name 值唯一，不存在一个 id 对应多个 name，如：

id=1 name=1
id=1 name=2

这种情况，还是指 name 这个字段被 unique 约束，在此基础上，我对您说的“ select 里面，非 group_by 的字段，你应该确保他们是唯一的”这一句话，感到有点无法理解，因为 select 中非 group by 的字段是否 unique 约束好像并不影响结果，如果你说的是 group by 的字段需要 unique，那我是明白您想表达的意思的。

在我的 SQL 中虽然的确筛选了非唯一的字段，但是因为这个字段是跟主键一一绑定（ 1：1 的关系）的（我不太清楚我描述的有没有问题即 1 个 is_send_msg 跟 1 个 id 对应，一个 id 也只能有 1 个 is_send_msg 字段，不存在一个 id 有 2 个 is_send_msg 的值），所以感觉子查询好像有一点多此一举？实际看你给我写的例子，id 可以有多个 name （我是从 count 这个函数中推断出来的，如果说错了请见谅，因为如果 id 和 name 一一对应，count （ name ）的结果应该一直为“ 1 ”）

我会在 APPEND 中补充我 3 张表的数据，如果您方便的话，可以帮忙结合着数据看一看我的 SQL 写的有什么问题吗？

@alcarl #5 我也是这么想的，所以才发帖问问这个究竟是怎么回事，现在网上给出的解决方案都是去配置里面关闭 only_full_group_by 模式