做过后端的人来说说重构迁移数据库难度大吗

c#也有.netframework 和 netcore
看你哪种了。

不要重构，也不要迁移，百分之百炸
建议再包一层，然后另起炉灶

我是过来人，信我

楼上+1 ，最好是另起炉灶。。。。

有句老话怎么说来着“重构一时爽，测试火葬场”哈哈哈哈
看你的项目规模和业务负责程度了。你再用 ai 也只能帮你转换 sql 语法，写写数据导入导出脚本，你要指望着 ai 帮你重构整个数据库，那基本完完～
总结：能跑就不要动

慢慢迁移吧，新老库同时运行，CDC 从老库同步过去，出问题了能立马切回去，反正要有兜底方案

难度非常大

重构的难度比新做可大多了，，绝大部分情况重构没有意义

有些重构，其实就是相当于重新做啊

难度大，做好回滚方案，除非你随时准备好跑路
一般都是先双写、然后同步旧数据、再双读验证、再把读切到新库、最后跑一段时间，没问题把双写关掉。

迁移还好，重构那是风险很高。但以你的描述，你想解决架构腐烂的问题，那还是得重构啊。这事，我建议是，你至少先运维老系统一年，再提重构的事情。你没摸清楚之前千万不要重构

不大，还好

我不太清楚你的业务场景。说说我的。
公司内部一个供应链管理系统，就是简单的库存管理+行业特性。
技术上+数据库完全重构。难不难？不难！开发 4 个多月就重构完了。
因为数据是动态的，不能有错误，否则库存对不上。
1. 花了一个周末过来进行数据迁移（花了一个星期，做数据转换脚本，周末才执行）
2. 业务部门配合并行 2 套系统，期间，所有数据录两遍（操作逻辑还不太一样）、数据报表互相验证，半年！
你就说业务部门肯不肯陪你这么玩吧。
为什么需要半年，因为数据流不一样，新系统多了很多中间生产状态，更加精细化了，而一个产品生产周期平均需要 2-3 个月。

重构 99.9999%的情况下没有意义

现在用 AI 来搞, 最明显的就是会超出上下文长度, 现在就是限额

我之前搞一个需求, 一个 json 字段,tree 结构,打平存储到三张表里面,
就这个需求,因为 token 限额跟 vibe coding 流程调优, 都搞了快 2 个星期, 同时还要不耽误其他的功能开发

吃力不讨好, 领导关注的, 跟你关注的完全不是一个点.

领导一不给经费去买 coding plan ,二要你不影响其他功能.

难度巨大无比，别干，而且必炸，有 AI 也不好使

迁移数据库是迁移数据库，重构是重构。。。。
迁移数据库大部分 ERP 系统不会特别难，数据库语法基本接近，估计 AI 也能帮忙
不理解业务，就不要去重构

c# 不挺好的吗，数据库不会是 sql server 吧，要换成啥？

没太理解为什么是先从数据库迁移开始，不应该是先开发新系统，最后迁移数据吗
如果没办法一口气开发完，就开发一部分然后把老系统的对应代码改成远程调用
迁移数据也没什么麻烦吧，原始数据保留不动，让 AI 反复写迁移脚本+人工测试不就完了

@nofishing 对，业务系统的数据库就是 sql server ,老板目标是最终想用 go 重构整个系统，现有 c#的系统太垃圾，有部分数据库是用 mysql 的，所以现在想先把业务上的 sql server 数据库迁移到 mysql, 然后再把我负责的业务用 go 重构 解耦。

@wangritian 想先把业务上的 sql server 数据库迁移到 mysql, 然后再把我负责的业务用 go 重构 解耦。

@wangritian 我他妈也不知道为什么就我负责的这块先重构，让我先搞，业务系统那么庞大呢。我日了

@qiaoqiao881100 #18 没意义啊，C# 不挺好，分模块慢慢优化呗。sql server 迁移 mysql 更没意义，除非 TB+ 数据单机放不下要换分布式数据库。我之前做过 10TB 的 sql server 迁移 OLAP 数仓，你这种 TP 的业务系统更复杂

重构这事交给 gpt-5.5 最合适。

新业务用新项目新数据库,老业务不要动,经验之谈听不听随你

风险大收益低的事情不能干

确实能动就不要搞，吃力不讨好，除非你有明确的性能优化指标，重构后可以提升 xx 倍，然后指望他升职加薪

怎么说呢，这种事有两个极端，有可能是想重用你也有可能是想干掉你

存量数据同步->增量双写->job 兜底比对/修复异常数据->开关控制读流量切到新库->开关控制停写老库->下线清理

大概就这么个流程, 我之前迁移线上 0 级系统

@chutianyao 你写的字我都认识，但是看不懂。俺之前干前端的。😭

感觉什么都没说清楚

1. 业务重构干嘛动数据库？
2. 所谓数据库迁移又是哪种迁移？
> - 更换数据库（ mysql -> pg ）？
> - 还是单纯挪个窝？

@SURA907 最终目的是替换 c#这套东西，用 go 重构，所以想先把业务上的 sql server 数据库迁移到 mysql, 然后再把我负责的业务用 go 重构 解耦。

@SURA907 现在我才发现我是不懂后端被 cto 忽悠了。cto 可能也想找个垫背的

@SURA907 确实你这几个问题真是灵魂拷问， 现在只是现有系统某些业务性能不好 ， 现有系统很多做法很龊，所以重构，但是还在跑。迁移数据库是 sql server 到 mysql

任何公司
任何项目
任何理由

重构 = 自杀

@qiaoqiao881100 这种重构巨危险，而且工期以年为单位，除非到了不彻底重构就会爆炸的程度，否则不建议碰

我之前有彻底重写过一个很边缘的小服务，没有碰数据库，即使如此也花了半年多

这个服务经过几手，被改的乱七八糟，经常搞出来脏数据，频繁去生产数据库清理脏数据不是什么好事，拖了很久拖不下去了，与其缝缝补补不如彻底重写

PS：这种细活不要太相信 AI

前端重构都容易炸飞，涉及到数据就更容易炸飞了，而且炸飞的后果更大，重构需要的不止是勇气，还要有理由，大多数重构也没法创造可观的 KPI 。

真是胆子大，不仅是数据库想迁移，代码也要一起改，我只能说牛，佩服佩服

重构过多个项目，我的经验是必炸。
你应该做好向上管理，明确告诉老板风险很大。真炸了你也打好预防针了。

> 这个 cto 每次问他问题都说让我掌控这个项目，说什么对我技术能力认可的，我 tm 才刚入职 2 月而已。

这是 PUA 话术，op 没感觉出来？

做前端的搞数据库重构，感觉有点离谱，数据库里面道道还挺多的，迁移数据不少坑要填，一旦有问题可能很难恢复

可能真就找个背锅的

绝对不要迁移，老的就不要动，直接双写到新数据库。缓慢的过渡业务。

看起来 AI 真的给了一些人盲目的自信，还能跑的东西你动它做什么，迁移个.NET 8 最多了。

@loading 我肯定感觉出来了啊，都说 2,3 遍了，就是 pua 我呗，没办法，刚入职，又不好找工作。

我自己写的，我熟悉业务的，我都不敢随便重构。虽然我有更好的设计，但是生产上依旧是缝缝补补。

看了看，还要搞什么 Go ，不要看到什么都想搞点新的技术栈进来。

@longaiwp 哈哈哈是的， 现在项目是.net5 的 abp

@yuyoung 这个老板不懂技术，估计是被这个 CTO 忽悠了可以搞重构优化性能， 又知道 go 的性能好。然后他可能有承诺了老板重构，没办法只能向下施压向上管理了

这 CTO 真会画饼

@Ayanokouji 看起来就是个火坑

token 管够，我能给你重构一个核电站出来。

重构，迁移这种活，搞好了没有增加收益，一不小心干砸了，你就得背锅。而且很容易出岔子。这就是典型的脏活累活

用 go 重构业务，不动数据库，是不是就容易了？

@minibear2021 token 确实管够，100 刀的 codex 开着，现在主要是我没啥思路， 现在主要都是参照 AI 一步一步来的。也不知道哪里会出岔子

招你来背锅，你一个新来的也不了解业务，测试要是不全面就无了

干！
事教人，一次就会

@qiaoqiao881100 我还以为是 framework 。.net 5 abp 我感觉问题不大啊，技术上没有迁移的必要啊，无论是可维护性还是性能上。 不是说 go 就一定比 c#性能好的。

没关系，有 AI ，很好搞定的

@xiaomushen 到你这里就很 easy 了？

前端仔还是没经验

你这和我发帖询问能不能去的那个工作有的一拼😅

有资深的 DBA 看着问题不大，但是复杂数据出问题难免的，运气好的话有时间慢慢修复还好，运气不好可能得连着好几个通宵。

我说的前提是对整个技术架构和业务流程完全熟悉的人都在场指挥的情况下，业务没完全搞透上来就动手基本就是个炸。

@qiaoqiao881100 100 刀刀 codex 就敢说管够了？太小看上下文爆炸后的 token 消耗了吧

1 、你都不懂后端，没深入的经验，这种重构，没个十年八年的屎山开发经验，这你敢动手？
2 、sql server 迁移 mysql 不是脑子有包吗，sql server 迁移 pg 都能说得通，迁移 mysql 不是负优化吗？
3 、c#+sql server 这个技术栈没有任何问题，抛开不好招人的问题，go+mysql 还不如前者
4 、mysql 的 sql 语句有很多方言，不是标准 sql ，迁移成本远大于重写


综上所述，必炸，就算顶着 n 次故障，弄完上线了，也没任何收益啊，系统垃圾是代码问题，不是 c#+sql server 的问题，这一套架构没有任何问题。

顺带一提，你们都用 c#+sql server 这一套了，直接打电话给微软呗，只要钱给够，微软的服务绝对包你满意，上门服务，各种性能问题给你查得明明白白，怎么迁移怎么升级，都给你安排的舒舒服服的

有过几次迁移的经验，只要给够时间，想怎么迁移都行。

不是，别的先不说
数据库能不选 mysql 就不要 mysql 啊，所有数据库里最差的就是 mysql 了，排除 access 和 sqlite……

巨坑，现在公司就在做信创的改造，oracle 迁移到国产数据库，不仅数据库迁移，整体项目都重构，准备跑路了已经，幸亏在试用期

重构最大的成本是测试验证。再烂的代码只要能在生产环境稳定跑起来那就是经过检验的合格的。业务陪你这么一通折腾有收益吗？仅仅是为了代码看起来漂亮？

你没说清楚是哪种类型的迁移啊，是从 mysql 数据库迁移到其它关系数据库吗？

从 CTO 角度来说难度可能不大，比如用绞杀者模式逐步替换 API ，结合流量镜像方案把生产流量同时导入测试环境的新老系统看数据对比来验证防止翻车等，手段很多。

如果是从培养你角度让你直接参考 https://typescript-is-like-csharp.chrlschn.dev/pages/intro-and-motivation.html 这种方便 TypeScript 熟练工快速学习 C# 的文档两天就能上手读懂项目，渐进式重构问题也不大。

但是选择的方案这么激进，对你来说难度就很大了，起码出一个风险应对方案来，除非业务规模很小，项目也不大。

同样是选择 AI 方案，还不如先让 AI 把当前系统优化好。

重构个鸡毛啊，又不是不能跑😆

刚毕业到国企的时候，一个内部商密系统重构，出了两次事故，最后分部研发领导和一半研发被干掉了

看重构可以带来什么

一般来说非常大，而且实际迁移进度可能跟规划排期有很大出入

如果是项目负责人、技术负责人牵头的，也就是有人背锅的，那就干。否则，千万别干。

sql server 的系统，迁移到 my sql ???? 一个查询估计就把系统干趴下了，my sql 复杂查询太烂太烂

我是后端佬，还算经验比较足的，你这个锅我都不敢接，这种重构就跟楼上说的一样都是以年起的，最佳的方案实际上是老的系统不管，新需求在新架构上开发，需要老系统的再迁移对应功能到新系统慢慢蚂蚁搬家。

直接重新起一个项目再做吧，如果你们没有 CI/CD 的话，必炸

@qiaoqiao881100 c#和 go 的效能是一样的

先去库里多瞅瞅吧，说不定各种惊喜

一般不是我们切图仔去送外卖，后端仔点外卖吗，怎么你们公司后端仔先倒下了

你在批评别人一坨屎的代码时，自己却想要用 AI 搞，而且要求就是跑起来就行，你是不是也太双标了?
另外，你只看到了所谓一坨屎的代码，但是你也许不知道的也许有人对开发者提出过 100 次的修改?

看了你的情况，我的建议是别重构，真的，还不如直接推倒做一个

@FreeWong 不是我评价这个项目是屎山啊，老板亲口说这个项目是屎山

1. 重构没 KPI 。 重构好了是应该的，重构导致到处炸雷就是你的问题。
2. 没有人关心哪里有坑，哪里有类。领导只希望你加班加点，把他重构的漂漂亮亮的。
3. 在没有摸清问题，没有足够排期，没有兜底方案的时候，别盲目重构。

一句话：重构好了是应该的，重构出篓子了都是你的锅。

不难，搞吧，年轻人要有闯劲，大不了跑路

非必要不迁移，sqlserver 各方面不比 mysql 差。stackoverflow 用过吧，人家就是.net + sqlserver ，性能极佳，Redis 都不缓存数据库查询的，当然了，人家是几台 1TB 内存的服务器跑数据库。

1. golang 的生态绝不会比 c#好，.net 的生态都是 m$主导，重型框架从 desktop 到跨平台到 web 到 orm 一应俱全，相比之下 golang 的官方生态除了语言本身，基本都是围绕 grpc 和云原生来的（ docker/k8s ）
2. golang 的抽象能力跟 c#比弱了两个数量级，意味着你要「重写」很可能面临 react/vue => jq+ES5 级别的特性退化，痛苦很可能不减反增
3. 「能力认可」这个话术老油条可太熟了，鸡肋的老项目我们也都是新招实习生去搞的，开发主线谁有空去开这种新坑

@nc 确实不差，但是人家也大量使用了 Redis ，参考他们的 blog
https://nickcraver.com/blog/2016/03/29/stack-overflow-the-hardware-2016-edition/
```
SQL Servers (Stack Overflow Cluster)
2 Dell R720xd Servers, each with:
Dual E5-2697v2 Processors (12 cores @2.7–3.5GHz each)
384 GB of RAM (24x 16 GB DIMMs)

Redis Servers (Cache)
2 Dell R630 Servers, each with:
Dual E5-2687W v3 Processors (10 cores @3.1–3.5GHz each)
256 GB of RAM (16x 16 GB DIMMs)


Elasticsearch Servers (Search)
3 Dell R620 Servers, each with:
Dual E5-2680 Processors (8 cores @2.7–3.5GHz each)
192 GB of RAM (12x 16 GB DIMMs)
```

@Rwing 我记错了，他们确实用 Redis 缓存数据库查询。不过数据库服务器也是很强的，2022 年的数据显示单台就有 1.5T 内存。https://archive.ph/9dEsB

@qiaoqiao881100 #18 你这样重构的目的是什么啊。。。几乎就是按实际业务全部重写一遍了。测试覆盖和生产环境的并行一致性确认，光这些的产生的成本，抵得上你重构这个系统产生的收益吗。
短视的角度去看，真有屎山系统，也是屎上雕花的效果可能会更好一点。

前端仔+刚入职两月+重构 C#后端，不敢想。这 CTO 是有多业余啊，感做这样的决策。要么是项目不重要，要么是人不重要。

别重构了，包一层然后慢慢迁移。
今天挪一点明天挪一点，几次迭代可能就挪干净了。

有一个外国搞电商的方法是，每个用户都维护最初使用的版本，用户不选不升级。
做 v2 v3 v4 v5 ，你的目的就是做个 v2 ，然后新用户接进来老用户别去管。
用户要迁移新版本，你再去把数据做个管道转移了。

有 Leader 掌控兜底，问题不大。先花点时间把测试覆盖率涂满，然后一块一块重构。
你要问难度大不大，那肯定大的，但是这个难度大不是说做起来累，而是说你得有能力才能做。这事情你让一个有丰富 AI 和重构经验的人来做，不难。你让一个刚起步的人去做，那就很难了。
假如你说的背景基本属实，没有妄自菲薄，那你们 CTO 就是坑子，开工前说相信你，开工后炸了你全责。

人觉得不是不可以，先把业务摸清楚在重构

@anivie 哈哈哈

不是，哥们首先想的居然不是跑路？

@KuangCD 已经在想跑路的事情了

数据库迁移最麻烦的是 sql 的不兼容。你得写测试，让 ai 把旧版的查询全部 sql 调用的地方，都需要分离出来，如果有比较抽象的 DAO 层，可以针对全部数据的访问写测试代码，然后两个库的结果分别比对 CDUR 的结果。能跑通全部测试再迁移。

哥们你是不是资历最浅的。是的话，估计拿你当小白鼠了。你迁移结束，其他人迁移有疑问也会找到你

@shaozelin030405 你还真说对了。俺基本后端资历最少把