- 背景：
针对海量增长模式的行业关系型数据，往往采用分布式数据库模式，为了提升分布式数据库的高性能、高可靠性、高可扩展性生产要求，我们往往采用分库分表分片设计，实现业务数据的分片存储。在分片存储中，一般会采用分片键方式，指定某些字段为分片键字段，并通过分片键字段进行分片位置的定位，实现数据的快速读写。那么，在实际业务中，根据上篇所描述，业务实体之间往往存在关联关系，为了实现关联关系实体的快速查询定位，会建立分片键关系，实现实体间快速查找定位，那么，这种做法会带来另外一个问题：当其中一个分片键实体发生变更的时候，如以客户身份证编号为分片键时对所在身份证进行批量割接或者客户合并时，可能会产生大量的跨分片变更事务处理。
- 分析：
根据上述所述，针对分布式数据库中存在关联关系的分片键关系表，当其中一个分片键发生批量迁移时，则可能会造成批量跨分片变更事务处理，所以，为了避免实体表中分片键一处修改引起分片键关系表中多处跨分片修改事务，可以考虑增加分片键寻址表，用于跟踪实体表中分片键的变更轨迹。
例如，仍以客户资料表为例：
1）建客户分片表：
CREATE TABLE ` customer ` (
`customer_id` varchar(20) not NULL,
`field_1` varchar(20) DEFAULT NULL,
`field_2` int(11) DEFAULT '1',
`shard1` bigint(20) DEFAULT NULL,
PRIMARY KEY (`customer_id `)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
然后设置分片键及其分片算法
sharding @@table name=' customer ' set type='sharding' and sharding_func='shard-XXX-FUNC' and sharding_id='shard1' and dn='dn1…';
2）建客户关联关系分片表：
创建客户关联关系分片库表：
CREATE TABLE ` customer_rela ` (
`customer_id_a` varchar(20) not NULL, --关联的A端客户标识
`field_1` varchar(20) DEFAULT NULL,
`field_2` int(11) DEFAULT '1',
`shard1` bigint(20) DEFAULT NULL,--本表记录的分片键
`customer_id_z` varchar(20) not NULL, --关联的Z端客户标识
` customer_id_z_shard1 ` bigint(20) DEFAULT NULL,--关联的Z端客户所在分片键
PRIMARY KEY (`customer_id_a `,`customer_id_z `)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
然后设置关联表的分片键及其分片算法
sharding @@table name=' customer_rela ' set type='sharding' and sharding_func='shard-XXX-FUNC' and sharding_id='shard1' and dn='dn1…';
当需要创建两个客户的关联关系时，可以从两端分别创建两条记录，记录双向的关联关系，同时记录双方客户所在的分片键标识
3）增加客户寻址表customer_key_addr
CREATE TABLE ` customer_key_addr` (
`customer_id` varchar(20) not NULL, --当前客户标识
`newshard1` bigint(20) DEFAULT NULL, --当前客户分片键变更后的新的分片键
`shard1` bigint(20) DEFAULT NULL,--本表记录的原有分片键
PRIMARY KEY (`customer_id `)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
然后设置客户寻址表的分片键及其分片算法
sharding @@table name=' customer_key_addr ' set type='sharding' and sharding_func='shard-XXX-FUNC' and sharding_id='shard1' and dn='dn1…';
4）为了实现在寻址表场景下的客户信息快速方便查询，可以封装公共的客户资料查询方法：
首先根据客户标识以及分片键从客户表进行查询：
Select * from customer where shard1 = ? and customer_id = ？
如果上述记录是因为分片键变更处于已迁移注销状态，则再从客户寻址表中查找：
Select * from customer_key_addr where shard1 = ? and customer_id = ？
根据上述记录获取新的分片键标识，然后根据新分片键标识按照上述逻辑再从客户表中查找。
通过上述分片键寻址表方式，在用户对客户分片键进行变更时，可以实现对客户分片记录的快速追踪访问处理。
- 结尾：
在实际分布式大型应用中，业务实体数据之间关系非常复杂，而且变更频繁，那么，在海量数据的分库分表存储场景下，如何实现对分片数据的高效读写变更处理以及保持数据一致性显得尤为重要。本文通过分片键寻址表方式，进行分片键数据的追踪处理，即避免在分片键变更时可能引起大量跨分片事务处理，又能实现数据的快速追踪访问，提高应用系统读写效率。
