记一次mysql迁移的方案与遇到的坑

直接结论：TiDB 方案最可靠。
分表短期内可以用，但长期来看就麻烦了。
旧数据的备份仅限于非实时查询场景。

分表计划：
video_id 用作密钥。

3 年需要6 张表，每张表1 亿条数据。

代码需要修改，双重检查结果暂时合并。

旧数据同步需要旧表代码下线。

TiDB 解决方案：
无需分表，自动扩展。

双写同步旧数据。

主键冲突的坑是最致命的。

同步坑：
作业重新启动会导致数据重复。

与主键ID同步会与业务冲突。

最终方案：分1 0批同步，使用Redis记录断点，同步除主键外的所有字段。

结论：TiDB 方案避免了分表历史债，同步脚本优化解决了核心陷阱。

mysql的最大数据存储量是多少

结论：MySQL数据量没有硬性上限。

单个字段的长度是有限的，具体取决于数据类型。

表大小不要超过2 G，否则效率会很慢。
建议的子表。

表结构简单，承载数据量大。

测试表明在2 000万线（4 G）下运行良好。

优化后5 000万（1 0G）运行良好。

MySQL 是开源的。

快速、可靠且适应性强。

无业务需求，是内容管理的最佳选择。

为什么MySQL单表不能超过2000万行？

说到MySQL不建议单表超过2 000万行的问题，我在多年的经验中遇到过很多讨论。
说实话，这个问题并不能简单地用“原因1 +原因2 ”来解释清楚。
这在技术层面带来了许多限制，需要逐项分析。

首先我们来谈谈索引深度如何影响性能。
我记得过去增加索引深度会延长搜索路径并影响性能。
但随着SSD、大容量内存等硬件的进步，IO不再是限制。
MySQL 使用 B+ 树索引。
随着数据量的增加，B+树的高度也随之增加。
然而，现代硬件性能如此强大，以至于这个因素不再重要。

那么就要提到SMO（Structure-Modification-Operation）的并发控制问题。
InnoDB存储引擎在调整数据结构时，如节点分裂、合并等，需要并发控制。
乐观锁和悲观锁是两种方法。
对于乐观锁来说，只需要在叶子节点添加排它锁，只要B+树结构不改变即可。
然而，一旦触发SMO，就需要悲观锁。
这时必须遍历B+树，并锁定可修改的节点。
在此过程中，根节点持有SX锁，导致其他SMO任务等待，在高并发情况下形成性能瓶颈。

我们来谈谈InnoDB索引组织表的特点。
InnoDB中的叶子节点存储主键和相应的数据。
当节点存储的数据行数较少时，SMO的触发会更加频繁，从而加剧了SMO无法同时写入的缺陷。
相比之下，堆组织表（例如 GaussDB 中使用的表）将索引键和行指针存储在叶节点中，从而允许它们存储更多数据，从而减少 SMO 触发器。

我之前也参加过性能对比实验。
对于相同的数据量和业务并发量，B-LinkTree和堆组织表数据库（如GaussDB）的性能明显优于MySQL。
GaussDB可以稳定地提高TPS（每秒事务数），但是提高MySQL的并发数并不能显着提高TPS。

综上所述，MySQL不建议单表超过2 000万行的原因主要是由于索引深度、SMO并发控制问题以及InnoDB索引组织表的性质。
这些因素综合起来限制了大数据量并发修改的性能。
因此，如果单表数据量接近或超过2 000万行，表库拆分或者考虑使用不同的数据库系统可能是一个不错的选择。
我自己从来没有操作过这个区域，但我记得它是X周围的数据，所以我建议检查一下。