如果你和我一样手里同时管着好几套数据库MySQL、PostgreSQL、SQL Server、Oracle 换来换去你一定体会过那种“明明会写 SQL但换个数据库就卡壳”的憋屈感。分页语法不一样去重写法不一样字符串拼接不一样连处理空值的函数都各有各的脾气。我花了不少时间整理了一份能覆盖这些场景的定制版 SQL 速查表核心目标就三个字少翻文档。这篇文章就是把那份速查表的关键内容拆开讲顺便把我在适配多个数据库时踩过的坑和排错思路一起放进去希望能给你省点功夫。这份速查表不是什么高深理论就是实打实的常用语法对照、典型场景写法和优化思路。适合谁看刚入门 SQL 的新人可以把它当成字典随时查写了好几年 SQL 但偶尔要在不同数据库之间切来切去的老手也能从对照关系里找到自己容易忽略的细节。我尽量把“为什么这么写”也讲清楚毕竟死记语法不如理解语法背后的逻辑。1. 速查表的设计思路多数据库适配到底在适配什么1.1 方言差异的本质是产品取向不同很多人第一次意识到 SQL 方言是个麻烦事通常是在换数据库的时候。比如在 MySQL 里写得好好的LIMIT 10拿到 SQL Server 里直接报语法错误因为 SQL Server 用的是TOP 10。再比如 Oracle 老版本里没有LIMIT你得用ROWNUM包一层子查询。你说这烦不烦烦但理解了背后的逻辑就不难记。SQL 标准本身是存在的但各个数据库厂商在标准之外都会扩展自己的语法原因很简单标准只规定了“最小可用”的公共能力厂商要做出差异化就得在语法上做加法。MySQL 的LIMIT简洁直观SQL Server 的TOP写法更靠近英文直觉Oracle 的ROWNUM是基于物理行号的古老设计PostgreSQL 则在 SQL 标准之外提供了更灵活的FETCH FIRST子句。你不需要背下所有写法但你需要一张对照表知道“同一个需求每个库该怎么表达”。我整理速查表的第一步就是把高频操作按“功能”而不是按“数据库”分类。比如分页是一类去重是一类空值处理是一类日期操作是一类。每一类下面再列出 MySQL、PostgreSQL、SQL Server、Oracle 四种写法。这样一来当你脑子里冒出“我要分页查 10 条数据”这个需求时你查的是“分页”这一行而不是去回忆某个数据库的某个特殊语法。1.2 全场景覆盖的边界怎么划所谓“全场景覆盖”听起来很唬人其实核心是覆盖日常工作中出现频率最高的那 80% 的场景。我当初列清单的时候给自己定了个原则不追求把所有冷门函数都收进去但凡是线上出过事故、群里面被问过三次以上的写法必须收录。按照这个原则我分了几个大的模块基础查询SELECT、JOIN、GROUP BY、数据操作INSERT、UPDATE、DELETE、高级查询窗口函数、子查询、CTE、函数速查字符串、日期、空值、转换、性能优化索引、执行计划、慢查询、安全注入原理、防注入写法。每个模块再拆成具体的“场景点”比如去重就有DISTINCT、GROUP BY、ROW_NUMBER()三种写法分别对应不同的需求。这个设计当时有个小插曲。我最初只做了 MySQL 和 PostgreSQL 两列后来接手了一个同时跑 SQL Server 和 Oracle 的老项目被迫把表格扩展成了四列。扩展过程非常痛苦因为有些语法在四个库里差异极大比如分页MySQL 是LIMIT offset, countPostgreSQL 也是LIMIT但推荐OFFSET子句独立写SQL Server 是OFFSET...FETCH NEXTOracle 11g 及以下只能用ROWNUM12c 以上才有FETCH FIRST。这种差异如果不用表格列出来光靠记忆真的会翻车。2. 高频场景速查从分页到去重再到空值2.1 分页查询四个库四种写法分页是我遇到的最典型的方言差异也是速查表里最值得先看的部分。需求很简单每页 20 条查第 3 页也就是跳过前 40 条取接下来的 20 条。MySQL 的写法最简单直接SELECT * FROM orders ORDER BY id LIMIT 40, 20;LIMIT 40, 20表示从第 41 行开始取 20 行。注意这里是“偏移量在前行数在后”很多人第一次写容易搞反。PostgreSQL 支持 MySQL 那种LIMIT写法但更规范的做法是用OFFSETSELECT * FROM orders ORDER BY id LIMIT 20 OFFSET 40;这里的语义更接近自然语言取 20 行跳过 40 行。SQL Server 2012 及以上版本支持OFFSET...FETCH语法SELECT * FROM orders ORDER BY id OFFSET 40 ROWS FETCH NEXT 20 ROWS ONLY;注意SQL Server 要求在使用OFFSET时必须配上ORDER BY没有ORDER BY直接报错。我第一次写的时候还纳闷为什么一样的逻辑在别的库不强制到这儿就强制了。后来一想SQL Server 是想确保分页结果的可预测性没有排序的分页本身就没意义。Oracle 12c 及以上版本引入了FETCH FIRSTSELECT * FROM orders ORDER BY id OFFSET 40 ROWS FETCH NEXT 20 ROWS ONLY;但在 11g 及以下版本只能靠ROWNUM迂回实现SELECT * FROM ( SELECT t.*, ROWNUM rn FROM orders t ORDER BY id ) WHERE rn 40 AND rn 60;这个写法的原理是先用子查询给每行标上ROWNUM然后在外层过滤。要注意ROWNUM是在排序之前分配的所以必须先把排序好的结果包成子查询否则分页结果就是乱的。实操建议如果你的项目是长期维护的分页查询最好封装成统一的数据访问层接口把方言差异隔离在底层。不然每个报表页面里都散落着各种风格的分页 SQL后面维护的人会想打人。2.2 去重的三把刀DISTINCT、GROUP BY、窗口函数去重是日常需求里最容易被写错的地方。很多人一上来就SELECT DISTINCT但DISTINCT有它的局限它只能对查询返回的整行去重。如果你只想根据某个字段去重同时还要保留其他字段的信息DISTINCT就无能为力了。举个例子订单表里有user_id和product_id你想知道每个用户买了哪些商品。如果直接查SELECT DISTINCT user_id, product_id结果是把“同一个用户买了不同商品”的每一行都保留这没问题。但如果需求变成“每个用户最近一次购买的商品”DISTINCT完全帮不上忙因为你要的不是“去重”而是“分组取一条”。这个时候有两个选择。第一个是用GROUP BY配合聚合函数SELECT user_id, MAX(product_id) FROM orders GROUP BY user_id;这个写法的逻辑是“按用户分组取每个组里 product_id 最大的那一条”。但注意这种写法只能返回参与聚合的字段如果你还想带上订单时间order_date就得小心了。在 MySQL 里这个 SQL 有时候能跑通但返回的order_date是组内随机一行的时间行为不可控。在 SQL Server 和 PostgreSQL 里select 列表中包含非聚合字段而没放进GROUP BY直接报语法错误。第二个选择是用窗口函数ROW_NUMBER()这也是我推荐的做法SELECT user_id, product_id, order_date FROM ( SELECT t.*, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date DESC) rn FROM orders t ) x WHERE x.rn 1;这个写法的逻辑很清晰按用户分组PARTITION BY user_id组内按订单时间倒序编号最后保留每组第 1 条。好处是你可以放心地把所有字段都带出来不会出现“查到了但不知道是哪一行”的尴尬。注意需要真正消除重复行且不关心额外字段时用DISTINCT最省事需要“每个分组取一条”时请直接用窗口函数别用GROUP BY硬凑。2.3 空值处理不是每个库都叫 IFNULL处理空值看着简单实际上是最容易出现跨库兼容问题的场景之一。MySQL 里的IFNULL(expr1, expr2)在 SQL Server 里不存在PostgreSQL 里也没有Oracle 也不认。但几乎每个数据库都支持标准 SQL 的COALESCE(expr1, expr2, ...)它的语义是返回第一个非空表达式。我自己的习惯是能用COALESCE就尽量用COALESCE因为它跨库兼容性最好而且支持多个参数比IFNULL和NVL更灵活。只有在特定的库里写一次性脚本时才会用库原生的函数。还有个容易踩的坑是“空值过滤”。需求是“去掉某个字段为空的行”初学者常写成SELECT * FROM orders WHERE order_date ! 2024-01-01;这个写法在遇到order_date为NULL时会让你以为条件生效了实际上NULL既不等于也不等于任何值它会被默默过滤掉。如果想要“不等于这个日期同时包含 NULL”必须显式写SELECT * FROM orders WHERE order_date IS DISTINCT FROM 2024-01-01;注意IS DISTINCT FROM是 PostgreSQL 和标准 SQL 的写法MySQL 也支持但 SQL Server 和 Oracle 不支持。跨库时你得拆成两步SELECT * FROM orders WHERE order_date ! 2024-01-01 OR order_date IS NULL;类似的需求还有“去除空值”。热搜词里出现了“sql去除空值”“清洗---sql语句去重”说明大家在数据清洗阶段经常遇到这类需求。数据清洗时你要明确“空值”的定义是NULL还是空字符串还是纯空格 三者处理方式完全不同。建议在速查表里专门留一块位置写下你常用数据库里判断空值的标准写法避免每次现想。3. 窗口函数速查现代 SQL 的进阶必备3.1 窗口函数和普通 GROUP BY 的本质区别窗口函数这几年很火因为它解决了一类 GROUP BY 解决不了的问题既要分组聚合又要保留明细行。GROUP BY 会把多行压成一行窗口函数则是在不压缩行数的情况下把聚合结果附加到每一行上。举个例子你要计算“每个用户的订单总金额同时保留每一笔订单的明细”。GROUP BY 做不到因为分组后行数就少了。窗口函数可以SELECT user_id, order_id, amount, SUM(amount) OVER (PARTITION BY user_id) AS user_total FROM orders;每一行都会带上user_total这个字段代表该用户所有订单的总金额但行数没有减少。理解了这个区别很多看似复杂的场景就有了统一的解法思路。比如求“每个用户订单金额排名前 3 的商品”用窗口函数RANK()或DENSE_RANK()就能在子查询里搞定。3.2 主流数据库窗口函数支持情况窗口函数是 SQL:2003 标准引入的现在主流数据库基本都支持但支持的细节有差异。MySQL 从 8.0 开始支持窗口函数8.0 以下版本完全不能用。PostgreSQL 从 9.4 开始支持得比较完整。SQL Server 从 2005 年开始支持语法也稳定。Oracle 是窗口函数的老玩家早在 9i 就支持了写法上还额外提供了KEEP等扩展。在速查表里我建议把窗口函数的常用场景分成三类排名类ROW_NUMBER、RANK、DENSE_RANK、聚合类SUM、AVG、COUNT配合OVER、偏移类LAG、LEAD、FIRST_VALUE、LAST_VALUE。排名类里最容易混淆的是RANK和DENSE_RANK的区别。假设成绩有两个人并列第一RANK()会生成 1、1、3 这样的编号DENSE_RANK()则生成 1、1、2。前者的编号会跳过后者的编号连续。有时候业务方要的是“我们有两个第一名那么第三名排第 3 名”有时候要的是“第三名实质上是第二梯队”。需求一模糊写错函数就是事故。偏移类里我最常用的是LAG和LEAD它们用来访问同一分组内前一行或后一行的值。比如计算“订单之间的时间间隔”可以先按用户分组、按时间排序然后用LAG(order_date)拿到上一笔订单时间再相减。这个写法在报表开发里极其常见。3.3 一个可直接复用的典型例子分组内排名光说不练没意义。我放一个我实际做过的例子销售报表每个区域按销售额排名保留销售额前 5 的区域负责人。MySQL 8.0 / PostgreSQL / SQL Server / Oracle 通用写法SELECT * FROM ( SELECT area, salesperson, sales_amount, DENSE_RANK() OVER (PARTITION BY area ORDER BY sales_amount DESC) rnk FROM sales_records ) ranked WHERE rnk 5;这里的逻辑是按area分组组内按sales_amount降序排名然后在外层过滤出排名小于等于 5 的记录。这个 SQL 在四个库里都能跑不需要做任何方言适配因为窗口函数本身是通用标准。这也是我特别喜欢窗口函数的原因一旦用上跨库移植的成本会小很多。需要注意的一点是PARTITION BY后面的字段和ORDER BY后面的字段不要搞混。PARTITION BY是“分组的维度”ORDER BY是“组内排序的规则”。我见过不少新手把ORDER BY sales_amount DESC误写成PARTITION BY sales_amount DESC结果分组维度直接错了查询结果完全对不上。4. 慢 SQL 优化速查从定位到改写的一线经验4.1 先看执行计划别凭感觉优化热搜词里“slow sql优化”出现次数不低说明慢 SQL 是很多人的日常痛点。我自己的习惯是拿到一条慢 SQL第一件事不是看 SQL 本身而是看执行计划。MySQL 里在 SQL 前面加EXPLAINPostgreSQL 用EXPLAIN ANALYZESQL Server 用“显示实际执行计划”Oracle 里可以用EXPLAIN PLAN FOR或者直接看数据库的 SQL 监控报告。为什么强调先看执行计划因为慢 SQL 的瓶颈通常不是 SQL 语法写得不够“高级”而是执行计划选择了错误的访问路径。比如该走索引却走了全表扫描或者关联顺序严重不合理或者因为隐式类型转换导致索引失效。我遇到过最典型的一个例子某条订单查询在数据量 300 万行时正常到了 800 万行突然变慢从 200 毫秒直接飙到 8 秒。一看执行计划发现关联字段user_id在订单表里是VARCHAR类型在用户表里是INT类型数据库在关联时做了隐式转换导致索引完全失效。解决方式就是统一字段类型或者显式写转换函数让类型对齐。4.2 慢 SQL 优化检查清单我把日常排查的思路做成了清单写进速查表里每次遇到慢 SQL 就照着过一遍是否查询了不必要的大字段比如SELECT *把TEXT类型的大字段也捞出来了。是否为过滤字段建了索引索引是否生效是否有函数包裹索引列比如WHERE DATE(order_date) 2024-01-01会让索引失效应改写为范围查询。是否因为隐式类型转换导致索引失效分页深度是否过大LIMIT 1000000, 20会让数据库扫描大量数据再丢弃。关联字段是否有索引关联类型是否是NESTED LOOP但驱动表选错了是否存在重复的OR条件能否改写为UNION ALL是否可以用窗口函数避免自连接优化改写时我有个经验法则能用范围查询解决的就不要用函数能用等值条件解决的就不要用范围查询能少一层子查询的就尽量不要层层包裹。SQL 的可读性和性能通常是正相关的SQL 写得绕执行计划往往也好不到哪儿去。4.3 分页深翻页的优化案例慢 SQL 里的经典场景是深分页。业务方要导出一年前的订单报表分页拉到第 10 万页每页 20 条。这种情况用LIMIT 2000000, 20会让数据库扫描 200 万行后丢掉前 200 万行性能极差。常用优化方式是应用“延迟关联”或者“游标分页”。延迟关联的思路是先查主键再回表取数据SELECT t.* FROM orders t JOIN ( SELECT id FROM orders WHERE status completed ORDER BY id LIMIT 2000000, 20 ) x ON t.id x.id ORDER BY t.id;这个写法的关键性能优势在于子查询只查询主键列通过覆盖索引直接定位到需要的行再回表获取完整数据。相比直接大偏移量查询扫描量小很多实际实测在深分页场景能提速数倍。游标分页的思路则是记住上一页最后一条记录的 id下一页就用WHERE id 上一页最大id来取SELECT * FROM orders WHERE id 1000000 ORDER BY id LIMIT 20;这种写法适合实时性要求高的列表场景比如无限滚动页面。它的代价是不能直接跳页业务场景有局限。两种方案在速查表里我都记了方便实际场景对照选择。5. SQL 注入速查懂攻击原理才能写好防护5.1 注入是怎么发生的万能密码背后的逻辑热搜词里出现了“sql注入万能密码绕过”这类内容之所以一直有人搜一方面说明它的危险性值得被反复强调另一方面也说明很多人没真正搞清楚注入的本质。所谓的万能密码比如在密码框里输入 OR 11本质上是在利用 SQL 解析规则把原本的验证逻辑偷偷改掉。假设数据库里原本的查询是这样的SELECT * FROM users WHERE username admin AND password 123456;如果输入的用户名是admin密码是 OR 11程序直接拼接字符串后查询就变成了SELECT * FROM users WHERE username admin AND password OR 11;由于OR 11恒为真整条 WHERE 条件的最终结果也变成恒真于是攻击者不需要知道密码就能通过验证。这不是某个数据库特有的问题MySQL、PostgreSQL、SQL Server、Oracle 只要存在不规范的字符串拼接都会中招。我在速查表里专门把注入原理写进去是因为我发现很多开发人员对注入的理解停留在“网络安全”而没有把它当成一个 SQL 写法问题。实际上注入的根源就是“代码和数据的边界被混淆了”。用户输入的内容被当成 SQL 代码解析了边界消失攻击就发生了。5.2 防注入的三个层级的实践层级一参数化查询。这是最基础也是最重要的一层。不管用 JDBC 的PreparedStatement还是 Python 的psycopg2的%s占位符核心思想都是让 SQL 语句的结构和数据分离数据库先把语句结构编译好再把参数作为纯数据传入。这样即使参数里写了 OR 11它也只是字符串而已不会参与语法解析。在 C# 的 SqlCommand 里对应的写法是使用参数名的方式SqlCommand cmd new SqlCommand(SELECT * FROM users WHERE username u AND password p, conn); cmd.Parameters.AddWithValue(u, username); cmd.Parameters.AddWithValue(p, password);这样写能直接绕开拼接陷阱是防御注入的第一道防线。层级二输入校验和白名单。比如限制用户名必须由字母、数字、下划线组成过滤掉单引号等特殊字符。但输入校验只能作为补充防线因为总有一些边角场景比如搜索框里的模糊查询需要允许各种字符强制过滤可能误伤正常功能。层级三最小权限原则。给数据库账号分配尽量小的权限应用账号只允许执行 SELECT、INSERT、UPDATE、DELETE不给 DDL 权限。这样就算注入真的发生了攻击者也没办法执行DROP TABLE之类的破坏性操作。我见过不少生产事故不是因为注入防护不到位而是因为应用账号权限过大一个注入点直接导致整表被删。6. 特殊场景速查字符串判断、GUID 默认值与多语句执行6.1 DB2 里判断数字字符串的正确姿势热搜词里有一条“db2 sql判断数字字符串函数”这确实是 DB2 里比较麻烦的一个场景。DB2 不像 PostgreSQL 有~ ^[0-9]$正则直接匹配也不像 SQL Server 有ISNUMERIC。DB2 里判断一个字符串是否是数字常用思路是用TRANSLATE函数把数字字符替换掉看剩下是否为空SELECT * FROM t WHERE TRANSLATE(col, , 0123456789) ;这个写法的原理是TRANSLATE(col, , 0123456789)会把col中所有数字字符替换为空如果替换后结果是空字符串说明col原本就只有数字字符。要注意这个写法对空字符串和 NULL 需要额外处理NULL永远不等于要过滤空值得先WHERE col IS NOT NULL。延伸一句普通的 IN 条件也可以配合校验用SELECT * FROM t WHERE col IS NOT NULL AND TRANSLATE(col, , 0123456789) ;这个写法我做得比较晚才总结进速查表因为 DB2 用得少每次遇到都要现查。把这类冷门写法也收进来才是真正的“全场景”。6.2 SQL Server 里设置 GUID 默认值另一个常见场景是“sql server 默认值guid”。在设计表时如果主键字段想用 GUIDUNIQUEIDENTIFIER类型默认值有两种常用方案。第一种是数据库内置函数NEWID()每次插入自动生成一个新的随机 GUIDCREATE TABLE users ( id UNIQUEIDENTIFIER PRIMARY KEY DEFAULT NEWID(), username NVARCHAR(50) );第二种是NEWSEQUENTIALID()它生成的是顺序性更强的 GUID在作为聚集索引主键时可以减少页拆分性能比NEWID()好。但NEWSEQUENTIALID()有个限制不能直接作为常量调用只能用在 DEFAULT 约束中你无法在普通 SELECT 语句里SELECT NEWSEQUENTIALID()。我建议如果业务不需要客户端提前知道主键值就在数据库层用NEWSEQUENTIALID()。如果需要在应用代码里预生成 id比如兼容多数据库的分布式系统那还是用客户端生成 GUID 更合适数据库默认值只能作为兜底。6.3 C# 里执行多句 SQL 的坑热搜词里还有一条“c#怎么执行多句sql语句”。很多人以为用SqlCommand只能执行一条 SQL其实不是。SqlCommand.CommandText里可以同时放多条 SQL 语句用分号分隔然后调用ExecuteNonQuery()一次性执行。string sql INSERT INTO logs (message) VALUES (start); INSERT INTO logs (message) VALUES (end); ; using (SqlCommand cmd new SqlCommand(sql, conn)) { conn.Open(); int affected cmd.ExecuteNonQuery(); }这里有个容易踩的坑如果其中任何一条 SQL 出错默认情况下事务会半途而废前面的操作可能已经提交了后面的没有执行。要保证多条 SQL 的原子性必须显式开启事务using (SqlTransaction tx conn.BeginTransaction()) { // 把 cmd.Transaction 设置为 tx再执行多条 SQL tx.Commit(); }这个细节我之所以专门记进速查表是因为我在一次数据迁移脚本里吃过亏。当时为了图省事在一个CommandText里塞了几十条 SQL中间一条插入因为字段长度超限报错结果前 20 条已经写进库了后 20 条没执行最后靠手动比对数据才把状态恢复回来。从那以后凡是要执行多条 SQL我必开显式事务。7. 常见问题排查实录SQL Server 周边的那些坑7.1 SSL 加密连接报错热搜词里有一条很长的错误信息“驱动程序无法通过使用安全套接字层(ssl)加密与 sql server 建立安全连接”。这通常不是你代码的问题而是 SQL Server 的证书配置问题。常见的诱因包括服务器端没有配置有效的 TLS 证书、客户端强制启用了EncryptTrue或者服务器是自签名证书而客户端没有信任该证书。排查的思路一般分三步。第一步确认链路上有没有代理或网关在做 TLS 卸载。如果有代理客户端连的是代理而不是真正的 SQL Server证书校验就可能失败。第二步用 SSMS 或命令行工具sqlcmd直接连接数据库排除驱动版本的干扰。第三步确认协议版本。旧版本的 SQL Server比如 2008 R2默认支持的 TLS 版本老旧如果客户端新版驱动只支持 TLS 1.2也会出现握手失败。临时解决时可以在连接字符串里显式关闭加密校验或设置TrustServerCertificateTrue但千万注意这只是开发环境调试用的缓兵之计生产环境必须配置正规证书并开启强制加密。7.2 SQL Server 的 Windows NT 进程内存占用过高“sql server windows nt占用内存”也是热搜常客很多人一打开任务管理器看到 SQL Server 进程占用了几十 GB 内存就慌了以为是内存泄漏。其实大多数时候这是 SQL Server 的默认行为。出于性能考虑SQL Server 会尽可能多地借用操作系统内存作为缓冲池而不是像很多应用那样“够用就行”。这个行为是有意设计的但如果你所在的机器内存有限就需要给 SQL Server 设置上限。在 SSMS 里右键实例选择“内存”设置把“最大服务器内存”调到一个合理值比如物理内存的 70%重启实例后生效。或者用 T-SQL 直接设置EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure max server memory (MB), 8192; RECONFIGURE;设置完成后SQL Server 的缓冲池会逐步释放到目标上限以上。需要注意的是max server memory调低后内存不会立刻降下来需要等 SQL Server 内部机制回收别刚执行完就以为没效果。7.3 SQL Server 不同版本的安装与共存问题热搜词里有大量关于 SQL Server 下载、安装、版本对比的词条比如“sql server 2008可以和ssms2022共存吗”“sql server 2012的数据库备份2008能用吗”。这两个问题的答案都很明确。SSMS 和 SQL Server 数据库引擎是可以分开装的SSMS 2022 完全可以连接 SQL Server 2008只要数据库引擎的网络协议和端口是开启的。就像你用新版手机客户端连接旧版服务器只要协议兼容就能通信。备份文件版本则是另一回事。SQL Server 的备份文件是不向后兼容的也就是说高版本备份的.bak文件不能恢复到低版本实例。SQL Server 2012 的备份可以恢复到 2008 吗不可以。反过来2008 的备份可以恢复到 2012因为低版本向高版本兼容。所以如果你手头有一个 2012 的库要迁到 2008唯一靠谱的办法是用脚本导出表结构和数据而不是直接恢复备份文件。这个坑我踩过当时业务方说“反正都是 SQL Server应该没区别”结果恢复时报版本不兼容错误差点搞崩迁移窗口。7.4 SQL Server 2019/2022 安装的常见拦路虎无论你装的是 SQL Server 2019 还是 2022新手最容易卡住的是“安装时提示需要对密钥有访问权限”或者“提示防火墙规则未配置”。前者一般出现在用最小权限账号执行安装时解决方式是使用管理员账号运行安装程序或者给当前用户授予安装目录的写权限。后者通常在安装过程中可以在“SQL Server 配置管理器”里手动为sqlservr.exe添加防火墙入站规则。还有一条值得提前注意SQL Server 2022 默认不在 Windows Server 2016 上支持如果你在旧系统上强行安装可能在功能检查阶段直接卡住。安装前尽量核对官方支持矩阵省得白折腾一晚上。8. 速查表的使用心法别让速查表变成“查了就忘”写到这儿其实这份速查表的核心内容已经讲得差不多了。最后我想聊一下怎么用它才不辜负花时间整理这些对照关系。速查表的本意是减少查文档的时间但如果你每次都现查现用、用完就忘下次照样踩坑。我的经验是每个场景的语法过一遍手就行。比如分页你在 MySQL 里写了LIMIT顺手看一眼 SQL Server 的OFFSET FETCH假装自己正在那个库上写脑子里过一遍语法结构。窗口函数更不用说了四个库差异极小你只要在任何一个库上熟练了其他库基本都能直接写。真正需要长期记忆的不是语法本身而是“这个需求该用哪种写法”。比如去重你要记住的优先级是整行去重用DISTINCT分组取一条用窗口函数万不得已才用GROUP BY拼子查询。这份速查表现在我还在持续更新每次遇到新坑、新写法就补一行。比如之前提到的 DB2 判断数字字符串、SQL Server 的NEWSEQUENTIALID()都是在具体项目里碰了壁才加进去的。我建议你也建一个自己的速查表不用像我一样追求大而全但凡是让你现查过两次以上的语法都值得记下来。时间长了你会发现这玩意儿比收藏夹里的几百篇教程好使多了。