@ruuu 我不发烧的，就是嗓子痛流鼻涕

@KimGuo 发烧太难受了，整个人都是懵逼状态。话说还是北京厉害，甲流 500 万，新冠 100 万。

@HappyFox 感谢建议，症状再持续就去医院了。

@irever 听说最近又是一波

@showonder 是的，药我先停了，这次不对劲。症状再持续就去医院检查。

@clhlc 嗯嗯，我吃着感觉不对劲就停药了，症状再持续就去医院了。

@seedhk
1.数据修改只能是通过待更新标记再重新同步。
2.但假如你使用 OLAP 数据库，比如 ClickHouse ，就像我之前说过的要注意是否有时不时的数据更新操作，如果有则不推荐。因为更新操作会引起索引重建，严重影响性能。非要更新的话也得是批量更新，数据更新及时性会受影响。我们之前的业务比如广告埋点，发送短信等这些数据插入/查询的业务每天几个亿数据，做数据分析连表查询性能很高，美滋滋。

@adoal 别盯着笔误挑毛病，我写成 abc 他那不还是不行？最烦你这种人，啥方案提供不了就知道挑别人毛病。你觉得你行就给人家一个方案，觉得我说的方案不行就指出哪里不行。逼逼赖赖显你有嘴了。

@seedhk

1.这个需要你们去分析。可以将关联查询出来的数据结果集作为一个大宽表同步到 ES 的索引中，这个大宽表可能有很多字段；也可以在后端业务逻辑中将需要的条件提前准备好了直接传递给 ES （如果被 jion 的表查询很快的话）；还有一种是 ES 的索引间关联查询也可以。
2.有一个数据同步中间件 datax ，可以将 Mysql 的表数据同步到各种其他数据库。
4.我感觉是哪个工作量相对小就将哪一个迁出，目标就是避免影响到核心业务。
10.还有一种查询是各种聚合查询，针对于各种大数据量下的 count 语句，那 ClickHouse 特别合适，不过使用他是有条件的，只有写入和查询的话可以使用。
11.前端页面上点击查询一时半会返回不了就不要再发送相同请求了

整体上我感觉就是现在的 Mysql 满足不了复杂的查询业务，把整个服务拖垮了，并发量其实并不高。最要紧的是把 1 和 4 搞定，其他的 6,11 同步做。不过，这么一搞就把技术复杂度提上去了，新增了 ES 和消息。

@YiXinCoding 感谢🙏 豁然开朗

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 组织使用，应该怎么设计呢？

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

埋点数据放 ch ，从 ch 中定时统计出来的数据放 mysql 方便查询，美滋滋。

感觉具体得看什么属性的数据。
1.如果是共享数据，如果不锁住读取的表内容，就会有并发导致的数据不正确的风险。可以在数据库中加一个乐观锁/悲观锁。
2.不是共享数据，串行化就 ok

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

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