首先...数据库是不是 mysql?
如果是...抬走！

数据库 join 改为代码 join
优点:笛卡尔积优化为 hash(你写个双重循环当我没说);硬盘查找变为内存查找;可跨库关联且不限制数据来源;可使用缓存优化性能
缺点:需要更多内存;数据库事务失效需要自己实现分布式事务或者不使用事务

个人经验, 外键设置正常, 不会很慢
1 走索引: 业务上绝大部分查询, 都是使用唯一单号(运单号, 订单号, 产品 sku 等)或者时间, 这些字段设置好索引, 就挺快
2 只取要用的字段: 分两步, 第一步是获取当前页的 id, 第二步是针对这一页的 id, 再查询数据.
3 减少查询次数: 一页 100 条数据, 不要每个字段都是 1 个 sql, 同一字段的可以一个 sql 生成字典

技术上这种详情表再关联订单表进行某字段搜索查询确实很慢，最简单的方法就是做冗余，大胆一点就单独拉一张宽表专门搜索数据双写。
要么改下页面设计，比如让产品重新设计页面拆分一些到不同的查询表单中，尽量避免少的联表

最常用的做法是：

特大数据量的表，按时间做 partition 分表。
查询时分时段查询，再汇总到周、月、年，一级一级汇总。

这种上 es 吧

erp 很难

表现在客户查询条件巴不得每个字段都可以用来查询

报表页面必须有小计总计, 使得优化困难

数据一定要实时性, 高度要求数据正确

数据查看需要各种制约,比方说按地区/员工/合作伙伴/部门等等, 不得不联表

当然,这些还仅仅是 erp 变态需求中的一部分

我一直以为是我使用数据库的方法有问题，原来大家也都会遇到类似的问题。不过这里想问问，所谓的查询速度快是多快呢？

对于内部用户，我认为百万级的多个表关联（例如 10 张表），返回 100 条以内的数据的响应时间在 3 秒内算是可以接受。如果面向 toB 用户，那么秒级差不多；而面向 toC 用户，大概要在 100 ms 这个水平？

先看你 pg 硬件配置，我们公司一个表几亿的，pg 连几十个表没什么问题，ssd 的还要做好数据库参数优化，要改成适合 ssd 的参数，让 sql 能走合理的索引，连表关键要看索引是否合理，对应表要看具体业务场景，有时间纬度的可以按时间分区。数据库内存 等参数要合理分配

分库分表，数据缓存，读写分离之类的没什么好说的，
提供一种冷热分离的思路，我们项目中每天凌晨会有一个定时任务，把 7 天前的交易数据压缩为 zip 上传到 Blob 上
7 天内的数据自动查 DB 表，7 天以前的数据都会从 Blob 上下载下来读取到内存后再返回给前台画面
Blob 速度也挺快的，目前系统一切都很正常