共计 950 个字符，预计需要花费 3 分钟才能阅读完成。
在理论开发过程中，应用例如 DDD 领 域模型充血计划或者为了数据模型更加的便于之后的拓展和解释，不便于也不倡议通过减少状态字段的形式解决问题，但同时下层业务有绝对比较复杂，就会存在数据模型与业务要求之间的适配问题，简单的业务可能提当初数据模型中须要用到多张表的联表查问状况，这类问题如何解决呢？
拆分形式
将本来一条 SQL 形式，查分为多步。多步能够是在 SQL 层面也能够是在程序层面。
有些业务状况是容许 通过多条 SQL 执行 的后果，在程序中进行拼装失去最终符合要求的后果集，在这里作者举荐尽可能在程序中解决，这样做的益处是缩小数据库的压力。
也能够 借助其余缓存中间件 ，例如 redis 将一部分数据事后解决好，查问 Redis 性能必定比数据库要好。
合并形式（读写拆散）
事后将所须要的后果集以冗余形式存储下来，程序只需查问该冗余数据汇合即可。
有的人会最先想到应用视图的形式去做，但理解视图的人都晓得，每次查问视图数据，仍旧会执行联表 SQL，不会起到性能晋升成果。
应用 缓存表形式 ，以 MySQL 为例，MySQL 有提供缓存表的实现，将指标数据先缓存到缓存表中，再查缓存表中数据。
同步数据到 ElasticSearch，查问 ElasticSearch 中的冗余数据 ，阿里 Canal 产品提供 MySQL 同步到 ElasticSearch 的实现，能够参考 Sync ES · alibaba/canal Wiki · GitHub。但该种计划往往存在提早的问题，仅适宜于对实时性有容忍度的场景中。
大数据 Spark / Flink 形式 ，以实时或者离线形式（实时性要求低）对多张指标表业务解决，长久化后果集，程序只需读取后果集中的数据。Flink 提供 Joining 计划，能够参考 Apache Flink 1.11 Documentation: Joining。
分库分表 + 主从形式 ，例如多租户的场景，租户之间数据隔离，咱们能够一主多从，一主用于写数据，多从别离依据租户拆分，各租户查问本人的从库。但该计划在程序实现方面会比较复杂，同时某个租户的数据量十分大还是会存在性能问题。
小结：该类形式往往是通过事件驱动形式实现，就会存在实时性和程序问题，在选型的时候，须要思考这方面的问题。以上提到的计划都仅仅适宜联表查问绝对简略的场景，如果存在子查问之类的简单要求，就无奈满足要求了。
