和我一模一样~~

如果确定是 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

描述得让人看不懂，建议直接贴 sql 和异常

@cnhongwei 谢谢，确实应该更多从业务角度考虑这个字段，不同场景去做取舍。

问题看来是 leader 没有话语权啊，这事儿跟前端后端没关系啊，公司内部 leader 没有话语权那肯定难受，领赏没有你，但背锅被甩锅肯定是第一位的，所以换 leader~~

刚入行就听组长的就好了，谦虚点，慢慢学。这么多人吐槽，就说明可能是你的思考方式有问题。感觉跟我认识的一个人好像，有个两年经验感觉就可以 diss 任何人，其实只是刚刚起步。

应该没到微服务的地步，拆分感觉只会加重你们的负担。重新梳理一下系统边界，把项目模块业务边界整理下，然后做些调整就好了，代价相应也比较小。

没办法，面试官就喜欢问这些，现状就是这样....

一般讲设计模式不都先讲 SOLID 原则么，没有接口或者抽象类，如何遵循这些原则呢？

你觉得对别人好的事，比如多学点东西，刚出来薪金不重要，多学习真本事之类的，都是你以为，在别人看来或者在年轻人看来，也许是负担。所以只交流工作就好了，额外的东西不要强加于人。

注释我不会嫌多的

我最近也打算成都买，用的购房通那个小程序，还算可以