問題が発生します
ライン上のスコアシートを適用する前に、我々はサービスが影響を受けないことを確認するために、新しいテーブルにレガシー・データ・テーブルを移行する必要があります。
その夜、再び移行するために、少数派である過去の最後の行をだから我々は64ポイントテーブルに大きなデータテーブルの移行のための責任がある別のアプリケーションの移行を、書いて、その後のプロセスで生成されたデータを移行します。
すべては、ライン上のアプリケーションが、そう単純ではない見つけたときに、非常に良いと思います。
第二に、データベースの負荷が増加
まず、データベース自体にあるが、データベース自体に、この移行プロセス圧力に私たちの前に立つことができない最初の質問は、比較的大型であり、それは、このアプリケーションは、最後の藁だったのです。
最終結果は：プログラムのデータベースに接続されているすべての動作のほとんどはアウト、異常なデータベース接続未満の範囲へのアクセスが発生しています。
最後に、方法は、私たちは早朝の実行には、このアプリを入れていないが、実際には、後にまだできません見つけるに観察することができます。
午前中の取引量の減少が、それでも要求の小さな部分があるが来てますが、データベース例外の様々ながあるでしょう。
別のは、それは三の大テーブル（3,4百万データ）に約10日かかる点テーブルに移行、移行プロセスの効率は、この速度に応じて、我々はビット移動時間を推定する、また、非常に低いです。
だから我々は、図書館での移行プログラムから実行するプログラムを変更した後、最終的には運用・保守の方法は、メインのライブラリに直接テーブルに分割されます。
圧力からのライブラリーよりもメインライブラリがたくさん小さいため、中小企業への影響、移行の効率ははるかに高速である必要がありながら。
たとえそうであってもまた夜を過ごした+一日の時間は、それが億個のデータ移行が完了するだろうが、ビジネス上の圧力は、データの量を成長させ、その後、追加していく、この効率はまだ十分ではありません。
第三に、プログラムは互換性があり
最終的には方法が唯一のプログラムは、データを移行しないたくないために、しかし、新たに生成されたデータポイントテーブルには書くことか、少なくとも大きなテーブルにはデータがもはや新しいものでないことを確実にするために。
しかし、私たちのために、この前のデータが行うことになって？それを読んで聞かせすることはできません。
実際には、へのデータの操作のためのより多くの何も增删改查それがどのようにこれらの4つの操作が互換性を参照しないように。
1、新しいです
新しい最も簡単なのは、あなたがデータのいとこを確保することができるように、サブテーブルルールから直接、新しいテーブルに書き込まれたすべてのデータは、もはや新しいものではありません。
2、削除
例えば、ユーザーが生成した個人情報を削除したい、より少し複雑追加されます削除し、新しいテーブル内のデータも可能いとこであることも可能である（例えば注文データです）。
所以删除时优先删除新表（毕竟新产生的数据访问的频次越高），如果删除失败再从老表删除一次。
3、修改
而修改同理，同样的会不确定数据存在于哪里，所以先要修改新表，失败后再次修改老表。
4、查询
查询相对就要复杂一些了，因为这些大表的数据大部分都是存放一个用户产生的多条记录（比如一个用户的订单信息）。
这时在页面上通常都会有分页，并且按照时间进行排序。
麻烦的地方就出在这里：既然是要分页那就有可能出现要查询一部分分表数据和原来的大表数据做组合。
所以这里的查询其实分为三种情况。
- 首先查询的时候要计算这个用户所在分表中的数据可以分为几页。
- 第一步首先判断当前页是否可以在分表中全部获取，如果可以则直接从分表中取出数据返回（假设分页中总共可以查询 2 页数据，当前为第 1 页，那就全部取分表数据）。
- 如果不可以就要判断当前页数在分表中是否取不到任何一条数据，如果是则直接取老表数据（比如现在要取第 5 页的数据，分表中一共才只有 2 页数据，所以第 5 页数据只能全部从老表中获取）。
- 但如果分表和老表都存在一部分数据时，则需要同时取两张表然后做一个汇总再返回。
这种逻辑只适用于根据分表字段进行查询分页的前提下
我想肯定会有朋友提出这样是否会有性能问题？
同时如果在计算分表分页数量时出现并发写入的情况，导致分页数量不准从而对后续的查询出现影响该怎么处理？
首先第一个性能问题：
其实这个要看怎么取舍，为了这样的兼容目的其实会比常规查询多出几个步骤：
- 判断当前页是否可以在分表中查询。
- 当新老表中都有数据时候需要额外多查询一张大表。
第一个判断逻辑其实是在内存中计算，这个损耗我觉得完全可以忽略不计。
至于第二步确实会有损耗，毕竟多查了一张表。
但在分表之前所有的数据都是从老表中获取的，当时的业务也没有出现问题；现在多的只是查询分表而已，但分表的数据量肯定要比大表小的多，而且有索引，所以这个效率也不会慢多少。
而且根据局部性原理及用户的使用习惯来看，老表中的数据很少会去查询，随着时间的推移所有的数据肯定都会从分表中获取，逐渐老表就会成为历史表。
而第二个并发带来的问题我觉得影响也不大，一定要这个分页准的前提肯定得是加锁了，但为了这样一个不痒的小问题却带来性能的下降，我觉得是不划算的。
而且后续我们也可以慢慢的将老表的数据迁移到新表，这样就可以完全去掉这个兼容逻辑了，所有的数据都从分表中获取。
四、总结
还是之前那句话，这里的各种操作、方法不适合所有人，毕竟脱离场景都是耍牛氓。
比如分表搞的早，业务上允许一定的时间将数据迁移到分表那就不会有这次的兼容处理。
甚至一开始业务规划合理、团队架构师看的长远，一来就将关键数据分表存储那根本就不会有数据迁移这个流程（大厂有经验的团队可能，小公司小作坊都得靠自己摸索）。
这段期间也被数据库折腾惨了，数据库是最后一根稻草果然也不是瞎说的。