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

[qiaoqiao881100]

业务耦合性高，基本就是一坨屎，而且还是国内不入流的技术栈 c#, 现在要想重构，先从数据库迁移开始，之前没干过迁移这种事情， 这事情难度大吗，现在基本就让 AI 搞，也不知道最终会不会搞好。
人和库有一个能跑就行

另外说明一下背景：
本人之前干前端的，简历上也基本都是写前端项目，只有一个简单的的后端项目，
对 mysql 也基本停留在简单的 curd 上面，
这个 cto 每次问他问题都说让我掌控这个项目，说什么对我技术能力认可的，我 tm 才刚入职 2 月而已。

另外说一句，目前我只负责一块业务的解耦吧算是，20 个表，然后表里面有一些服务需要拆分的，通过 api 调用方式来交互，但是我心里也没底。虽然用 AI 已经迁移了表，但是各种服务要拆分出来，主要是心里没底

[IMengXin]

同 C# ，同迁移数据库，最早是 SQLServer 迁移到 MySQL,屎山代码里全是拼接的 SQL 语句或者调用的存储过程，改成用 SqlSugar,基本完成，然后！老板不知道哪看来的人大金仓 SQLServer 版 +　国企要求信创，再次迁移到人大金仓 SQLServer 版 ，这才是痛苦的一匹

[JamesMackerel]

除了设计复杂业务的高并发分布式场景的系统之外，最难的不就是重构和迁移了吗。

sql server + c-sharp 有啥不好的，是突然业务量要扩大几十倍吗，如果是那样的话重构还算合理，但是如果是有那么大的扩展，为什么资金投不到人力上来，就得你一个人干？

[mooyo]

不大，但是比较繁琐。看你们要在线迁还是可以停机迁了。

之前在线迁过几张亿级的表 没啥问题。

[Felldeadbird]

巨大。就算 ORM 加持，有一些特殊 SQL 你不知道有什么坑在里面。一不小心就炸了。

[tangmanger]

本人之前干前端的，简历上也基本都是写前端项目，只有一个简单的的后端项目，
对 mysql 也基本停留在简单的 curd 上面，
建议别动如果 c#的完全用的 EFCore 迁移还行 单基于你后端经验一般情况下 别动框架 别动数据

[zgsi]

重构不如重做

最麻烦的是数据库

[heftyMan]

生产谁爱迁移谁迁。测试想咋迁就咋迁

[chandleryou]

真 vibe 出来后，能用没问题皆大欢喜，一旦问题一段时间解决不掉 -> 大概率背锅 -> cto 以此为理由扩充后端团队

[chtcrack]

怎么感觉这个 cto 是想找你背锅的啊?

[SchwarzeR]

先把业务吃透了、把单元测试都补齐了再说
给个半瓶子水的后端纯做数据库迁移都能把主键索引迁没的，高风险还费力不讨好

[zh3256]

不用原地迁移，新建服务重写 API ，写完一个迁一个。各个地方多打点日志，没事观察一下，老项目其实很多功能是没用到的，没有日志就干掉。
数据库没到瓶颈没必要迁，强迫症作祟。

[dog82]

要看系统复杂度，如果写了函数或过程，比较麻烦。

[zjcolvin]

cto 不像正儿八经的人类，你也不要正儿八经的弄，评论区已经有很多人说这个事情有多难了，但是我觉得你拿来练手混项目经验没问题，只要不用担责和赔款就放心弄；但如果不是这样只推荐跑路

[zjcolvin]

哦对了，ai 润色过的：
不要把 CTO 当成一个成熟、规范的管理者来看待。这个项目本身难度和风险可能都不低，评论区也已经有人分析过了。如果只是把它当成练手、积累项目经验的机会，而且出了问题不用你承担责任或赔偿，那可以大胆尝试；但如果需要你背锅、承担风险，那更建议尽早离开。

[hjw45611]

AI ？你信 AI ？？
老板让我们重构一个项目，说用 AI 一个月搞定，结果本来后端一个人，用 AI 弄了两周天天加班实在时间不够，后来加了两个人，AI 用了快一千刀，还超期完成

[Xwang]

数据迁移和程序重构分开做，不要一起做

[horacegao]

ai 迁数据库肯定出问题，老司机才能搞定的事情

[ElmerZhang]

看你什么数据规模，数据越少风险越小。
曾经重构过公司核心数据库，峰值 qps 上万，所有表加起来百亿数据量，折腾了两三个月才重构完。

[ningxing]

让 AI 参考你现在代码，重新设计一套，别改以前代码，不然肯定会炸，特别是自己不懂的话。让 AI 重新写也别指望一次性全部搞定，长时间或者一次性 AI 写出来的也是一坨屎，只有慢慢一个一个单功能完成人工校验没问题再继续下一个。

[whisper1225]

@wangritian 大部分都是从 DB 迁移开始，CDC 同步，然后读灰度，然后写灰度，最终完全迁移

[tt67wq]

换 DB 自古以来就是难题，要是业务不接受停机的话更难

[whisper1225]

@chutianyao 存量数据同步之后是不是要有个新存储读灰度

[whisper1225]

@qiaoqiao881100 其实搞搞挺好的，拿公司的资源练自己的手。当然如果啥资源都不给你，那就尬了

[qiaoqiao881100]

看评论学到不少知识

[Torpedo]

@liuzhedash #2 虽然没搞过，但是见过很多次。都是双写，完善之后逐步切流

[qiaoqiao881100]

@whisper1225 说的对， 拿来练手涨经验，干不干的成都有收货应该是

[wengjin456123]

ai 搞 数据库容易炸，不炸的前提是你特别懂

[esee]

重构是工作最多最繁琐，也是最没有收益的事情，我自己写的项目我自己去重构都很痛苦，能推就推了吧

[JiafuYuan]

@qiaoqiao881100 #43 大厂出来的就喜欢搞这一套,技术能力没有,吹牛甩锅能力第一名,疯狂贬低老系统,给老板画饼,骗老板几个月跑路

[brazz]

做过重构，建议分批重构，也要了解清楚 源数据库和新类型数据库的差异。按照业务批次分批迁移重构掉，不建议一步到位，也得配合代码同时进行，有很多业务是 历史毒瘤，可能不是因为你重构引起的也会归到你这边来，总之，任重道远

[liuzhedash]

说双写的稳定以后切流的，这种只适用于重构期间不会做任何修改的系统，但是这样的系统本身也没有被重构的价值。

[JiafuYuan]

@JamesMackerel 肯定是领导给老板许了承诺,想证明自己,但自己没那个能力

[liqiuqiu]

入职 2 个月你就敢背这么大口锅，况且你还是前端，胆子挺大啊

[qiaoqiao881100]

@liqiuqiu 不是我背锅，是现在他就给我派这个活，产品那压了半年的需求都还没做呢，没办法咯

[z1154505909]

难度巨大无比，我以前维护一个 c#的站点，加功能都是用 python 拦截请求来实现，简直 mmp

[ZENGQH]

@play78 #12 hhh 我司一周时间 一套业务系统 c#转 java 微服务，用 ai

[wtml]

你们老板心真大，这么重大的重构不找个专业的直接让前端全权负责

[daqingzi]

同种数据库迁移都需要经过各种测试，包炸的，有 ai 也包炸

[zhangli2946]

0. 沟通重构要求 -> 确认重构原则\确认重构目标
1. 建立重构计划,明确里程碑目标 -> 向上管理用
2. 建立请求网关 -> 请求流量复制和响应内容比较\未来流量控制
3. 梳理现存业务 -> 沟通并识别原系统中的技术债务\明确现存数据模型\匹配迁移重构的附加要求

[NeoWalnut]

重构火葬场

[aidchow]

宁愿写胶水层，也不要迁移数据库，就没遇到过不炸的

[malusama]

迁移后他妈以前的数据 bug 或者各种问题都是你的锅， 过去的问题也不会承认的

[chneqi]

我赞同能跑不要动，改就是坑。但是，有人愿意付费给时间给你机会那 ai 练手这可是大好事啊，怎么会想着跑路

[qingyingwan]

我预测你半年到一年就会跑路，好好珍惜这段时间掌握他们的系统架构，做的事情哪些能写到简历上去。

[SenseHu]

后端多少人啊, 听起来像要搞微服务? 那我只能说祝你们好运, 我们被坑惨了, 现在单体一把梭问题少多了

[seenthewind]

迁移重构数据库比重新做难 10 倍不止，如果还要叠加新的业务功能，那么基本上等同于在找死。

为什么我这么清楚。。。因为我干过。。。反正所有数据，包括库从一个库拆 7 个库，实时和历史全部分层解耦合。

具体量化一下难到什么程度，这么说吧，当时我带 5 、6 个人干这个事情，干到最后人全跑了，只有我留下来，后面重新汇报，重新安排工作，再一次划分负责和范围，第二次搞的时候基本上把数据重构+解耦+新业务设计所有工作拆分到大概 100 人的团队中。

最终当然是顺利搞完了，要说收获嘛，有了点经验而已，后续的工作或者发展中，并不会有多少人记得当时发生了多大的事情，当时遇到了多大的困难。

[zzzzCore]

做过从 sql server 迁移到 mongodb ，当然，项目规模并不大，3 个人做了一个多月。
具体做起来，就是从功能出发一个功能一个模块一点点做。

说清楚风险，管理好预期，有人支持就大胆搞就是了。

[happywind]

哈哈，明显 CTO 让你做他不敢做的事，应该跟老板畅想未来了不少加 AI 好办事

方案成功了：你的功劳变他的（这是我提的方案）

方案失败了：你是“罪人”

跟我们公司这个没啥两样，老板也不懂技术，
让你去冒风险做新功能，他自己做复制 ，粘贴工作。。。

[cenbiq]

你这个跟什么语言什么数据库都没关系，数据库可能还是反向升级，.net 跟 go 性能是一档的，除非你是 node/python 可能还能说一下语言平台性能问题，我猜你们项目性能差主要是数据库设计瞎搞了。一句话别搞什么重构了，想办法优化一下查询，哪怕问下 AI 看看结论也行啊

[qiaoqiao881100]

@cenbiq 这个我说了不算啊，重构是领导要求，

[livin2]

重构的前提是，有着极其完善的测试 case ，能改一步 test 一步，不然你这不叫重构，就是重写

[javalaw2010]

线上业务敢重构的，都是有种的。给你点赞。

[qiaoqiao881100]

@javalaw2010 看来这个公司估计实在是找不到 CTO 招来这么一个坑货过来了

[deepshe]

数据库 sqlserver->mysql 不是反向升级嘛

[aw2350]

.net 十个项目九个是 shi ，因为这个群体开发人员较少，高质量的代码以及方案示例较少，开发人员接触到的层次也较低，所以写的都很 shi

[burymme11]

@qiaoqiao881100 看你描述，第一步处理数据库迁移，线上数据从 sql server 切到到 mysql ，第二步做代码重构，是串行还是并行？如果是串行的，还能试着搞搞，并行的话。。。。。。。
如果是串行，20 张表还行，重新包一层，新老双写，切流，数据对比，这套 AI 应该能搞定。

[shiloh595]

重构不如重做，OP 赶紧溜溜球吧

[wikisu]

让你掌控就行，我对 ai 也是这么说的（ doge

[fujizx]

经历过重构，也经历过 sql server 迁移到 mysql 。
信心满满重构之后，项目很容易变成新的屎山，唯一开心的是搅自己的没有搅别人的那么臭。
sql server 迁 mysql 小坑蛮多的。。。不过是痛苦一次的事情。

[zsmile]

都有 AI 了，让 AI 自己跑吧，包出事的。人和代码一个能跑就行了

[zsmile]

C#很多都爱 SQLSERVER ，而且 SQL SERVER 都喜欢用存储过程什么的，总得来说都是费时费事的

[abc0123xyz]

如果能保证出问题后不杀了我的话，那迁移相当简单，轻轻松松.

[xingzhi95]

其实根本不是数据库的问题，是遗留代码的复杂度和可读性的崩溃

[slation]

重构数据库，这可是一般人干不了的事情，万一有点错误

[gejigeji]

数据规模有多大？

[hoopz]

换国产数据库？ 我们搞过，先拿 AI 补测试，再改代码。虽然心惊胆战，但最后评估整体风险可控。