接手一个中等规模的后台系统时摆在桌上的第一个技术决策往往不是微服务怎么拆、缓存用哪家而是数据库这台“地基”踩在哪里。我碰到过不止一次这样的场面会议室里两拨人各说各话一拨人坚持开源栈的 MySQL理由是不花钱、生态烂大街、招人容易另一拨人死守 SQL Server理由是存储过程写得爽、报表工具配套齐、运维界面点几下就能把活干完。吵到最后往往不是靠技术定胜负而是谁嗓门大或者谁资历老。MySQL 与 SQL Server 的对比几乎每个做后端的人都绕不开一次但网上的答案大多停留在“开源 vs 商业”“免费 vs 收费”这种表层。真到落地那天让你熬夜的绝不是许可证价格而是某条 UPDATE 语句在两边表现不一样、某个分页语法迁移过去直接报错、某张表锁的粒度完全失控。这篇会把我在多个项目里踩过的差异点摊开讲从授权账本、SQL 方言、并发模型、高可用、调优路径五个维度掰扯清楚适合正在做技术选型的架构师也适合只是想知道“换库到底会疼在哪”的开发同学。1. 那次差点吵翻的选型会暴露出什么问题1.1 两派人的理由其实都不完整坚持 MySQL 的那一拨核心论点浓缩起来就三句话不要钱、社区资料多、DBA 好招。这三句听着都对但每一句都有个隐藏前提。不要钱指的是社区版企业版该花的钱一分不少而且更要命的是 GPL 协议对分发场景的约束——如果你的产品是以镜像或私有化部署方式交付给客户的法务那边通常会要求你重新审视一下协议义务。社区资料多也是相对的中文博客里大把内容是抄来抄去的真正讲到间隙锁在什么条件下会拖垮一批插入的未必有几篇。坚持 SQL Server 的那一拨理由则是开发体验好、周边组件齐、Windows 环境无缝。这话同样成立但代价被轻描淡写了按核心计费的授权模型在云主机上跑个十几核的实例年费不是小数目而且这套生态的重心始终在 Windows 那一侧如果团队的技术栈已经倒向容器化部署很多便利会打折扣。我后来把这场争论归结为一句话大家在用各自项目的成功经验论证一个通用结论。这本身就是错位。1.2 我判断这件事的三个坐标轴踩过几次坑之后我形成了比较固定的判断框架只在三个轴上称重其余都是噪音。第一是规模与增长曲线。单表数据量是千万级还是十亿级决定了你对分区、分片、中间件的依赖程度而这两个引擎在这条路上的成熟度并不对称。第二是团队的既有资产。存量代码是不是用了大量存储过程和 T-SQL 特有语法、报表体系和 ETL 是不是绑在某个生态里这些沉没成本往往比授权费更贵。第三是运维人力的形状。有人愿意写脚本、看监控、调参数MySQL 会变得非常可控如果运维只有半个人、希望图形化点两下就能备份和排查那商业产品的完整度是实打实的优势。这三个轴交叉起来答案基本就浮出来了。下面几章我会把每个轴上的具体细节展开因为选型判断最怕的就是“大概知道”真出事时那点模糊会要命。2. 授权与总拥有成本五年账本怎么算才不失真2.1 两种计费模型的实际差异SQL Server 的授权模型有两套Server CAL 和按核心授权。前者适合用户数明确的内部系统比如一个只有几十个员工用的 ERP后者适合面向外部用户、人数不可控的服务。按核心授权还有最低门槛通常是四核起算而且企业版按物理核心数计虚拟化环境下还要看宿主机的核心分布——这一条经常被低估一台宿主机上跑多台虚拟机授权计算方式会直接翻倍。MySQL 这边社区版免费企业版按服务器数量订阅包含备份工具、审计插件、线程池、防火墙这些在企业环境里经常被点名的功能。有意思的地方在于很多团队嘴上说“我们用的社区版”实际上备份方案是 Percona 的物理热备工具、监控是自己写的脚本、审计干脆没做。这些“自己动手”的成本不出现在账单上但会出现在人力上。真正做五年账本时我习惯把成本拆成四块成本项MySQL 社区版MySQL 企业版SQL Server 标准版SQL Server 企业版许可费用无按服务器订阅按核心计费按核心计费单价更高备份方案依赖第三方工具内置内置且功能完整内置且功能完整审计与合规需自行实现或买插件内置内置审计功能内置审计功能运维人力脚本能力要求高中等图形化程度高图形化程度高这张表最右边两列看起来贵但如果你的团队只有一个人管数据库还兼着网络和发布那“点几下就能配好日志传送”这件事的价值折算成人月可能比授权费还高。反过来如果团队里有愿意啃源码和参数的人MySQL 的性价比会非常突出。2.2 免费版的边界比想象中窄有个细节很多人到项目后期才发现轻量版并不是“缩水一点的正式版”它的限制会直接卡住业务。单库容量上限、缓冲池内存上限、可用核心数上限、缺少定时任务代理——最后这一条最要命意味着你不能在数据库层面做定时备份和定时统计只能把这个职责挪到应用层或者外部调度系统。MySQL 社区版没有这个问题因为它压根没做功能阉割社区版和企业版的差异主要在工具链和企业级特性上。但社区版也有自己的边界比如官方不提供热备份工具大库全量备份只能靠逻辑导出或者第三方物理备份前者恢复慢、后者需要额外维护。我一般的建议是先用免费版做原型但一定要在架构评审阶段就明确生产环境用哪一档因为这个决定会影响备份策略、监控方案甚至部署拓扑等上线前才发现限制改动面会很大。2.3 云上托管之后账本要重新算自建和托管是两套完全不同的成本结构。托管服务把授权、备份、高可用打包进单价看起来省心但计费维度和自建有偏差——存储按容量计费、备份按占用空间计费、跨可用区的网络流量也计费这些在自建时几乎为零。我的经验是中小规模数据库总容量几百 GB 以内、QPS 不过千上托管通常划算因为省下来的运维人力价值远超差价规模上去之后托管单价乘以体量会迅速超过自建加人力的总和这时候就该考虑混合模式把冷数据或者报表库单独挪出去。3. SQL 方言的裂缝迁移时会崩在哪几行代码上3.1 分页、自增、日期这些日常语法的对照迁移最容易被低估的就是这类“看起来一样”的语法。写代码时觉得 Select 语句都长一个样真搬过去才发现处处是坎。下面这张表是我整理的常用对照基本覆盖了日常开发九成的场景场景MySQL 写法SQL Server 写法备注自增主键AUTO_INCREMENTIDENTITY(1,1)见下文跳号问题分页LIMIT 20 OFFSET 40OFFSET 40 ROWS FETCH NEXT 20 ROWS ONLY后者要求先有 ORDER BY当前时间NOW()GETDATE()或SYSDATETIME()后者精度更高空值替换IFNULL(col, 0)ISNULL(col, 0)COALESCE两边通用字符串拼接CONCAT(a, b)a b或CONCATMySQL 里是数值加法分组拼接GROUP_CONCAT(col)STRING_AGG(col, ,)后者需要较新版本日期格式化DATE_FORMAT(t, %Y-%m)FORMAT(t, yyyy-MM)见下文性能问题标识符引用反引号方括号[]混用会导致解析失败布尔类型TINYINT(1)BIT取值语义不同表格里最值得单独拎出来说的是字符串拼接。MySQL 中a b的结果是 0因为它把两边都当数字处理a 转成 0、b 转成 0相加得 0而 SQL Server 中同样的表达式结果是ab。这个差异在迁移时极其隐蔽因为在原库里跑得好好的代码搬过去不会报错只会静默产出错误结果。日期格式化那条也有坑。SQL Server 的FORMAT函数内部走的是 CLR功能强但开销大在大结果集上逐行调用性能会掉一个数量级。线上见过把FORMAT放进 WHERE 条件里做月份筛选的写法几百万行跑了几十秒。正确做法是用范围查询替代函数包裹比如t 2024-03-01 AND t 2024-04-01让索引能吃上。3.2 隐式转换两个引擎截然不同的脾气MySQL 的类型转换非常“宽容”。拿字符串跟数字比较它会把字符串转成数字abc转成 0于是WHERE num_col abc会匹配到所有 num_col 为 0 的行。这个行为在写代码时是便利在生产上是灾难——而且它还会让索引失效因为列被隐式转换后无法走索引扫描。SQL Server 在这一点上严格得多字符串和数字直接比较通常会直接报转换错误逼着你在写代码时就把类型对齐。短期看是麻烦长期看是保护。但 SQL Server 也有自己的“反直觉”在默认排序规则下空字符串和纯空格在比较时被视为相等。也就是说WHERE name 可能匹配到名字是几个空格的记录。这个特性在做去重和数据校验时经常导致结果对不上。还有一个跨库迁移的经典报错排序规则冲突。当两张表来自不同排序规则的库或者临时表和业务表的排序规则不一致连接查询会直接抛出非法混合排序规则的错误。解决办法是在查询中显式指定COLLATE但这会让索引失效属于能用但不好用的方案。根治办法是在建库和建表阶段就把排序规则统一。3.3 DDL 与事务语义回滚这件事不总是成立MySQL 在建表、改表这类操作上会隐式提交当前事务。这意味着你不能把 DDL 和 DML 放在同一个事务里“要么全成功要么全失败”。较新版本虽然引入了原子 DDL保证单条 DDL 语句自身的原子性但隐式提交的行为没变。SQL Server 这边DDL 是可以放在事务里回滚的。写过发布脚本的人应该能体会这个差异带来的影响一边可以放心地“先改表结构出问题整体回滚”另一边必须靠严格的发布流程和回滚脚本兜底。另外事务嵌套的行为也不同。MySQL 没有真正的事务嵌套内层BEGIN只是被忽略只有最外层COMMIT才真正提交。SQL Server 用事务计数管理嵌套内层COMMIT只是把计数减一减到零才真正落盘。如果业务代码里有服务层和方法层各开一次事务的习惯迁移过去后事务边界会完全变样。4. 事务、锁与并发同一条 UPDATE 的两种命运4.1 默认隔离级别不同行为分歧从这里开始MySQL 的 InnoDB 默认是可重复读SQL Server 默认是读已提交。这一个默认值的差异会引发连锁反应。在可重复读下MySQL 为了防幻读会在范围查询上加间隙锁——锁的不只是存在的行还包括行与行之间的“空隙”。并发场景下两个事务分别拿着不同区间的间隙锁去插入很容易互相等待形成死锁。我遇到过一个典型案例一个批量导入任务按时间区间删除再插入另一个业务在相邻区间做同样的操作两个任务跑着跑着就死锁了报错日志里全是等待间隙锁。SQL Server 默认的读已提交不加间隙锁只有在显式加锁提示或者串行化级别下才会。所以同样的业务逻辑搬过去可能就顺了但代价是可能出现不可重复读——同一个事务里读两次结果不一样。想把 SQL Server 调成类似可重复读的效果可以启用基于行版本控制的读已提交快照隔离让读操作不阻塞写。这个开关在数据库级别一键开启但开了之后版本存储放在临时库需要预留空间否则高并发写入时临时库会迅速膨胀把磁盘吃满。4.2 行锁的实现基础走不走索引决定一切两个引擎都号称支持行级锁但“行锁”的前提不一样都建立在索引之上。MySQL 的 InnoDB 里如果 UPDATE 的 WHERE 条件没有可用的索引会退化为扫描并锁定大量记录在整个扫描过程中持有的锁范围可能接近全表。有人觉得“我加了行锁就是行锁”实际上执行计划一变锁的粒度立刻就变了。SQL Server 有个额外机制叫锁升级当一个语句在单张表上持有的锁数量超过阈值大致在几千这个量级会直接把锁升级为表级以减少锁管理开销。这个行为在批量更新时会突然让整张表不可写而且它不受语句级提示的完全控制只能说优先尝试不升级。这两个特性的实战含义是迁移之后一定要重新检查热点语句的执行计划不能假设原来的索引策略在新引擎上依然有效。我见过一个项目迁移后 QPS 掉了七成最后定位就是一条原本走索引的更新语句因为统计信息不准选了全表扫描锁范围从几十行变成几十万行。4.3 参数嗅探与执行计划缓存SQL Server 的参数嗅探是个老生常谈但依然高频的问题。存储过程第一次执行时优化器会根据传入的具体参数值生成执行计划并缓存后续复用这个计划。如果第一次传的是选择性很高的值比如某个仅有一条记录的 ID计划会倾向于索引查找但后续传入的选择性很低的值比如覆盖八成数据的类型字段这个计划就变成了灾难。MySQL 的预处理语句也有类似的计划缓存但行为没那么极端而且它有更灵活的计划重编译机制。SQL Server 的应对手段比较成熟可以用OPTION (RECOMPILE)强制重编译可以用OPTIMIZE FOR指定代表性参数也可以开启数据库级的自动调优。但这些手段都有副作用重编译频繁会消耗 CPU需要按语句逐一评估。我的做法是对执行频率高、参数分布差异大的语句先看缓存计划的使用次数和平均耗时如果差异明显再做针对性处理不要一上来就全局开重编译。5. 高可用与备份出事那天才知道谁靠谱5.1 复制与可用性组的思路差异MySQL 的原生复制是基于二进制日志的异步复制主库写完日志就返回从库自己拉取重放。这套机制简单可靠但异步意味着主库崩溃时可能丢最后一段数据。半同步复制能缓解这个问题——主库至少等一个从库确认收到日志才返回代价是写入延迟变高而且从库网络抖动会直接拖慢主库。再往上走是组复制方案基于一致性协议做多副本同步支持自动选主和故障转移配合路由组件可以形成一套完整的高可用集群。部署复杂度明显上一个台阶需要奇数个节点、需要处理网络分区场景运维门槛不低。SQL Server 的可用性组是另一套思路它把一组数据库作为一个整体做复制副本之间可以配置同步或异步模式同步模式下主副本提交事务前要等辅助副本确认写入。读流量可以路由到辅助副本做读写分离比较自然。故障转移可以是自动的配合监听器让应用端连接串不变。两者对比MySQL 的方案更轻、组件更分散灵活但需要自己组装SQL Server 的方案更整合、开箱即用但绑定在特定平台和版本上跨平台部署时周边工具的支持会打折。5.2 备份恢复的时间点能力备份这件事平时看不出差别出事时差一分钟就是几小时的停机。MySQL 的逻辑备份工具简单通用但导出和恢复都是单线程的大库动辄几小时。物理备份工具能显著缩短时间但需要额外部署而且对版本一致性有要求。增量备份的支持在社区版里比较弱通常要依赖文件系统快照或者第三方方案。SQL Server 的备份体系是原生完整的完整备份、差异备份、事务日志备份三级组合配合日志链可以恢复到任意时间点。备份支持压缩和加密还原时可以只还原部分数据文件。这套能力在合规审计场景里是硬需求。需要注意的一点是日志备份不是开了就完事日志链一旦断裂比如误做了一次完整备份覆盖或者切换了恢复模式之前的时间点就恢复不了了。我见过因为没有监控日志链断裂真出事时只能恢复到前一天的情况。6. 性能观察出问题时你手上有什么工具6.1 慢查询从哪里开始看MySQL 的慢查询日志是最直接的入口配置阈值之后把超过阈值的语句记下来再用分析工具做聚合和排序。性能模式库提供了更细的等待事件统计能看出时间花在锁等待、IO 还是 CPU 上。SQL Server 这边图形化的活动监视器能快速看到当前阻塞和资源消耗扩展事件可以抓取细粒度执行信息查询存储则把历史执行计划的变化都记下来——这一点很实用能直接对比同一条语句昨天的计划和今天为什么不同。工具层面的差异其实是表象真正的差别在于分析路径。MySQL 的排查往往从慢日志出发逐条看执行计划SQL Server 更倾向于先看整体等待类型分布判断瓶颈在 IO、CPU、内存还是锁再下钻到具体语句。后者的思路更系统但需要一定的经验积累。6.2 索引结构的根本不同决定了设计思路MySQL 的 InnoDB 里表本身就是一棵以主键为键的聚簇索引树数据行直接挂在叶子节点上二级索引的叶子节点存的是主键值查询非索引列时需要回表。所以主键的选择对这个引擎格外重要——用随机值做主键会导致页分裂和写入放大用自增整数则顺序写入效率高得多。SQL Server 里表默认是堆结构除非你显式建聚集索引。主键默认会建成聚集索引但也可以建成非聚集。这意味着同一个逻辑模型在两边的最优物理设计可能完全不同。在 SQL Server 里可以做到“一张表一个聚集索引多个非聚集索引覆盖不同查询”设计自由度更高在 MySQL 里主键定了就改不了物理顺序除非重建表。覆盖索引这个概念两边都有但要注意 MySQL 的二级索引天然带主键所以按主键查询的覆盖成本更低SQL Server 的非聚集索引带的是聚集键或者行标识包含的列需要显式声明。7. 我的选型决策表以及一个常被忽略的第三条路7.1 这些场景我会倾向 MySQL互联网面向用户的业务系统、需要横向扩展读能力的场景、团队里有能写运维脚本的人、预期数据量会涨到单实例扛不住需要分片——这几条满足两条以上我基本会选 MySQL。它的生态在分库分表、中间件、云托管上的成熟度确实高遇到问题搜到的答案也更多。还有一个隐性优势它对硬件的要求更温和。同样配置的机器跑 MySQL 能撑住的并发连接数通常更高因为每个连接的开销更小。当然这不绝对要看具体负载类型。7.2 这些场景我会倾向 SQL Server内部管理系统、报表和数据分析占比高的系统、存量代码有大量存储过程和 T-SQL 逻辑、运维人力有限但预算充足、技术栈本身在对应生态里——这些情况选它省心。它的查询优化器在复杂多表连接上的表现相当稳做报表类查询时写起来也顺手。需要提醒的是即使选它也要提前规划好版本。不同版本在内存上限、可用核心数、高可用特性上差异很大标准版和企业版之间的鸿沟不小别等到需要某个特性时才发现版本不支持。7.3 还有一条路按负载拆库我最近两个项目都没有做二选一。核心交易走一个引擎报表和离线分析走另一个中间用数据同步工具打通。这样交易库可以按自己的节奏优化写入分析库用自己擅长的引擎做聚合互不干扰。代价是同步链路的运维复杂度上升需要处理延迟、断点续传、字段类型映射这些问题。如果团队规模小我不建议一上来就这么干先把单库调优做到位更实际。最后分享一个实操中的体会做选型评估时别只看功能列表拿自己业务里最复杂的三条 SQL 到两个引擎上各跑一遍看执行计划和耗时。这半小时的验证比看十篇对比文章都有用。另外无论选哪个把索引设计与执行计划审查纳入代码评审流程这条经验在两个引擎上都成立而且是投入产出比最高的一件事。
接手一个中等规模的后台系统时摆在桌上的第一个技术决策往往不是微服务怎么拆、缓存用哪家而是数据库这台“地基”踩在哪里。我碰到过不止一次这样的场面会议室里两拨人各说各话一拨人坚持开源栈的 MySQL理由是不花钱、生态烂大街、招人容易另一拨人死守 SQL Server理由是存储过程写得爽、报表工具配套齐、运维界面点几下就能把活干完。吵到最后往往不是靠技术定胜负而是谁嗓门大或者谁资历老。MySQL 与 SQL Server 的对比几乎每个做后端的人都绕不开一次但网上的答案大多停留在“开源 vs 商业”“免费 vs 收费”这种表层。真到落地那天让你熬夜的绝不是许可证价格而是某条 UPDATE 语句在两边表现不一样、某个分页语法迁移过去直接报错、某张表锁的粒度完全失控。这篇会把我在多个项目里踩过的差异点摊开讲从授权账本、SQL 方言、并发模型、高可用、调优路径五个维度掰扯清楚适合正在做技术选型的架构师也适合只是想知道“换库到底会疼在哪”的开发同学。1. 那次差点吵翻的选型会暴露出什么问题1.1 两派人的理由其实都不完整坚持 MySQL 的那一拨核心论点浓缩起来就三句话不要钱、社区资料多、DBA 好招。这三句听着都对但每一句都有个隐藏前提。不要钱指的是社区版企业版该花的钱一分不少而且更要命的是 GPL 协议对分发场景的约束——如果你的产品是以镜像或私有化部署方式交付给客户的法务那边通常会要求你重新审视一下协议义务。社区资料多也是相对的中文博客里大把内容是抄来抄去的真正讲到间隙锁在什么条件下会拖垮一批插入的未必有几篇。坚持 SQL Server 的那一拨理由则是开发体验好、周边组件齐、Windows 环境无缝。这话同样成立但代价被轻描淡写了按核心计费的授权模型在云主机上跑个十几核的实例年费不是小数目而且这套生态的重心始终在 Windows 那一侧如果团队的技术栈已经倒向容器化部署很多便利会打折扣。我后来把这场争论归结为一句话大家在用各自项目的成功经验论证一个通用结论。这本身就是错位。1.2 我判断这件事的三个坐标轴踩过几次坑之后我形成了比较固定的判断框架只在三个轴上称重其余都是噪音。第一是规模与增长曲线。单表数据量是千万级还是十亿级决定了你对分区、分片、中间件的依赖程度而这两个引擎在这条路上的成熟度并不对称。第二是团队的既有资产。存量代码是不是用了大量存储过程和 T-SQL 特有语法、报表体系和 ETL 是不是绑在某个生态里这些沉没成本往往比授权费更贵。第三是运维人力的形状。有人愿意写脚本、看监控、调参数MySQL 会变得非常可控如果运维只有半个人、希望图形化点两下就能备份和排查那商业产品的完整度是实打实的优势。这三个轴交叉起来答案基本就浮出来了。下面几章我会把每个轴上的具体细节展开因为选型判断最怕的就是“大概知道”真出事时那点模糊会要命。2. 授权与总拥有成本五年账本怎么算才不失真2.1 两种计费模型的实际差异SQL Server 的授权模型有两套Server CAL 和按核心授权。前者适合用户数明确的内部系统比如一个只有几十个员工用的 ERP后者适合面向外部用户、人数不可控的服务。按核心授权还有最低门槛通常是四核起算而且企业版按物理核心数计虚拟化环境下还要看宿主机的核心分布——这一条经常被低估一台宿主机上跑多台虚拟机授权计算方式会直接翻倍。MySQL 这边社区版免费企业版按服务器数量订阅包含备份工具、审计插件、线程池、防火墙这些在企业环境里经常被点名的功能。有意思的地方在于很多团队嘴上说“我们用的社区版”实际上备份方案是 Percona 的物理热备工具、监控是自己写的脚本、审计干脆没做。这些“自己动手”的成本不出现在账单上但会出现在人力上。真正做五年账本时我习惯把成本拆成四块成本项MySQL 社区版MySQL 企业版SQL Server 标准版SQL Server 企业版许可费用无按服务器订阅按核心计费按核心计费单价更高备份方案依赖第三方工具内置内置且功能完整内置且功能完整审计与合规需自行实现或买插件内置内置审计功能内置审计功能运维人力脚本能力要求高中等图形化程度高图形化程度高这张表最右边两列看起来贵但如果你的团队只有一个人管数据库还兼着网络和发布那“点几下就能配好日志传送”这件事的价值折算成人月可能比授权费还高。反过来如果团队里有愿意啃源码和参数的人MySQL 的性价比会非常突出。2.2 免费版的边界比想象中窄有个细节很多人到项目后期才发现轻量版并不是“缩水一点的正式版”它的限制会直接卡住业务。单库容量上限、缓冲池内存上限、可用核心数上限、缺少定时任务代理——最后这一条最要命意味着你不能在数据库层面做定时备份和定时统计只能把这个职责挪到应用层或者外部调度系统。MySQL 社区版没有这个问题因为它压根没做功能阉割社区版和企业版的差异主要在工具链和企业级特性上。但社区版也有自己的边界比如官方不提供热备份工具大库全量备份只能靠逻辑导出或者第三方物理备份前者恢复慢、后者需要额外维护。我一般的建议是先用免费版做原型但一定要在架构评审阶段就明确生产环境用哪一档因为这个决定会影响备份策略、监控方案甚至部署拓扑等上线前才发现限制改动面会很大。2.3 云上托管之后账本要重新算自建和托管是两套完全不同的成本结构。托管服务把授权、备份、高可用打包进单价看起来省心但计费维度和自建有偏差——存储按容量计费、备份按占用空间计费、跨可用区的网络流量也计费这些在自建时几乎为零。我的经验是中小规模数据库总容量几百 GB 以内、QPS 不过千上托管通常划算因为省下来的运维人力价值远超差价规模上去之后托管单价乘以体量会迅速超过自建加人力的总和这时候就该考虑混合模式把冷数据或者报表库单独挪出去。3. SQL 方言的裂缝迁移时会崩在哪几行代码上3.1 分页、自增、日期这些日常语法的对照迁移最容易被低估的就是这类“看起来一样”的语法。写代码时觉得 Select 语句都长一个样真搬过去才发现处处是坎。下面这张表是我整理的常用对照基本覆盖了日常开发九成的场景场景MySQL 写法SQL Server 写法备注自增主键AUTO_INCREMENTIDENTITY(1,1)见下文跳号问题分页LIMIT 20 OFFSET 40OFFSET 40 ROWS FETCH NEXT 20 ROWS ONLY后者要求先有 ORDER BY当前时间NOW()GETDATE()或SYSDATETIME()后者精度更高空值替换IFNULL(col, 0)ISNULL(col, 0)COALESCE两边通用字符串拼接CONCAT(a, b)a b或CONCATMySQL 里是数值加法分组拼接GROUP_CONCAT(col)STRING_AGG(col, ,)后者需要较新版本日期格式化DATE_FORMAT(t, %Y-%m)FORMAT(t, yyyy-MM)见下文性能问题标识符引用反引号方括号[]混用会导致解析失败布尔类型TINYINT(1)BIT取值语义不同表格里最值得单独拎出来说的是字符串拼接。MySQL 中a b的结果是 0因为它把两边都当数字处理a 转成 0、b 转成 0相加得 0而 SQL Server 中同样的表达式结果是ab。这个差异在迁移时极其隐蔽因为在原库里跑得好好的代码搬过去不会报错只会静默产出错误结果。日期格式化那条也有坑。SQL Server 的FORMAT函数内部走的是 CLR功能强但开销大在大结果集上逐行调用性能会掉一个数量级。线上见过把FORMAT放进 WHERE 条件里做月份筛选的写法几百万行跑了几十秒。正确做法是用范围查询替代函数包裹比如t 2024-03-01 AND t 2024-04-01让索引能吃上。3.2 隐式转换两个引擎截然不同的脾气MySQL 的类型转换非常“宽容”。拿字符串跟数字比较它会把字符串转成数字abc转成 0于是WHERE num_col abc会匹配到所有 num_col 为 0 的行。这个行为在写代码时是便利在生产上是灾难——而且它还会让索引失效因为列被隐式转换后无法走索引扫描。SQL Server 在这一点上严格得多字符串和数字直接比较通常会直接报转换错误逼着你在写代码时就把类型对齐。短期看是麻烦长期看是保护。但 SQL Server 也有自己的“反直觉”在默认排序规则下空字符串和纯空格在比较时被视为相等。也就是说WHERE name 可能匹配到名字是几个空格的记录。这个特性在做去重和数据校验时经常导致结果对不上。还有一个跨库迁移的经典报错排序规则冲突。当两张表来自不同排序规则的库或者临时表和业务表的排序规则不一致连接查询会直接抛出非法混合排序规则的错误。解决办法是在查询中显式指定COLLATE但这会让索引失效属于能用但不好用的方案。根治办法是在建库和建表阶段就把排序规则统一。3.3 DDL 与事务语义回滚这件事不总是成立MySQL 在建表、改表这类操作上会隐式提交当前事务。这意味着你不能把 DDL 和 DML 放在同一个事务里“要么全成功要么全失败”。较新版本虽然引入了原子 DDL保证单条 DDL 语句自身的原子性但隐式提交的行为没变。SQL Server 这边DDL 是可以放在事务里回滚的。写过发布脚本的人应该能体会这个差异带来的影响一边可以放心地“先改表结构出问题整体回滚”另一边必须靠严格的发布流程和回滚脚本兜底。另外事务嵌套的行为也不同。MySQL 没有真正的事务嵌套内层BEGIN只是被忽略只有最外层COMMIT才真正提交。SQL Server 用事务计数管理嵌套内层COMMIT只是把计数减一减到零才真正落盘。如果业务代码里有服务层和方法层各开一次事务的习惯迁移过去后事务边界会完全变样。4. 事务、锁与并发同一条 UPDATE 的两种命运4.1 默认隔离级别不同行为分歧从这里开始MySQL 的 InnoDB 默认是可重复读SQL Server 默认是读已提交。这一个默认值的差异会引发连锁反应。在可重复读下MySQL 为了防幻读会在范围查询上加间隙锁——锁的不只是存在的行还包括行与行之间的“空隙”。并发场景下两个事务分别拿着不同区间的间隙锁去插入很容易互相等待形成死锁。我遇到过一个典型案例一个批量导入任务按时间区间删除再插入另一个业务在相邻区间做同样的操作两个任务跑着跑着就死锁了报错日志里全是等待间隙锁。SQL Server 默认的读已提交不加间隙锁只有在显式加锁提示或者串行化级别下才会。所以同样的业务逻辑搬过去可能就顺了但代价是可能出现不可重复读——同一个事务里读两次结果不一样。想把 SQL Server 调成类似可重复读的效果可以启用基于行版本控制的读已提交快照隔离让读操作不阻塞写。这个开关在数据库级别一键开启但开了之后版本存储放在临时库需要预留空间否则高并发写入时临时库会迅速膨胀把磁盘吃满。4.2 行锁的实现基础走不走索引决定一切两个引擎都号称支持行级锁但“行锁”的前提不一样都建立在索引之上。MySQL 的 InnoDB 里如果 UPDATE 的 WHERE 条件没有可用的索引会退化为扫描并锁定大量记录在整个扫描过程中持有的锁范围可能接近全表。有人觉得“我加了行锁就是行锁”实际上执行计划一变锁的粒度立刻就变了。SQL Server 有个额外机制叫锁升级当一个语句在单张表上持有的锁数量超过阈值大致在几千这个量级会直接把锁升级为表级以减少锁管理开销。这个行为在批量更新时会突然让整张表不可写而且它不受语句级提示的完全控制只能说优先尝试不升级。这两个特性的实战含义是迁移之后一定要重新检查热点语句的执行计划不能假设原来的索引策略在新引擎上依然有效。我见过一个项目迁移后 QPS 掉了七成最后定位就是一条原本走索引的更新语句因为统计信息不准选了全表扫描锁范围从几十行变成几十万行。4.3 参数嗅探与执行计划缓存SQL Server 的参数嗅探是个老生常谈但依然高频的问题。存储过程第一次执行时优化器会根据传入的具体参数值生成执行计划并缓存后续复用这个计划。如果第一次传的是选择性很高的值比如某个仅有一条记录的 ID计划会倾向于索引查找但后续传入的选择性很低的值比如覆盖八成数据的类型字段这个计划就变成了灾难。MySQL 的预处理语句也有类似的计划缓存但行为没那么极端而且它有更灵活的计划重编译机制。SQL Server 的应对手段比较成熟可以用OPTION (RECOMPILE)强制重编译可以用OPTIMIZE FOR指定代表性参数也可以开启数据库级的自动调优。但这些手段都有副作用重编译频繁会消耗 CPU需要按语句逐一评估。我的做法是对执行频率高、参数分布差异大的语句先看缓存计划的使用次数和平均耗时如果差异明显再做针对性处理不要一上来就全局开重编译。5. 高可用与备份出事那天才知道谁靠谱5.1 复制与可用性组的思路差异MySQL 的原生复制是基于二进制日志的异步复制主库写完日志就返回从库自己拉取重放。这套机制简单可靠但异步意味着主库崩溃时可能丢最后一段数据。半同步复制能缓解这个问题——主库至少等一个从库确认收到日志才返回代价是写入延迟变高而且从库网络抖动会直接拖慢主库。再往上走是组复制方案基于一致性协议做多副本同步支持自动选主和故障转移配合路由组件可以形成一套完整的高可用集群。部署复杂度明显上一个台阶需要奇数个节点、需要处理网络分区场景运维门槛不低。SQL Server 的可用性组是另一套思路它把一组数据库作为一个整体做复制副本之间可以配置同步或异步模式同步模式下主副本提交事务前要等辅助副本确认写入。读流量可以路由到辅助副本做读写分离比较自然。故障转移可以是自动的配合监听器让应用端连接串不变。两者对比MySQL 的方案更轻、组件更分散灵活但需要自己组装SQL Server 的方案更整合、开箱即用但绑定在特定平台和版本上跨平台部署时周边工具的支持会打折。5.2 备份恢复的时间点能力备份这件事平时看不出差别出事时差一分钟就是几小时的停机。MySQL 的逻辑备份工具简单通用但导出和恢复都是单线程的大库动辄几小时。物理备份工具能显著缩短时间但需要额外部署而且对版本一致性有要求。增量备份的支持在社区版里比较弱通常要依赖文件系统快照或者第三方方案。SQL Server 的备份体系是原生完整的完整备份、差异备份、事务日志备份三级组合配合日志链可以恢复到任意时间点。备份支持压缩和加密还原时可以只还原部分数据文件。这套能力在合规审计场景里是硬需求。需要注意的一点是日志备份不是开了就完事日志链一旦断裂比如误做了一次完整备份覆盖或者切换了恢复模式之前的时间点就恢复不了了。我见过因为没有监控日志链断裂真出事时只能恢复到前一天的情况。6. 性能观察出问题时你手上有什么工具6.1 慢查询从哪里开始看MySQL 的慢查询日志是最直接的入口配置阈值之后把超过阈值的语句记下来再用分析工具做聚合和排序。性能模式库提供了更细的等待事件统计能看出时间花在锁等待、IO 还是 CPU 上。SQL Server 这边图形化的活动监视器能快速看到当前阻塞和资源消耗扩展事件可以抓取细粒度执行信息查询存储则把历史执行计划的变化都记下来——这一点很实用能直接对比同一条语句昨天的计划和今天为什么不同。工具层面的差异其实是表象真正的差别在于分析路径。MySQL 的排查往往从慢日志出发逐条看执行计划SQL Server 更倾向于先看整体等待类型分布判断瓶颈在 IO、CPU、内存还是锁再下钻到具体语句。后者的思路更系统但需要一定的经验积累。6.2 索引结构的根本不同决定了设计思路MySQL 的 InnoDB 里表本身就是一棵以主键为键的聚簇索引树数据行直接挂在叶子节点上二级索引的叶子节点存的是主键值查询非索引列时需要回表。所以主键的选择对这个引擎格外重要——用随机值做主键会导致页分裂和写入放大用自增整数则顺序写入效率高得多。SQL Server 里表默认是堆结构除非你显式建聚集索引。主键默认会建成聚集索引但也可以建成非聚集。这意味着同一个逻辑模型在两边的最优物理设计可能完全不同。在 SQL Server 里可以做到“一张表一个聚集索引多个非聚集索引覆盖不同查询”设计自由度更高在 MySQL 里主键定了就改不了物理顺序除非重建表。覆盖索引这个概念两边都有但要注意 MySQL 的二级索引天然带主键所以按主键查询的覆盖成本更低SQL Server 的非聚集索引带的是聚集键或者行标识包含的列需要显式声明。7. 我的选型决策表以及一个常被忽略的第三条路7.1 这些场景我会倾向 MySQL互联网面向用户的业务系统、需要横向扩展读能力的场景、团队里有能写运维脚本的人、预期数据量会涨到单实例扛不住需要分片——这几条满足两条以上我基本会选 MySQL。它的生态在分库分表、中间件、云托管上的成熟度确实高遇到问题搜到的答案也更多。还有一个隐性优势它对硬件的要求更温和。同样配置的机器跑 MySQL 能撑住的并发连接数通常更高因为每个连接的开销更小。当然这不绝对要看具体负载类型。7.2 这些场景我会倾向 SQL Server内部管理系统、报表和数据分析占比高的系统、存量代码有大量存储过程和 T-SQL 逻辑、运维人力有限但预算充足、技术栈本身在对应生态里——这些情况选它省心。它的查询优化器在复杂多表连接上的表现相当稳做报表类查询时写起来也顺手。需要提醒的是即使选它也要提前规划好版本。不同版本在内存上限、可用核心数、高可用特性上差异很大标准版和企业版之间的鸿沟不小别等到需要某个特性时才发现版本不支持。7.3 还有一条路按负载拆库我最近两个项目都没有做二选一。核心交易走一个引擎报表和离线分析走另一个中间用数据同步工具打通。这样交易库可以按自己的节奏优化写入分析库用自己擅长的引擎做聚合互不干扰。代价是同步链路的运维复杂度上升需要处理延迟、断点续传、字段类型映射这些问题。如果团队规模小我不建议一上来就这么干先把单库调优做到位更实际。最后分享一个实操中的体会做选型评估时别只看功能列表拿自己业务里最复杂的三条 SQL 到两个引擎上各跑一遍看执行计划和耗时。这半小时的验证比看十篇对比文章都有用。另外无论选哪个把索引设计与执行计划审查纳入代码评审流程这条经验在两个引擎上都成立而且是投入产出比最高的一件事。
