@Sasasu 请问下，这里的「卡很久」应该只是卡当前 session ？其他的读写请求也会阻塞？

@JasonLaw 且不说国外外键用得比较多作为「事实」成不成立吧（毕竟没有真实数据支撑）
就算事实成立，也顶多就说明国外小厂生态比较好，或者国外小厂程序员的社区活跃度比较高，总之我想和外键这一技术本身不会有太大关系

这个问题本身并不成立。
参考 https://github.com/github/gh-ost/issues/331#issuecomment-266027731，这个 issue 里提到 Github 从来不使用外键。
外键的使用并没有国内外之分，而更多和系统体量相关。大型微服务系统里几乎不会用到外键。

大部分垃圾代码就是「图个省事」带来的，写的人越省事，后续维护的人越蛋疼

不考虑现实？那只能学虚拟现实了 [doge]

这种是典型的反规范建模设计，本身是没错的，得看具体的业务场景。
但是 [用户 角色 权限] 这种系统设计，本来就是典型的规范建模，具体到数据库设计又变成反规范的，就有点奇怪了~

转语言没啥风险吧，后续找不到 node 岗，再转回 java 就是了，java 这种技术栈成熟的语言，隔个两三年也不会有太大的变化。
至于说语言两年不算精通的，只能表示无法赞同。语言这种东西够用就行，真没必要精通（也没几个人敢说自己精通...）况且一线大厂基本都支持转语言了，字节 golang 零经验拿 offer 的大有人在。语言真不是问题，数据库 /中间件 /架构设计 /业务思维 /沟通能力，才是大多数后端开发的瓶颈

我们的大概思路差不多，所有调用三方接口的收敛到一个服务，对内网服务暴露 RPC 接口。鉴权的话根据业务情况判断是否需要，需要的话用现成的 RPC 鉴权方案，也不复杂

选两三个感兴趣的语言，写个 demo 级的应用试试

静态语言 Jetbrains，动态语言 VsCode

@Bijiabo 确实

@cxytz01 太感谢您的回答了，正是我需要的。和我之前大概想的很相似，但是前辈的思路明显更加清晰，再次感谢～

@AngryPanda 前辈方便展开讲讲么

@litor 小厂确实易踩坑，祝好运

@timelessg 有明确目标就很好了，我没什么具体目标，只是不满意现状

@NotreDame 果然是围城了😂

核心也不是多维度查询的问题了，而是亿级数据 InnoDB 单表存储，完全是个不具备拓展性的方案。
建议先重新评审下需求，3 亿数据，却没有任何一个字段或元组可以作为主维度来进行查询，合理吗？
如果不合理，确定一个合理的主维度，做下分表，前端限制或默认带主维度进行查询就好了。
一般来说，99.9%的情况都是需求不合理，剩下 0.1%才是确实需要用 ES 或其他查询引擎来解决的场景。

华强北版 airpods 很香