网站维护 英语大连投诉网站

网站维护 英语,大连投诉网站,云做网站,大兴网站开发公司从Oracle迁移到MySQL#xff0c;我踩过的10个大坑#xff08;附解决方案#xff09;坑1#xff1a;自增主键居然不连续#xff1f;坑2#xff1a;分页查询性能暴跌坑3#xff1a;大小写敏感搞崩了SQL坑4#xff1a;空字符串 vs NULL 的语义差异坑5#xff1a;日期时间…从Oracle迁移到MySQL我踩过的10个大坑附解决方案坑1自增主键居然不连续坑2分页查询性能暴跌坑3大小写敏感搞崩了SQL坑4空字符串 vs NULL 的语义差异坑5日期时间精度丢失坑6没有真正的物化视图坑7PL/SQL 存储过程无法直接迁移坑8字符集和排序规则Collation踩雷坑9事务隔离级别行为不同坑10没有DBLink跨库查询怎么搞最后一点真心话差不多快10年前当时也刚学MySQL我们团队接到一个“光荣而艰巨”的任务把公司用了十几年的Oracle核心系统整体迁移到MySQL上。老板说“开源、省钱、轻量还能拥抱云原生。”听起来很美好但真正动手之后才发现——迁移不是换数据库是给系统做一场高风险手术。今天就来和大家聊聊我在迁移过程中踩过的10个大坑每一个都是血泪教训也都有对应的“止血”方案。希望你少走弯路少熬几个通宵。坑1自增主键居然不连续- 场景还原在Oracle里我们用的是序列Sequence触发器生成主键。迁到MySQL后改用 AUTO_INCREMENT。上线第一天测试发现订单ID跳号了比如刚插入1001下一条变成1005。原因分析MySQL的 AUTO_INCREMENT 在事务回滚、批量插入失败或服务器重启后不会回退已分配的值。这是设计使然不是bug。- 解决方案如果业务强依赖连续ID比如财务系统建议继续用外部ID生成器如Snowflake、Leaf。如果只是担心“看起来不连续”那就接受现实——ID只要唯一就行别执着于连续。坑2分页查询性能暴跌场景还原Oracle里 ROWNUM 100 分页飞快。MySQL用 LIMIT 100000, 20 查第5000页时直接卡死。原因分析MySQL的 LIMIT offset, size 会先扫描前 offset 行再返回结果offset 越大越慢。而Oracle的 ROWNUM 是在执行计划早期就过滤的。解决方案改用 基于游标的分页Cursor-based PaginationSELECT*FROMordersWHEREid100000ORDERBYidLIMIT20;或者加缓存层把高频分页结果预加载。坑3大小写敏感搞崩了SQL场景还原开发在Oracle写的是 SELECT UserName FROM users一切正常。迁到MySQL后报错“Unknown column ‘UserName’”。原因分析Oracle默认不区分列名大小写而MySQL在Linux下表名和列名默认区分大小写取决于 lower_case_table_names 参数。解决方案迁移前统一规范所有SQL字段用小写。设置MySQL参数 lower_case_table_names1仅限新实例已有数据慎用。用工具如SQL审核平台扫描历史SQL自动修正大小写。坑4空字符串 vs NULL 的语义差异场景还原用户手机号字段在Oracle里存的是空字符串 ‘’迁到MySQL后变成 NULL导致前端判断逻辑全乱。原因分析Oracle中 ‘’ 和 NULL 是等价的这是Oracle的“特色”。但MySQL严格区分‘’ 是空字符串NULL 是“无值”。解决方案数据迁移脚本中显式处理INSERTINTOmysql_table(phone)SELECTCASEWHENphoneTHENNULLELSEphoneENDFROMoracle_table;应用层统一约定要么全用 NULL要么全用空字符串别混用。坑5日期时间精度丢失场景还原Oracle的 TIMESTAMP(6) 能存微秒当时使用的版本低MySQL 5.6 的 DATETIME 只支持到秒。迁移后日志时间戳全变成整秒排查问题时根本对不上。解决方案升级到 MySQL 5.6.4使用 DATETIME(6) 或 TIMESTAMP(6)。确保应用连接串加上 serverTimezoneAsia/Shanghai避免时区混乱。坑6没有真正的物化视图场景还原Oracle里有个复杂的物化视图每天凌晨自动刷新汇总销售数据。MySQL没有原生物化视图怎么办解决方案用 普通表 定时任务 模拟CREATETABLEsales_summaryASSELECTshop_id,SUM(amount)FROMordersGROUPBYshop_id;再用 crontab 或调度系统每天凌晨重建。或者用 ClickHouse / Doris 做实时OLAPMySQL只存明细。坑7PL/SQL 存储过程无法直接迁移场景还原核心计费逻辑全写在Oracle存储过程里上千行PL/SQL。MySQL的存储过程语法差异大重写成本高。真实做法果断放弃存储过程把逻辑上提到应用层Java/Python。好处可测、可监控、可版本控制。坏处初期工作量大。我们花了两周重构但后续迭代效率提升3倍。坑8字符集和排序规则Collation踩雷场景还原用户昵称“Àlex”在Oracle按字母排第一在MySQL却排最后。搜索“alex”也搜不到“Àlex”。原因分析Oracle默认用二进制或语言无关排序MySQL默认 utf8mb4_general_ci 不支持重音符号折叠。解决方案使用 utf8mb4_unicode_ci 或更现代的 utf8mb4_0900_ai_ciMySQL 8.0。对搜索场景考虑引入 Elasticsearch 做全文检索别依赖数据库LIKE。坑9事务隔离级别行为不同场景还原Oracle默认是 READ COMMITTED且不会出现幻读。MySQL InnoDB虽然也是RC但在某些场景下仍可能看到“幻行”。关键差异Oracle通过多版本回滚段实现一致性读MySQL InnoDB在RC级别下每次SELECT都创建新快照可能导致同一事务内两次查询结果不一致。解决方案明确业务是否需要可重复读RR。如果需要显式设置SETSESSIONTRANSACTIONISOLATIONLEVELREPEATABLEREAD;对账类、金融类操作强制用RR并配合 SELECT … FOR UPDATE。坑10没有DBLink跨库查询怎么搞场景还原Oracle用 DBLink 轻松查另一个库的数据。MySQL没有等效功能报表系统炸了。解决方案不要跨库查提前把数据同步到同一实例用ETL工具如DataX、Canal。或者用 Federated 引擎不推荐性能差。更好的方式数据仓库化用Doris/StarRocks统一查询。最后一点真心话迁移不是技术炫技而是业务连续性的保卫战。我们花了几个月做准备全量SQL审计自动化回滚预案影子流量对比验证最终零故障切换。如果你也在做迁移记住慢就是快稳才能赢。