golang 吧，我一个 Java 程序员都觉得 go 无敌

@Lax 数据量太大，单条 sql 撸不出来

@james2013 老哥，我 22 岁，10105，能撑多久

@youyelan9527
@Youngxj

压力太大吗


@gaigechunfeng 阿里都进不去

@oneonesv
@nosay
@cmobiooo
不正常的，我扫地的时候全是头发，包括浴室角落也是
发际线高了很多，发量跟之前相比也少了很多
在想是不是来到这个公司压力比较大，心态不太好

@sun1993 AopContext.currentProxy() 可以解决同类内调用事务 aop 代理不生效问题，我这种方法其实类似二段式，存在 updateB 成功了，但是 updateA 在 commit 失败了的问题，以及二段式的阻塞问题跟过于保守的问题，如果不在意性能的话，我觉得这种处理是没问题的，毕竟完全保证一致性无法通过简单的方法去实现。


@pws22 将 updateB 放在另一个类或者 AopContext.currentProxy()可以解决，我在代码注释已经加了的


@HiShan 如果不在性能的话，我简单这种方案是可以的，只要最终一致性可以通过 mq 来实现。


@q4487979711 这个我还没研究过，晚点有空看下


@Aruforce 两个数据源对应两个事务管理器的


@HiShan 先 mark，晚点看下


@hantsy 我昨天看了一种好像叫做 TCC 的方案，也是补偿的方案

@optional 可以具体说说吗

直接堆开发文档就可以了，我记得服务端只需要写登录接口，小程序端调用即可

@mccreefei 或者你的意思是回表查询的时候不会走主键索引

@NizumaEiji explain 出来的结果一模一样的

@mccreefei 按这么说，主键也是有索引的，那根据主键索引回表一次这么慢？我加了一条附言，你看下

@mccreefei type 跟 status 都有单列索引，问题的关键在雨多查一个 user_id 为什么回表查一次慢这么多

@NizumaEiji 第一条因为 id 是 primary key 不需要回表，所以很快，第二条 user_id，需要多回表查一次，但是回表一次为什么这么慢

@arrow8899
我实际的 sql 是这样的
```
select id from xxx.xxx where type = 12 and status in (11,12,13) limit 300000,500;
```
```
select id,user_idfrom xxx.xxx where type = 12 and status in (11,12,13) limit 300000,500;
```

这个表数据量 7000w+，第一条 sql 查询可能 100ms+，第二条 sql 得将近 1min

我想这是为什么

@lllllliu 我的想法是按 15s,15s,1min,3min,10min,30min,30min...这种频率来回调，超过一天即判定失败

@ivlioioilvi 怎么迁喔？你的博客有点骚兄弟

@cmonkey H 哈哈楼下有小伙伴说了
@83f420984 接下来怎么打算

@liuhuansir 已经收到了 offer

@Justin13 没资本这么浪，最多回家呆几天

我现在公司四年线程进程分不清，get posh 区别说不出，上班刷水，代码出 bug 笑嘻嘻滑过去，其实都差不多吧，往大平台上靠就能避开吧...