PG 百万数据就卡不应该吧 EXPLAIN 一下看看优化优化

百万就卡，要不先看看执行计划？

我们 PG 大表（千万、亿级）连太慢，现在说把 PG 同步到 Starrocks ，SR 大表关联性能还可以，缺点是他复杂查询性能好，简单查询不如 PG 、MySQL 这种关系型数据库

flink cdc 然后 join ，最后吧结果数据写到 es 。转批处理为流处理，upsert 保证数据一致性。 后台查询 es 大表，保证实时。

这不是搜索典型应用场景吗？上 ES

查询字段溶于一张表，详细表其余表走主键

用 cdc 预联表打宽做个新表，在新表上把联表查询改成单层的查询就行了，这个数据量延迟也就秒级

基于关系型数据库 能优化的：
1. 首次 fetch 只查 id ，根据 id 最后获取想要的数据
2. 部分冗余，部分卡顿场景具体分析解决
3. 分表，这个要针对业务场景了，有些情况要就是没法分的
4. 冷数据处理，比如几年前的数据，把它迁移走
5. 建立好索引，优化查询语句
基于 CDC：
1. 做个新的宽表，数据仍旧放在 PG
2. 新宽表放到 ES CH 等地方

要是挡不住这个需求的话，赶紧抽数据做宽表吧。

我们的更恶心，相当于要把“订单”、“收货单”、“入库单”、“退货单”等不同类型的单据强行抽象成同一种业务单据供分页查询，并且每个字段可筛选，充分迎合业务人员的需求“一个页面可以把所有事情都干了”。

其实这需求都还好... 最恶心的是产品没想清楚，就潦草设计快速上线，然后三天两头的加字段改字段、改抽象逻辑、刷历史数据，苦的都是开发、测试。

先查询主表 ，然后多线程查询 join 表，内存连接，如果存在 join 表条件就在这个 join 表的查询结果中过滤掉主表的记录