heiya

SQL 太复杂，一查几百行，表数据量又太大 导致大量的慢 sql ，是不是瓶颈在于查询而不是新增和修改？这样的话我感觉用 Redis 替代 Mysql 查询不合适，原因是即使前台没有显式的调用这些复杂 sql ，在相关业务进行新增和修改时也调用复杂 sql 同步到 Redis ；如果说不调用 sql 直接将数据存到 Redis ，那能不能确定由复杂 sql 组成的数据可以通过简单的 Redis 命令重新组成，我感觉挺困难的；还有数据量太多的话假设 Redis 挂掉，AOF 恢复是需要时间的，在这段时间内服务不可用；综上，我感觉 Redis 不合适。 解决办法根据描述我感觉：1.针对那些很复杂、数据量又特别多导致慢 sql 的表，将这数据同步到 ES 的一个索引中，组成一个大宽表，所有有关的复杂查询全走 ES 2.每次新增或修改时使用消息队列同步到 ES ，不能直接同步（或者现在有一些同步组件可以用） 3.如果有很多复杂查询但彼此不相关就需要多个索引了 4. 如果条件允许的话针对这些复杂的查询单独拆出来组成查询服务 5.分库分表还是有必要搞的，不过根据我的经验用过 Sharding 和 Mycat ，复杂的 sql 还是歇菜 6. 优化还得继续，慢 sql 报警不知道有没有 7.业务上能不能限制一下查询条件，比如起始时间什么的 8.有没有数据冷热分离的可能性？ 9.据说 PG 很强，但我没有用过，得试试

@YiXinCoding 请教一下。我的需求是有不能联网的情况且代码要离线部署在客户服务器上，具体的要求是一个组织下有若干台设备，一个激活码控制着组织下的所有设备。现在的问题是纯软件的情况下不能百分百保证 A 组织的激活码不能被 B 组织使用，应该怎么设计呢？

相亲的话最好不要相年龄大的

感谢大家，我觉得我又行了。靠谱就是一个很难得的品质了了

生活没有起伏？上杠杆梭哈大 A

先去呆三天两天的看看情况，找个合适的机会问问同事。该提桶提桶~