有点饭圈的味道了

直接问就好了，一般不会骗你，就怕你没问清楚，如果真的骗你了，上午入职下午离职就行。

- 这个岗位招聘多久了?
- 要求最快多久入职?
- 岗位的空缺是因为替换员工还是新增业务?
- 该岗位希望招募到的人解决什么样的问题?
- 该岗位所在的团队目前的经营情况是什么样子的?
- 觉得我哪方面是符合岗位要求的?

好早之前就下架了吧

一定要加唯一索引！

@garyxi24 应该在设计的时候就避免这种情况发生，可以设计为：
- 如果 b 服务中的数据是长期不变的，可以在 a 服务中冗余一些数据
- 如果 a 和 b 服务是属于同一种业务，那么就不应该拆分为两个服务
- 如果以上都不满足，大概率是需求或者设计有问题了，可以考虑用妥协的方案，比如：伪分页（不展示总数）、滚动搜索（不支持跳页，只能一页一页翻）

PS：实际上 es 的分页性能比数据库差很多，有分页需求肯定是不适合的，通常只用滚动搜索。

@garyxi24

现在很少写 join 和子查询，因为数据库基本都是分库分表，或者是微服务物理隔离的，所以 JPA 比较合适。

如果不是这种场景，需要手写复杂 SQL ，可以尝试一下 MyBatis 分页插件，比如：MyBatis-PageHelper 、MyBatis-Plus ，但是这俩插件在一些场景下可能会有 Bug ，而且代码质量也堪忧。

也可以参考我写的分页插件： https://github.com/yihleego/mypages
使用了 ANTLR4 分析语法树，支持多种使用场景。

可以试试 H2 ，是用 Java 实现的，虽然是关系型数据库。

我觉得 ORM 能解决你的痛点，比如 JPA ，而不是 MyBatis 。

像 Elasticsearch 这种，分页性能更差，基本上都不用分页，通常用滚动搜索。

你用习惯了 Java 再转 Go ，大概率很长一段时间都无法适应，尤其是生态方面。
如果说 Java 是全副武装的话，那么 Go 就只穿了条裤衩配了双拖鞋就上去干了。

显然，你自己心里是清楚的，不要抱侥幸心理，被抓到不仅可以开除你，还可以报警抓你。如果是仲裁收集证据，你大可以放到明面上来。

我不觉得 GitHub 一定要放对岗位有用的 repo ，上班已经写的够多了，下班还要写？饶了我吧。
并不是所有人都喜欢蹲 Bug 提 PR 硬蹭，难道平时写写自己喜欢的小工具和文档算减分项吗？对别的技术感兴趣，到你这怎么就变成一文不值了。我觉得对技术有热情就是好事，比那些下班回家一趟刷抖音的强多了。

不贴 GitHub ，不用 GitHub ，甚至都不知道 GitHub 的人，大部分对技术不感兴趣吧。

dynadot

互联网用数据库就存个数据，根本不用特性，计算都通过应用服务。
公司有一套 MySQL 的生态，而且开发者比较熟悉 MySQL ，也就没有理由换其他数据库了。
同理，如果有公司熟悉 PostgreSQL ，那他也没有理由换成 MySQL 。

除非 PostgreSQL 宣布下个版本支持高性能分布式，否则 MySQL 不会被替代。

不敢

我也卖一个 https://草.dev/

@wxf666 不会，多 join 一张表会有一点开销，但是不至于差；分库分表不允许使用 join 。

示例：user 、department 、user_department_rel 各 100 万条，共 300 万条数据，两张表联查和三张表联查的开销几乎无差别。

两张表联查结果：

test>
select *
from user u
join department d on u.department_id = d.id
where u.id = 100000
[2022-07-29 10:24:46] 1 row retrieved starting from 1 in 116 ms (execution: 76 ms, fetching: 40 ms)

test>
select *
from user u
join department d on u.department_id = d.id
where u.id > 100000
limit 10000,10
[2022-07-29 10:24:47] 10 rows retrieved starting from 1 in 127 ms (execution: 89 ms, fetching: 38 ms)

三张表联查结果：

test>
select *
from user u
join user_department_rel udr on u.id = udr.user_id
join department d on d.id = udr.department_id
where u.id = 100000
[2022-07-29 10:24:47] 1 row retrieved starting from 1 in 125 ms (execution: 76 ms, fetching: 49 ms)

test>
select *
from user u
join user_department_rel udr on u.id = udr.user_id
join department d on d.id = udr.department_id
where u.id > 100000
limit 10000,10
[2022-07-29 10:24:48] 10 rows retrieved starting from 1 in 138 ms (execution: 96 ms, fetching: 42 ms)

@wxf666 按我的理解，数据库范式只是一种建议，而且其过于学院派，并不适合所有实际场景。
尤其是互联网行业，更倾向于实用派，例如 MySQL ，其作用仅为储存数据，计算基本上都放在应用服务，有些公司的设计规范中，甚至连外键都禁止使用。

@wxf666
根据 OP 的业务场景，一般是如此。应该考虑到「用户系统」和「组织架构」的隔离性，即「用户系统」可以拆出来单独使用，「组织架构」也可以拆出来可以与其他的「用户系统」配合使用，而不需要改造代码（或者说只需要微调）。

如果是商品（ SPU ）和商品库存（ SKU ）这种业务，则应该用直接关联，如：在 sku 表中存 spu_id ，因为他们业务上本身就是强关联的，而且一般是处于同一个 domain 中。

@hahaFck
不推荐使用 join ，是因为互联网业务的很多场景下都可能无法使用 join ，例如：
- 微服务：物理隔离
- 分库分表：数据库实例不同
- 数据中台：数据存在中台，只能通过接口方案
- 更换数据库（多数据库）：去 Oracle 化、MySQL -> TiDB 、RBD -> KVDB 等，不同数据库语法可能不兼容。

如果没有使用 join ，只需要替换 Repository 层即可，如果使用的是 JPA ，甚至可以不改代码。