不要想十年后，考虑明天怎么过就行了，想十年后只会增加你的焦虑而已。另外对于生活而言，不要把收入作为唯一指标去衡量，不然你只会在内心深处觉得自己是个失败者，因为永远有同学或者朋友之前不如你，现在赚得比你多，内心严重失衡，人生不是线性的。

感谢大家的回复。这个贴子的初衷更多的是一种对自己状态的一种吐槽。大家说的各种道理其实自己心理都明白，只是真正在面对现实的时候，有一种理想和现实巨大落差的无力感和失败感。坚持一条路走到黑或者换条路终究都是选择问题，但自己缺乏的不是选择，而是行动的问题。

情况差不多，最近找了一下工作，还是多背八股吧，我的感受

以前用到过，理念还是很好的，但是学习成本是高

类似的情况，我已经主动走了，这种事也没啥对错，立场不同而已，如果想留下来就和领导聊一下或者不再叛逆，按照领导要求做即可，如果心理状态调整不过来，导致长期失眠压力大，那还是离开吧

太正常了，靠说是没有用的。如果你要要求他的代码达到你预期的整洁度，那只能来硬的，不达到要求的代码不允许 merge 。不然以我的经验来看，你再强调多少次，他还是原样，一是没有这个意识，觉得代码能跑就行，二是不照你说的做，也没有啥惩罚，无所谓。

首先需要对这个产品的未来达成一致，也就是未来我们会怎么样做，这样聊起来会有效率不少，但往往现实是产品翻译一个业务需求，研发翻译一下产品需求写成代码，一旦代码不容易实现或者有其它问题，研发一般都会抱怨：产品这样要求的

一般我听到 DDD 无非两种场合，1. 新领导空降来指点江山的时候用 2.项目要重构的时候说 DDD 有多么的好。 但是最终执行出来的往往还是分层模型，我觉得 DDD 理念很好，价值也有，但是必须要在一个大的团队里至上而下的都能理解和执行才能造得出来，不然就是感觉在吹牛逼了。

@jenlors 空降啊，一般是同事之类的

@zhangchongjie 我没上去是因为第一任 leader 最终没有升上去，然后被调离养老去了。

和我一模一样~~

如果确定是 SQL 查询的结果太大导致的，可以看一下数据库的日志，比如慢查询日志，有记录数据大小的。
或者如果用的是 druid 连接池，打开监控也能看到相关 SQL 的处理信息。
如果不是 SQL 导致的，那就是应用程序实现的问题了，可以试试用 arthas 线上排查一下。哪个请求报的 OOM 应该知道吧。

....我才入了一台 16 寸的

前天才下单 16 寸低配官翻

秒级扫表把需要处理的用户放入队列里串行处理

sharding 的方案优缺点还是比较明显的，我现在接手的就是用的 sharding，主要是按 sharding 的方式跑数据处理，提高效率，但是数据量上来后，需要扩容再多 sharding 点表成本就很高了。另外报表查询也是个突出的问题。所以最近也在选型，我目前倾向于用 spark-sql 批处理，汇总数据再导入 mysql 或者 hbase 吧。tidb 不敢用的原因还是因为不了解，怕当小白鼠。

lz 你那样测试肯定测试不出来啊，这语句执行那么快，等不到锁超时的

我觉得会死锁啊，会竞争 X 锁啊。你开两个事务，start transaction 手动测试就知道了啊。
看之前的回答我还怀疑自己，测试了下：
Trx id counter 101931
Purge done for trx's n:o < 101930 undo n:o < 0 state: running but idle
History list length 11
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 101930, ACTIVE 16 sec
2 lock struct(s), heap size 1136, 1 row lock(s), undo log entries 1
MySQL thread id 13, OS thread handle 19224, query id 835 localhost ::1 root starting
show engine innodb status
---TRANSACTION 101928, ACTIVE 107 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 3 row lock(s)
MySQL thread id 14, OS thread handle 1736, query id 834 localhost ::1 root Searching rows for update
update user set id = 1 where name = 'aa'
------- TRX HAS BEEN WAITING 10 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 489 page no 3 n bits 72 index PRIMARY of table `orange`.`user` trx id 101928 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0