在项目里由你负责推进分库分表改造，你会按照怎样的步骤来实施？

回答思路

1. 【回答框架 1】先做现状评估与目标确认。梳理业务量、数据量、读写比例、慢查询和容量瓶颈，明确分库分表要解决的扩展性问题，并确认非功能目标如吞吐、延迟、可用性。同时评估团队对中间件的熟悉度和运维能力。
2. 【回答框架 2】再设计分片方案。根据业务特点选择分片键，优先选高频查询且分布均匀的字段，如订单号或用户ID；确定分库分表策略，常用哈希取模或范围分片，并规划分片数量要预留未来2到3年增长。还需明确数据分布和路由规则，考虑跨分片查询、聚合和事务的代价。
3. 【回答框架 3】选择中间件或自研方案。对比ShardingSphere、MyCat等中间件的功能、性能、社区活跃度和团队维护成本，或考虑使用云数据库的分布式版本。确定方案后搭建测试环境，进行功能验证和性能压测。
4. 【回答框架 4】制定数据迁移方案。根据业务容忍度选择停机迁移或在线迁移，在线迁移常用双写加历史数据同步，需设计校验机制保证数据一致性。制定灰度发布计划，先切读流量，再切写流量，并准备回滚方案，包括开关和逆向迁移。
5. 【回答框架 5】上线后持续监控和优化。监控分片数据均衡度、慢查询、连接池和中间件指标，建立告警。根据实际访问模式调整分片策略或增加缓存，还要定期进行数据一致性审计和容量规划。
6. 【关键点 1】分片键要选区分度高且覆盖核心查询场景的字段。
7. 【关键点 2】迁移前必须制定回滚方案，确保可逆。
8. 【关键点 3】跨分片查询和分布式事务是主要限制，需在设计阶段规避或接受代价。
9. 【关键点 4】中间件选型要考虑团队能力和运维成本，避免引入过重依赖。
10. 【易错点 1】误选分片键导致数据倾斜或热点，影响扩展效果。
11. 【易错点 2】在线迁移时忽视双写一致性和数据校验，导致数据错乱。
12. 【易错点 3】未预留分片数量，后续扩容需要重分布，成本高。