对 Range 分区表执行分区拆分操作，TiDB 能否自动完成数据重分布，会不会影响线上业务读写？
能自动完成。
默认的 reorg 参数并发较小，对业务一般不会有明显影响。
TiDB 在 7.0 版本开始支持 REORGANIZE PARTITION 语句，用这个命令来拆分分区的话，数据重分布是自动的，不用手动迁移。你只需要执行 ALTER TABLE 命令，TiDB 会在后台把原分区中的数据按照新的边界自动分配到各个新分区去。
对线上的影响：不会导致业务停机，但性能会有明显影响。
TiDB 用的是在线 DDL，所以你的 SELECT、INSERT、UPDATE 这些操作理论上都能继续跑。但现实情况是：
1、写入延迟会明显上升：分区重整过程中涉及大量数据移动和写入，会占用 TiDB 和 TiKV 的资源
2、吞吐量会下降：这个时间段内的吞吐肯定会比平时低
3、可能会遇到元数据锁等待：如果这个时候还有长事务在跑（比如某个大查询还没完成），DDL 的元数据切换阶段就会被卡住，整个操作时间会更长
所以建议是尽量在业务低峰期做这个操作，比如夜间，给 DDL 足够的资源空间。数据量大的话（GB 级别），可能需要十几分钟到几十分钟，这期间业务会感受到性能下降。
2 个赞
自动完成分布，性能视数据量略有影响，很大的话，还是建议低峰期实施。
肯定能自动完成的，对读写肯定有一定的影响。
- TiDB 会后台自动完成分区数据 Region 重分布；
- 元数据瞬时短锁，迁移阶段不阻塞读写，但会占用机器资源，高峰易抬高延迟、锁冲突；
- 建议低峰执行，可暂停 PD 调度、限速搬迁、预拆分 Region 降风险。
** 能自动完成数据重分布；分区拆分（Reorganize Partition）会短暂锁元数据、有少量 IO 与调度开销，正常线上读写基本不阻塞、影响可控。
TiDB 的兼容性跟执行计划的生成机制有关，同样的 SQL 在 MySQL 和 TiDB 上的优化器决策可能不同，特别是子查询和 JOIN 的处理方式。迁移前建议用 SQL Plan Management 做下 SQL 兼容性扫描。
分区拆分无需手动迁移数据，TiDB 会后台自动重分布数据。操作不阻塞业务读写，但会占用资源、小幅影响性能，建议低峰时段执行。
跨大版本逐步升级，跳版本容易出兼容性问题。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。