如何解决数据关联查询

在传统数据库查询时，如果要获取的字段在别的库表中，通常会使用join操作获得，但是当数据量越来越大时，join操作会使查询速度越来越慢，这显然是不可取的，那么我们该如何进行查询呢？

调用接口补填数据

在微服务环境下，各个微服务在业务进行过程需要进行的各种查询，由于数据库的拆分，其实不能像以前那样进行 join 操作了，而是需要采用接口调用的方式进行数据补填。比如电商平台中“用户下单”“商家接单”“物流配送”等微服务，由于数据库的拆分，它们已经没有访问用户表与商家表的权限，就不能像以往那样进行 join 操作了。这时，需要重构查询的过程

查询订单数据，但不执行 join 操作。这样的查询结果可能有 1 万条，但通过翻页，返回给微服务的只是那一页的 20 条数据
再通过调用“用户注册”与“商家管理”微服务的相关接口，实现对用户与商家数据的补填

这种方式，既解决了跨库关联查询的问题，又提高了海量数据下的查询效率。通过分页后的数据补填，就能有效地提高查询性能

适当增加冗余

在查询订单时，如果要通过用户姓名、联系电话进行过滤，然后再查询时，又该如何设计呢？注意：这里千万不能先过滤用户数据，再去查询订单

我们过去的数据库设计采用的都是3NF（第 3 范式）

第一范式(确保每列保持原子性)
第二范式(确保表中的每列都和主键相关)
第三范式(确保每列都和主键列直接相关,而不是间接相关)

比如在设计一个订单数据表的时候，可以将用户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于用户其它信息（比如姓名、所属公司等）的字段

它能够帮助我们减少数据冗余，然而却带来了频繁的 join 操作，降低了查询性能。因此，为了提升海量数据的查询性能，适当增加冗余，即在订单表中增加用户姓名、联系电话等字段。这样，在查询时直接过滤订单表就好了，查询性能就得到了提高

宽表设计

最后，当系统要在某些查询模块进行订单查询时，可能对各个字段都需要进行过滤查询。这时就不再采用数据补填的方式，而是利用 NoSQL 的特性，采用“宽表”的设计。按照这种设计思路，当系统通过读写分离从生产库批量导入查询库时，提前进行 join 操作，然后将 join 以后的数据，直接写入查询库的一个表中。由于这个表比一般的表字段更多，因此被称为“宽表”

由于 NoSQL 独有的特性，为空的字段是不占用空间的，因此字段再多都不影响查询性能。这样，在日后的查询时，就不再需要 join 操作，而是直接在这个单表中进行各种过滤、各种查询，从而在海量历史数据中实现秒级查询。因此，“订单查询”微服务在数据库设计时，就可以通过NoSQL 数据库建立宽表，从而实现高效的数据查询