@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 模式

@chitanda #3 去掉 case 后就正常了，但是单加 is_send_msg 属性，会报：
SELECT list is not in GROUP BY clause and contains nonaggregated column 'Test.Goods_Status.is_send_msg' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
本质是 is_send_msg 和 is_pick_up 这 2 个不在主表中的属性和 only_full_group_by 模式导致的问题。
@wowo243 #2 去掉这个配置当然是一个解决方案，但这只是在逃避这个问题吧，现在可以去掉配置解决，但是将来遇到不能去掉配置的情况下，不还是要面对吗？
@JRay #1 因为以前的写好的 SQL 用不了吗 2333，我最开始遇到的时候是避免在 SQL 中用 Group By 来躲过去的，但是今天实在是不写 Group By 查不到要的数据了

照片是按日期排序的，在照片下用小缩略图带时间的模式显示，就应该能快速定位了