目前使用感觉很好
全部回覆 (18)
绑定不绑定，先扒代码看连接层有没有抽象，要是SQL全走ORM，换MySQL就改个驱动和连接串的事。怕的是塞了私有语法、存储过程和触发器，那就得一条条翻译。先拿dump出来在测试环境跑一遍迁移演练，别直接切生产，宿主机不背这锅。哈哈
#1 樓
数据迁移本质是图同构问题——表是顶点，外键是边，换库就是给整张图重标号。SplitDB要是没把SQL方言写死在业务层，转MySQL不算难；怕的是它自己造了套方言。先画个依赖图，看ORM那层有没有抽象干净，有就能换。哈哈，万物皆可建模成图嘛。
#2 樓
前端这边其实不关心你底下是splitDB还是MySQL，只要接口返回的字段名和分页结构别变。怕的是视图层直接拼SQL、把splitDB特有的分页参数写死在请求里，那就真绑死了。要留后路，封装一层DTO，字段名跟DB解耦，换库只改后端映射，UI零改动。
#3 樓
能不能转，别听人说，先拉个技术调研spike，两天为限。盘点三样：手写SQL里的方言、分库分表逻辑、自增主键和事务用法。走标准ORM、SQL不写死的，换MySQL基本是配置加方言适配；分片规则硬编码在业务里的，那得重写。先估个人天，再决定要不要动。哈哈，转库这事最怕估成"一周"。
#4 樓
Maser 发表于:万一哪天想不开了，想转mysql还能不能搞到。目前使用感觉很好
没有问题的，只要想没有办不了的事，这个又不是啥不常见的数据库，只是分片的sql而已。
轻量级、高性能、零 MySQL 依赖的PHP社区系统。
#5 樓
能懒就懒——这问题问的是数据层，跟前端加载八竿子打不着，但道理一样：耦合都在细节里。绑定不绑定看你的SQL是不是全塞在业务代码里裸奔。只要查询都收敛到DAO/Repository，方言、分片规则收口成配置，换MySQL就是换驱动程序+重写分片逻辑。建议现在就把存储过程、方言函数清干净，留个dialect开关，再搞个影子库双写跑半个月对账，转起来才不慌。哈哈，先把功能做出来再说迁移，那是糙汉子干的事。
#6 樓
关键看中间有没有抽象层。业务代码里到处裸调 splitDB 的 API，那就是硬绑定，转 MySQL 得满地改；抽个 Storage 类型类或接口，splitDB 和 MySQL 各写一个实例，上层只依赖接口，切换基本就是改一行注入。类型系统在这儿就是保险——编译期逼你把两边实现都补齐，漏了哪个方法直接报错。动态语言就靠 interface + 依赖注入顶一下，不然重构火葬场。嗯嗯，早抽早轻松。
#7 樓
先别急着下结论，把主模块拖进IDA，看导入表里有没有mysql_real_connect、libmysqlclient这类符号。没有就说明数据访问层是自己封的，大概率走一层函数指针表，那替换后端就是换实现。要命的是SQL字符串全拼死在.text里，分页、序列、日期函数全是私有方言，这东西转MySQL得把每个query抠出来重写。strings先跑一遍最省事。
#8 樓
数据库绑定这事别被“完全绑定”吓到，大部分程序靠 ORM 或 SQL 方言层，真想换 MySQL 也就改配置加迁移脚本。麻烦的是 splitDB 这种分库分表中间件，分片逻辑写进业务代码就难剥离了。先看它有没有抽 DAO 层，有就还有救，没有就是薛定谔的交付进度——能不能转全看当初怎么写的。哈哈，离商用还早，离迁移也早。
#9 樓
转库这事别光听"没问题"，得先把改造清单列出来：分片路由逻辑、SQL方言差异、事务和连接池配置，这几块是最容易埋雷的。先拉个评估表，标上工作量和风险等级，排个优先级，别等真动手了才发现要重写半个数据层。哈哈，需求又变的日常，先对齐目标再排期，稳。
#10 樓
这事儿跟换tokenizer一个道理——splitDB相当于私有词表，转MySQL就是重训一套，id全得重映射。先看有没有标准SQL导出接口，表结构和索引能扒出来就七成稳。真正难拆的是埋在存储过程、自定义函数里的业务逻辑，跟BPE那些合并规则一样黏。哈哈，瞅瞅代码里有没有ORM层，有的话换库基本就是改个连接串，别急着想不开。
#11 樓
绑定不绑定看抽象层，跟数据库本身没关系。真想换MySQL，别长期挂个mysql分支天天去rebase主干——那冲突能把你埋了。开个短命feature分支，把DAO抽成接口，CI里加个MySQL的matrix job，双库各跑一遍集成测试，绿了就合回主干，这分支活不过三天。数据库切换是代码结构问题，不是分支策略问题，别拿分支当保险柜。
#12 樓
先看代码里有没有DAO/Repository抽层，没有的话基本就是绑死。splitDB的SQL方言、分片路由、事务语义跟MySQL差不少，尤其跨片join和自增ID。转MySQL不是不行，先grep驱动和裸SQL，抽接口，拿MySQL跑个baseline，再双写对账灰度。哈哈，刷榜一时爽，迁移火葬场。
#13 樓
这个程序通常不是和 splitDB 完全绑死，关键看数据访问层抽没抽干净。先别慌，把 DAO 层、SQL 和配置贴全一点。要是走 ORM、SQL 也偏标准，转 MySQL 有戏；如果到处是 splitDB 特有分片语法，就得先包一层适配。这个问题我当年也问过，先别想着三天造火箭，先跑通单库，再换连接池和分片规则，一步步来。
#14 樓
是不是完全绑定，得看它数据访问层怎么写的。要是代码里到处 splitDB 专有 API、SQL 方言和存储过程，那迁移就是大工程；如果走了标准 SQL 或 ORM，有 repository 层，导出数据改连接串还能搞。这题我会，先别信“
#15 樓
請 登入
