14 | 订单数据越来越多，数据库越来越慢该怎么办？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何处理订单数据持续增长导致数据库性能下降的问题。作者首先解释了数据库性能问题的根本原因，即查找时间复杂度和数据总量。针对海量数据导致存储系统慢的问题，作者提出了“分片”思想，即将一大坨数据拆分成N个小坨，以提升查找性能。针对订单数据的情况，文章介绍了归档历史订单数据以提升查询性能的方法。通过将历史订单数据移到另外一张历史订单表中，可以减少新数据的数据量，从而提升查询速度。文章还详细描述了归档历史订单的流程，包括创建历史订单表、迁移数据、测试新版本代码等步骤。此外，文章还介绍了如何批量删除大量数据，并对删除SQL进行了优化。最后，文章强调了对线上业务影响的最小化和数据迁移过程中的注意事项。整体而言，本文通过实际案例和详细步骤，为读者提供了解决订单数据持续增长导致数据库性能下降问题的有效方法。
《后端存储实战课》，新⼈⾸单¥59
全部留言(41)
- 最新
- 精选
李玥置顶Hi，我是李玥。 这里回顾一下上节课的思考题： 课后请你想一下，复制状态机除了用于数据库的备份和复制以外，在计算机技术领域，还有哪些地方也用到了复制状态机？欢迎你在留言区与我讨论。感谢你的阅读，如果你觉得今天的内容对你有帮助，也欢迎把它分享给你的朋友。 复制状态机的应用是非常广泛的，比如说现在很火的区块链技术，也是借鉴了复制状态机理论，它的链，或者说是账本就是操作日志，每个人的钱包，就是状态。它只要保证账本一旦记录后就不会被篡改，那在任何人的电脑上，计算出来的钱包就都是一样的。2020-03-3031
约书亚如果不进行OPTIMIZE，想通过历史表来提升性能的目的岂不是达不到了？作者回复: 不执行OPTIMIZE也是可以提升性能的。数据和索引虽然在物理上没有删除，但逻辑上已经删除掉了，执行查询操作的时候，并不会去访问这些已经删除的数据。 比如，原来有100条数据，删除完成后剩了10条。虽然100条数据都在磁盘文件中，但这时候执行一次全表扫描，MySQL只会访问剩下的10条数据。
2020-03-28333
AI一下子和Java的GC算法产生了共鸣。 创建新表的方式，只复制少部分数据，效率更高，但你要能接受这段时间的STW。这是复制算法。 历史归档，删除数据的方式，会产生碎片，利用率低。只有到空间不足的情况下，才进行压缩整理（OPTIMIZE）。这是标记清理算法，关键时刻再整理（STW），CMS GC就是这个思路。作者回复: 是的，磁盘碎片和内存碎片产生的原因是一样的，所以清理的思路很多都是相似的。
2020-04-27332
刘楠alter table A engine=InnoDB 命令来重建这样也能达到释放空间的效果吧作者回复: 是可以的。
2020-03-28611
乖，摸摸头按时间分库分表一直有个疑惑， 按月进行分表， 有几个月数据很小，有几个月数据特别大，这种会怎么处理作者回复: 这种情况可能就不适合按月来分片。
2020-05-128
王老师，什么情况下需要归档，什么情况需要分库分表呢？有什么具体的指标吗？作者回复: 我个人的建议是，如果归档能解决问题，就不要分库分表。我们下节课会详细讲讲分库分表。
2020-03-2825
怀朔比这个删除规律 是不是有问题啊？ 1、创建temp表 2、把历史数据迁移老表 3、check历史数据条数 4、删除老数据？ 按照老师的方法 在rename 之前 插入之后 这时候有数据进来 数据会丢在老表里面了？作者回复: 所以我们说，这个方案的前提是必须得停机操作。
2020-03-2834
lesserror老师，您的这句话：“其实每次都排序是没必要的，所以我们可以先通过一次查询，找到符合条件的历史订单中最大的那个订单 ID，然后在删除语句中把删除的条件转换成按主键删除。” 事实上每次，都做了排序啊？为什么说没必要呢？作者回复: 这个地方改为：“其实没有必要每次都按照timestamp比较订单”。我联系编辑小姐姐修改，感谢你的问题！
2020-05-242
特种流氓最近的订单表往归档表挪数据的过程中可能一份数据在两张表都存在 这个时候用户查询全部订单的时候是否我们在应用利用是用去重去剔除重复数据作者回复: 如果要同时查二个表，那合并和去重就在所难免。一般情况下，最好能设计好业务逻辑，尽量不要同时查当前和历史表。
2020-03-292
Panmax最后一种方案中（重建一张新的订单表），最后不应该把 orders_to_be_droppd 表删掉吧，删掉之后历史数据就丢了。作者回复: 这个可以灵活处理。
2020-04-021
