@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

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

国内计算机非全不好搞。同一所学校，参加研究生入学考试的门槛比全日制略低或持平。有的学校过线就要，有的学校会刷人，刷人的依据主要是看复试的表现、有无编程基础、能否毕业。。。入学之后基本放养，但同时还要完成毕业论文毕业，这就很难了，挺多在这个点上放弃的。最后一点，现在非全不太受待见，但比之前几年情况好一些了。

@trzzzz thanks~

@trzzzz hi ，我还是没 get 到弱网环境下的问题。实际在上传时后端会维护一个 uploadId 下的已上传分片数组，客户端（我这边是 windows 客户端）会根据这个数组尝试重试机制。所以无论网络环境如何、是否是并发上传，只要客户端能正确处理这个数组就可以。

我的做法是：
1.前端做好分片，为每一个分片生成序号，统计分片的个数。将这些数据传给后端，后端把这些数据记录下来，为这个文件生成一个全局 id ，返回给前端。
2.前端每次上传分片会连带文件 id+分片 id 一起传过来。分片文件会被上传到一个临时目录。每上传完成一个分片，后端会记录下来分片 id （分片序号）。如果是并发上传的话，要注意已上传分片 id 集合会有线程安全问题，不然会出现某个分片已上传但没记录的问题。
3.后端返回已上传分片集合。同时会有一个异步线程判断该文件 id 下的分片是否全都上传完毕。如果全都上传完成，调用文件系统 SDK 的合并文件方法（我用的是 minio ），合并完成之后，删除临时文件目录的分片。
4.与此同时，前端全部分片上传完成之后，循环调用获取文件合并状态接口。
完成~