@user8341 四楼是我的方案的一个子集，不建议写两次，一般是主库通过同步工具同步到从库，然后主库和从库各自分库分表。
实际上，楼主这种业务场景，活动纬度的查询一般是商户分析使用，是不需要实时的。完全可以主库按用户纬度分表，然后由大数据的同事一天一次或者一小时一次增量读 /监听队列之内的方案来提供分析数据

楼主这种场景，一般用异构索引或者用双数据源。
我们公司的处理方案是后者，因为需要通过用户维度和活动维度两个维度查询，对于消费者来说必须实时查询，所以主数据源是用户 ID 来分表，然后通过同步工具或者直接双写将数据同步到另一个数据源，次数据源通过活动维度分表，因为活动维度分表是给商户分析用的，可以有延迟，甚至可以通过大数据批跑来实现。

动态链接用 API 网关就是了，干嘛用 cdn ？你这个估计是 cdn 的缓存预刷新

很多血淋淋的例子，非常建议楼主不要这么做，一旦因为楼主私自内存穿透搞出安全问题，轻则辞退，重则牢狱之灾。
有穿透需求的话就向公司正式提，走公司渠道搞堡垒机，千万别为了省事自己撘隧道，害人害己。

楼上正解，主要看业务场景。有的表仅仅是做存储几乎不读，简单搞个冷备份就行了。如果当前业务场景下性能没问题，就暂时没必要为了分库分表而分库分表，毕竟分库分表就意味着风险和代码重构。

搞 ip 代理池

甚至更甚一步，分享的内容直接以文本口令的形式替代，例如淘宝的分享口令。

@shintendo 你这个场景，最重要的是兼容性问题。大多数用户在分享图片时，是不会注意勾选发送原图的按钮。因此就必须考虑用户图片被压缩的情况。楼上方案中图片直接二维码包含链接的形式就很通用，比较适合这种场景。

去
1. 公司有工作氛围，没有太多的干扰
2. 和同事之间交流方便，减少很多交流成本
3. 在家办公，会很难区分工作时间和休息时间，最后在家办公比公司加班都狠

先晒一下 sql 和表索引结构，单 sql 耗时 1 秒还是挺久的

2. 执行命令`dstat 1`，监控一下压测期间服务器的 CPU,IO,网络,中断的数据情况

1. 输出红火图，查看应用 CPU 时间分片占用分布

以及执行一下命令`show global status like '%tmp%';`，看看临时表有多少次是创建了磁盘临时表。磁盘临时表会非常影响性能。

用 uid 索引，不慢才怪呢，会对 uid=726080 的所有记录回表。建议对 uid,ordertime,order_id 做联合索引，减少回表次数。

贴一下返回的报错报文以及 es 的报错日志

表结构和表数据量

mysql 如果是 innodb 引擎，内存主要都是被数据页缓存占用，可以通过参数 innodb_buffer_pool_size 来控制。相比之下，其他的内存占用都是零头。

部署个堡垒机，外网用堡垒机登录生产机器