新订单号设计和数据迁移方案

解决目前现有订单详情表数据过大(订单有700万，详情大概1.5亿多条数据) 所以要设计分表和新的订单号

新订单号规则

例：BCDE11904010001

(BCDE 1 190401 0001)

第1位到4位(4位)

站点信息

目前31404 100万个站点

按照22进制，去掉了I O Q Z，把Q作为前面补零的标识

Z 是用户自定义必须用到的前缀。用来表示用户自定义订单号，我们本身的不会用

第5位(1位)

订单类型(1:PL,2:LK)

第6位到11位(6位)

时间信息

年月日

190401

第12位到15位(至少4位)

一天一个站点所下的订单量每天从0递增

采用一张mysql表给每个站点自增每天订单

2019-03-01 - 2019-04-01 507204

2019-02-01 - 2019-03-01 278192

2019-01-01 - 2019-02-01 411354

2018-12-01 - 2019-01-01 424430

2018-11-01 - 2018-12-01 430673

2018-10-01 - 2018-11-01 395830

2018-09-01 - 2018-10-01 373932

2018-08-01 - 2018-09-01 395830

2018-07-01 - 2018-08-01 306296

2018-06-01 - 2018-07-01 318979

2018-05-01 - 2018-06-01 322916

2018-04-01 - 2018-05-01 272587

2018-03-01 - 2018-04-01 269680

2018-02-01 - 2018-03-01 135126

2018-01-01 - 2018-02-01 251980

分表方案

按照目前的订单
采用一个月分一张表，把后面月数的表，都先建起
1年一个库，每个库里面存放上面每个月份的三张表
mysql
  order_2019
    tbl_order_201904
    tbl_order_detail_201904
    tbl_order_serial_201904
  order
    tbl_order_id_inc
mongo
    order_relation

order_relation，绑定新老订单的关系。放到mongo

order_relation
id
order_id                        系统内部订单
order_id_alias          对外订单别名，旧的存PL0001这种，新的存用户自定义别名
station_id                  站点
group_id                        
create_time                 创建时间
modify_time                 修改时间
delete_time                 删除时间
pstatus                         物理删除状态

索引
order_id
station_id_order_id_alias   唯一索引

tbl_order_id_inc

 CREATE TABLE `tbl_order_id_inc` (
     `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
     `station_id` varchar(20) NOT NULL COMMENT '站点id',
     `num` varchar(10) NOT NULL  COMMENT '订单号自增数',
     `create_day` date NOT NULL  COMMENT '创建日期，每天会有每个station对应的id增长数',
     `create_time` datetime NOT NULL COMMENT '创建时间',
     `modify_time` datetime NOT NULL COMMENT '最后修改时间',
     `extra3` int(11) NOT NULL DEFAULT '0',
     `extra4` varchar(128) NOT NULL DEFAULT '',
     PRIMARY KEY (`id`),
     KEY `station_id` (`station_id`),
 ) ENGINE=InnoDB;

实行步骤(相关方案在订单重构3期.md )

1. 上一个版本
   1. 新的订单生成器
   2. 写order_relation 这个表，把新生成的订单写到这张表
   3. 修改station，manage关于订单修改的脚本和order服务的代码，改成双写
   4. 标识新老站点，通过给老站点加一个标识字段，让新的站点展示最新的系统订单号
   5. 确定别的绑定订单id的表，长度是否够用
2. 编写脚本(和上一步同步进行)
   1. 把历史数据同步到mysql，检查两边数据，保证两边数据一致
   2. 按照1年一个库，每个库里面存放上面每个月份的三张表
   3. order_relation 刷历史数据到这张表
3. 再上一个版本
   1. 把查mongo的操作改成mysql，检查mysql设计的表字段是否完整
   2. 按照分库分表的逻辑查询，要兼容新老订单的查询
   3. 查询按照系统订单号直接查对应的表，对外订单号查order_relation表，再查对应的表
4. 最后过一段时间，上一个版本
   1. 删掉双写的代码

规划

时间	任务	规划人员
4月11号-4月18号(6天)	上面的版本一订单生成器（1天） station、ma双写（2天） order对应的双写(3天)	儒端
4月19号-4月23号(3天)	测试、灰度客户	李铭
到4月23号(9天)	导数据到test机器编写验证数据脚本，检查数据是否完整和一致	文峰
4月24号-4月30号(5天)	把station、ma、order对应的查询改到mysql 期间检查数据完整性的脚本一直运行	儒端
5月5号-5月9号(5天)	测试、灰度客户	李铭
最后	抽个时间，上个版本，把双写的逻辑去掉	儒端

新订单号设计和数据迁移方案