@zjyl1994 拍照的你是拦不住的。只能说进我们所能降低这些风险并且能够提高员工的工作效率。

@MeSMC 已经有加密系统（亿赛通），但是那个加密系统漏洞很多。我简单的看了下。就知道怎么解密了文件了。不靠谱。

@fcfangcc 对 要的就是这种效果

@RiESA 现在上传的渠道太多， 网盘等肯定不能完全限制住

@lihongjie0209 监控这玩意 一旦泄露出去 再去追究责任 已经损失很大了。

@wr410 我们现在有几台固定的上网地点。但是需要到其他地方。使用起来不是很方便。

@chinesestudio 看个人使用习惯吧 我觉得这个听不错的。

谢谢 大家 已经满员了。

只要一分钱哦

试了一下 几次都是验证失败

各位 解释一下 。是有开发团队的。原来的负责人离职了。现在还有开发人员在。

@akira 你是说数据库冗余这两个列么？ DATE_FORMAT(a.created_at,"%m-%d") 和 DATE_FORMAT(a.created_at,"%H")

@likuku 哈哈 2 核 4g 够用了，前几天我还是用一核 2g

前期进行 group by 是因为需要根据是时间 将各个 rid 的值进行累加。如果后面效率不行 我将考虑 group by 和 sum 操作由业务代码处理。但是数据量巨大，也许会有其他的问题。

各位，我后来把阿里云的服务器的数据 down 到本地跑，同样的数据同样的 sql 语句，跑完只要 0.3s. 后来我就升级了一下数据库的配置（ 1 核 2G 升级到 2 核 4G ），现在执行结果是 0.4S 。但是仍然比我本地慢。

后面我将继续根据大神的指点，将 group 操作放到业务逻辑里面去计算。谢谢各位了。

我先试一下 谢谢各位

@mineqiqi created_at 的索引已经加了

@showecho 用的是 RDS 一核 2G 的