记录了一次迁移过程中遇到的挑战和问题，供大家参考避坑！
在进行库迁移之前，我们首先将所有直接连接要迁移的库表服务通过一个统一的服务来实现，其他的服务则通过API的方式进行归一处理。
其次，我们需要处理SQL Server中的存储过程。由于TiDB不支持存储过程，所以在迁移之前，我们需要用程序代码实现SQL Server存储过程的功能，以便进入数据迁移阶段。
接着，我们对两个库的表进行双写（也可以预先设置开关，先进行双写，然后在观察期内检查是否有异常情况，最后再全部切换至新库中）。然后，我们迁移历史数据，迁移完成后，数据校验通过后，并逐步切换读数据。在切换读数据时，我们可以使用灰度开关，在上线后通过修改配置来设置灰度的比率。
在迁移数据和进行双写时，我们主要遇到了以下几个问题：
主要问题1：字符集不一致
SQL Server和TiDB可能使用不同的字符集和编码方式，这可能导致在迁移过程中出现字符集不一致的问题，特别是对于包含特殊字符的数据。SQL Server使用GBK编码，对一些生僻字和表情符的支持不太好，而TiDB使用utf-8编码。在迁移数据后的测试验证中需要注意这一点。
主要问题2：主键生成方式不一致
SQL Server和TiDB在生成主键值方面可能采用不同的策略，这可能导致主键值不一致的问题。为了解决这个问题，我们增加了一个分布式Id生成器。
主要问题3：查询默认排序问题
SQL Server和TiDB在处理查询结果的默认排序方式上可能存在差异，这可能导致相同查询在两个库中返回的结果集顺序不一致。SQL Server默认按主键排序，但在TiDB中主键是乱序的。为了解决这个问题，我们在一些默认排序的SQL语句中增加了排序字段，以确保在两个库中查询的数据一致。
主要问题4：浮点数位数不一致
SQL Server和TiDB在浮点数精度和位数上可能有不同的默认设置，这可能导致迁移后浮点数值的精度问题。同时，时间的精度也可能存在差异。为了解决这个问题，在迁移前和双写时，我们使用程序指定精度来处理。
主要问题5：外键依赖
SQL Server 有些表与表之间有外键 如果表迁走后，其他的表对这张表有依赖性需要先迁其他的表或去除外键
将表从 SQL Server 迁移到 TiDB 的过程中，需要仔细规划和处理数据。在进行迁移前，务必了解两个数据库系统的差异，并采取适当的措施来确保数据的一致性。无论遇到什么问题，都可以通过适当的工具和技术来解决，并确保迁移过程顺利进行，以满足业务需求并保持数据的完整性。虽然迁移是一项复杂的任务，但经过良好的规划和准备，我们可以成功实现迁移。