产品上线也一年多了，目前数据表中的数据越来越多。由于之前开发的时候，为了追求尽快上线，没有做好长期规划，完全使用了数据模型来进行操作，导致现在需要分表的时候发现难以下手。
产品是用 tp5 开发的，tp 文档里是有支持分表功能的，但是功能实在是比较弱，无法满足需求。
这个时候就需要考虑自己去改造业务代码。
主要需要切分的有用户表、订单表、订单评论表
其实直接拆分一个表，还是困难不大。但是之前都是用数据模型来操作数据库，如果要拆表的话，发现数据模型改造起来成本太高，需要对架构进行修改。鉴于尽量不修改框架本身的原则，不得不放弃，只能用查询构造器了。
因为拆表，带来各种的关联也是更加复杂。比如订单评论表本身需要关联订单信息，所以在在每个评论表里都增加 part 和 partId 字段。
同时用户表的改造带来的问题更多，因为用户表在八成的业务中都用到了，这就意味着带来更多的业务量。幸好之前有一定的封装，但是由于数据模型的操作是利用对象，查询构造器利用是数组，所以需要把所有用户信息修改的地方全部改掉。
最头疼的地方是，分表是基于项目 ID、用户 ID 进行拆分的，但是有时候需要根据项目表其他字段进行查询的时候，带来的问题就是没有办法在一个表内查询到所有数据。那么我需要再根据要查询的字段再做一个映射表。这样做不但增加了大量的 sql 查询，程序复杂度也大大增加。
但是我哪怕是做了这个映射表，还是有没有解决的问题。
一旦我需要 join 查询的时候，映射表就用不到了。这个时候，我只能分别查询所有子表，然后将数据进行整合。
数据库用的阿里云 RDS，不支持 mrg_myisam(merge)引擎。而且因为考虑到事务的支持，也不考虑 mysql 引擎。
所以在这里有这几个疑问：
1、一个听起来很简单的拆表，带来的工作量是不拆表的三到四倍。我实在是想不到有什么更好的办法可以解决这个问题了，希望能够得到大家的意见或者成熟解决方案。
2、我也查看了一下其他框架对于分表的支持，发现主流框架对于分表支持都不是不友好，那到底利用框架开发的产品，到底能不能支撑起单表超过千万的业务？
3、如果自己去写一个框架的话，从框架层面，根据自己的业务需求直接解决分表问题就轻松的多了。很好奇是不是大公司都会在数据量到达一定规模的时候，完全放弃通用框架，根据自身业务开发一个框架来重构产品？
我们产品现在数据量还是几百万，没有达到千万，但是按照现在的数组增长曲线，过千万不会太久。目前产品功能基本上已经定型，问题就是即将面临的性能问题，我是想趁着现在数据量还不大，不会有太大改动成本，提前把改造完成，然后这个产品就可以保持长久一段时间内不改动了，所以不适用于“过早优化是万恶之源”理论，希望大家勿喷。
1
Select Language