这个基本方案可以从两个角度刷亮点：
第一个角度是结合主键生成策略，优化中间表的设计
在设计订单主键的时候，将买家ID编码放到了订单ID里，中间表里就可以考虑删除买家ID列。
第二个角度是讨论中间表的缺陷，最大的缺陷是性能瓶颈
这个方案的一个重大缺陷是中间表的性能瓶颈。如果中间表的数据只插入，不存在更新的话，主要是读瓶颈，那么多加几个从库就可以解决；但是如果中间表的一些列是需要频繁被更新的，那么中间表本身就扛不住写压力，但是中间表是不能分库分表的，因为分库分表后不知道该查询哪张中间表。
中间表最让人害怕的就是写瓶颈，可以考虑提供一个解决方案：
一般来说，在设计中间表的时候就应该包含尽可能少的列，而且这些列的值应该尽可能不变，会频繁更新的列就不要放了。比如 订单ID这种ID列的基本不会变，状态这种经常变更的就不要放了。
中间表还有两个明显的缺陷：难以适应灵活多变的查询场景，还有数据一致性问题。
中间表还有一个缺陷就是表结构很固定，如果将来需要支持新的查询场景，必须要修改中间表的表结构，大多数情况下会增加新的列。另一方面，中间表本身往往是一个大表，大表改表结构是一个非常危险的事情，当然也可以考虑增加新的中间表，但是治标不治本，而且中间表越多越难维护，数据一致性越难保证。
进一步思考，中间表要想解决写瓶颈，是不是也可以分库分表？
