详情
在拆分之前，我们系统中很多列表和详情所需要的数据大部分从多张表中获取的，这个时候我们使用 join 操作即可。但是分库分表后，这些表可能会被分散在多个库中，这个时候我们是无法进行 join 操作的。虽然 Sharding Sphere 支持跨库 join ，但是我们基于架构规范、安全、性能方面的考虑，我们都会强制禁止跨库 join 操作的。那怎么解决呢？有如下几种方案：
一、全局表 OR 数据冗余
为了避免 join 操作我们可以使用全局表，即一个表中存储所有需要查询的字段，这样我们就只需要查询这一张全局表了，而不需要执行 join 操作。比如在订单列表中，我们总是会显示用户名，这时我们可以在 t_order 表中冗余用户信息：
CREATE TABLE t_order (
order_id INT PRIMARY KEY,
user_id INT,
user_name VARCHAR(100), -- 冗余的用户信息
product_id INT
);
这样在查询订单列表时就不需要关联用户表了。
这种方案虽然能够减少 join 操作，但是它会增加存储，同时在新增、修改操作时也会带来额外的操作。
二、应用层 join
由应用层来执行 join 操作，具体步骤如下：
- 分布查询：查询各个分片的数据。即在各个库中查询各自的相关字段的数据
- 数据汇总：在应用层将各个分片数据进行汇总
- 手动 join：在应用层对各个分片数据进行匹配、合并、汇总
例如：假设有两个表 t_order 和 t_user 分别存储在不同的数据库实例中，且我们需要查询某个用户的订单信息。
// 根据用户id 查询用户的订单数据
List<Order> orders = orderService.getOrdersByUserId(userId);
// 查询用户信息
User user = userService.getUserById(userId);
// 组装数据
orders.forEach(order -> order.setUser(user));
三、利用 ElasticSearch
将所有需要查询的字段全部纳入到 ElasticSearch 中，利用 ElasticSearch 的宽表思想，将多张表中我们所需要的字段组成一个文档，这样我们就可以利用 ElasticSearch 来做一些大数据检索和复杂搜索的场景了。
最后
对于简单的列表查询或者详情查询时，大明哥推荐采用应用层 join 组装数据。而针对大数据检索和复杂的搜索场景下，大明哥还是力推 ElasticSearch。
对于数据冗余，这个哪怕不分库分表，我们也是可以做一些必要的冗余，这样能够极大地减轻我们的开发，减少不必要的 join 操作。当然，我们冗余的字段最好是一些不怎么变更的字段，如果经常变化的字段是没有必要进行冗余的。
