非常庞大的数据可能会降低服务器的性能，因此有一种方法可以解决这一问题：
1） 必须使用存档存储机制创建另一个表来存储存档数据（旧数据）https://dev.mysql.com/doc/refman/8.0/en/archive-storage-engine.html )
2） 创建mysql作业/调度程序以将旧记录移动到存档表。当服务器处于最大空闲状态时，按时间段进行调度。
3） 将较旧的记录移动到存档表后，请重新索引原始表。
这将有助于提高绩效。

在我看来，一开始使用mysql的方式本身就有问题。
数据库系统应该管理应用程序工作所需的数据。如果你认为经常洗table是可以接受的，那么事实似乎并非如此。
也许你最好只使用日志文件。按日期拆分，如果确定旧的不再相关或需要磁盘空间，则删除旧的。从复苏的Angular 来看，这样做更安全。
如果你需要一个更好的建议，那就改进你的问题，把你想要达到的目标包括进去，这样我们就可以帮助你了。

1000行表的性能不太可能差到每隔一段时间进行一次表复制就可以获得总体净收益。不管怎样，新表有什么比旧表没有的更好的性能呢？
使表高效运行的关键是智能表设计和索引管理。这就是为什么无数行表在地理空间工作、图书馆目录、天文学以及互联网搜索引擎如何找到有用的数据等方面是有效的。
每个定义的索引都会对mysql产生更大的影响，尤其是在插入行时。假设读取比插入多，这是一个优势，因为大多数查询都是通过合适的索引快速完成的。
定义索引时，最好充分了解对表进行的查询的质量和数量。而且，如果查询的性质有几个月或几年的趋势，那么索引将需要添加、修改甚至删除。

首先，您讨论的是单个表的数TB。你的磁盘有那么大吗？是的，mysql可以处理这么大的表。
会慢下来吗？这取决于
索引。如果有“随机”索引 INSERTs 将减慢到每次磁盘命中1次插入。在一个旋转的硬盘上，这仅仅是大约每秒100次。ssd可能可以处理1000/秒。请提供 SHOW CREATE TABLE .
这张table有table吗 AUTO_INCREMENT ? 如果是这样，那就需要 BIGINT ，不是 INT . 但是，如果可能的话，把它全部去掉（以节省空间）。再一次，让我们看看 SHOW .
“点”查询（通过索引加载一行）通常不受表大小的影响。它们在万亿行表中的速度大约是在百万行表中的两倍。点查询将花费毫秒或数十毫秒；没什么大不了的。
表格扫描需要数小时或数天；希望你没有那样做。
除非您使用 PRIMARY KEY 或者有一个“覆盖”索引。让我们看看查询和 SHOW .
最好的方法是不存储数据。当它到达时进行汇总，保存汇总，然后抛出原始数据(好的，您可以将原始数据存储在csv文件中，以防需要构建新的摘要表或修复现有摘要表中的错误。）
使用一些摘要表代替原始数据会将数据压缩到1tb以下，并允许相关查询以10倍的速度运行(好的，点查询只会稍微快一点。） PARTITIONing （或者分开table）？视情况而定。让我们看看查询和 SHOW . 在很多情况下， PARTITIONing 不会加速任何事情。
是否要删除或修改现有行？我希望不是。这增加了问题的更多层面。另一方面，如果您需要清除“旧”数据，那么这对于 PARTITIONing . 为了3年的数据，我会 PARTITION BY RANGE(TO_DAYS(..)) 每个月都有分区。然后每月 DROP PARTITION 会很快的。