企业官网建设流程全解析

SQL 这门语言有个很有意思的特点：入门门槛低得离谱，SELECT ... FROM ... WHERE三件套半小时就能上手，但真正让人栽跟头的从来不是语法本身，而是写完之后结果对不上、或者结果对了却慢得离谱。我带过几个刚转行的同学，语法书翻得滚瓜烂熟，一上手写报表就出问题——要么LEFT JOIN之后行数莫名翻倍，要么COUNT出来比业务方给的数字少一截，要么一条查询跑了四十秒被叫去喝茶。这些问题没有一个是语法错误，全是“没想清楚数据怎么流动”。

这篇东西不打算当语法手册用，那玩意儿官方文档写得比我全。我想聊的是 SQL 背后的执行逻辑、模块之间的选型取舍、以及那些只有真正在线上跑过几千条查询才会总结出来的经验。从一条语句在数据库里怎么被拆解、优化、执行讲起，再往下拆解单表过滤、多表关联、聚合与窗口函数、子查询与 CTE 这几大块，然后给一套可以直接抄作业的建表、索引、执行计划解读流程，最后把慢查询排查和方言差异这两块单独拎出来讲。

适合谁看：写过一些 SQL 但总觉得自己是在“试出来”而不是“算出来”的人；被慢查询折磨过、想知道索引到底怎么建的人；以及要从一个数据库迁到另一个数据库、担心踩坑的人。完全零基础也能看，我会把关键概念用生活化的方式讲清楚，但节奏会稍微快一点，毕竟这行的耐心都留给线上事故了。

1. 先搞懂 SQL 的执行链路，再谈语法

1.1 一条 SELECT 从敲下回车到返回结果

很多人以为 SQL 是“声明式语言，所以不用管它怎么执行”，这话只对了一半。声明式意味着你不用告诉数据库“先读哪一行再读哪一行”，但性能好坏完全取决于数据库替你做的那些决定，而你想干预这些决定，就必须知道链路长什么样。

一条查询发过去，大致会经过这么几层。连接层先接管，做身份认证、权限校验、连接复用，连接池打满的时候你会看到请求排队而不是报错，这个现象很多人第一次遇到会误以为是慢查询。接着是解析器，把文本切成词法单元、检查语法、生成语法树，这一步报的是You have an error in your SQL syntax，属于最容易解决的一类问题。

真正决定命运的是优化器。它拿到语法树之后做逻辑改写（比如把外连接转内连接、把恒真条件消除、把子查询展开），然后基于统计信息估算每种执行路径的代价，选出一个它认为最便宜的计划。这里的“统计信息”通常是索引的基数、表的行数、列的直方图，一旦统计信息过期，优化器就会做出离谱的判断——这也是为什么线上偶尔会出现“昨天还好好的查询今天突然全表扫描”的怪事。最后是执行器，按计划调用存储引擎的接口，一行一行（或者一批一批）把数据取上来，做连接、排序、聚合，再回给客户端。

用点外卖打个比方：解析器是看懂你订单的客服，优化器是规划骑手路线的调度系统，执行器是真的在路上跑的骑手。你抱怨送得慢，问题往往不在客服看不懂订单，而在调度给了条绕远路的方案，或者骑手被派了太多单。SQL 调优的本质，就是让调度做出正确判断。

1.2 逻辑执行顺序与书写顺序的错位

这是我认为最值得优先建立的一个心智模型。你写 SQL 的顺序是SELECT → FROM → JOIN → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT，但数据库实际处理的逻辑顺序是另一套：先FROM确定数据源，再ON做连接条件匹配，再JOIN产出连接后的虚拟表，然后WHERE过滤行，接着GROUP BY分组、HAVING过滤组，再SELECT投影出列、DISTINCT去重，最后ORDER BY排序、LIMIT截断。

这个错位能解释一大堆“为什么这么写就报错”的疑惑。为什么WHERE里不能用SELECT起的别名？因为WHERE执行的时候SELECT还没跑，别名压根不存在。为什么聚合函数不能直接写在WHERE里？因为WHERE阶段还没分组，没有“组”这个概念可以聚合。为什么HAVING里可以用聚合函数？因为它作用在分组之后。为什么ORDER BY里反倒可以用别名？因为它是最后执行的，此时别名已经算出来了。

我自己刚学的时候在这个上面卡了很久，写了个SELECT amount * 0.9 AS net_amount FROM t_order WHERE net_amount > 100，数据库直接报错说不认识net_amount。当时觉得这语言设计得不合理，后来理解了执行顺序才明白，是我在要求一个还不存在的东西参与判断。

1.3 为什么这个错位会直接影响排错效率

理解了顺序，报错信息基本能秒读。看到Unknown column 'xxx' in 'where clause'，第一反应应该是“别名用错位置了”或者“拼写错了”，而不是去怀疑表结构。看到Invalid use of group function，第一反应是“聚合函数跑到了WHERE里”。看到Column 'xxx' in field list is ambiguous，那是多表连接时同名列没加表前缀。

更实用的是排查“结果不对”这类问题。举个真实场景：某人写了个统计，想看每个用户的订单总数，用了LEFT JOIN从用户表连订单表，然后WHERE o.status = 2。结果那些一单都没下的用户全消失了。原因很简单——WHERE在连接之后执行，它把o.status为NULL的行（也就是没匹配上的用户）全部过滤掉了，LEFT JOIN的语义被WHERE干掉了。正确写法是把条件挪到ON里，或者加OR o.status IS NULL。这类问题不看执行顺序根本想不明白。

提示：凡是LEFT JOIN之后再写WHERE过滤右表字段的，都要停下来想三秒钟：这个条件到底是连接条件还是过滤条件？放在ON和放在WHERE里，结果集可能差出几十万行。

2. 语法模块拆解与方案选型

2.1 单表过滤：WHERE 里的四个高频陷阱

单表查询看着最简单，实际上坑最密。第一个是NULL的三值逻辑。SQL 里的布尔值有真、假、未知三种状态，NULL参与任何比较的结果都是“未知”，而WHERE只保留结果为“真”的行。所以WHERE status != 2会把status IS NULL的行全部漏掉，这不是 bug，是标准行为。想包含空值必须显式写WHERE status != 2 OR status IS NULL。

第二个是NOT IN遇到NULL。WHERE user_id NOT IN (SELECT user_id FROM t_blacklist)这条语句，只要子查询结果里混进一个NULL，整个条件就永远不成立，返回空集。这个坑极其隐蔽，因为数据里偶尔出现几条NULL是很正常的事。稳妥的写法是改成NOT EXISTS，或者给子查询加WHERE user_id IS NOT NULL。

第三个是函数包裹索引列。WHERE DATE(created_at) = '2024-05-01'看着很自然，但DATE()包裹之后索引直接失效，数据库只能全表扫描再逐行算函数值。改写方式是把它变成范围查询：WHERE created_at >= '2024-05-01 00:00:00' AND created_at < '2024-05-02 00:00:00'。一样的意思，性能差出几个数量级。

第四个是隐式类型转换。手机号这类字段如果在表里定义成VARCHAR，查询时写成WHERE phone = 13800000000（没加引号），数据库会把列转成数字再比较，索引照样失效。反过来，如果字段是BIGINT而你传了字符串，某些数据库也会做转换，同样影响索引使用。字段类型和传入参数类型严格对齐，这条规则能省掉一半的线上性能问题。

2.2 JOIN 家族的选择逻辑与代价

INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL OUTER JOIN、CROSS JOIN这几种，语义差别很清晰，但用的时候经常搞混。我见过不少代码用RIGHT JOIN，纯粹是因为写的人把两张表的位置调换了但懒得改关键字，最后可读性极差。

选型的核心判断标准是：你要保留哪一侧的全部数据。主表全部保留用LEFT JOIN，从表全部保留用RIGHT JOIN（但我一般建议调换表顺序改成LEFT JOIN，可读性更好）。两侧都保留、缺失的补空，那得看数据库方言，FULL OUTER JOIN并非所有数据库都支持。

执行层面最关键的概念是驱动表。嵌套循环连接（Nested Loop）是最常见的实现，它拿驱动表的每一行去被驱动表里找匹配。驱动表小、被驱动表的连接字段有索引，这个组合是最优的。如果驱动表百万行、被驱动表没索引，那就是百万次全表扫描，基本等于灾难。

优化器通常会自动选小表当驱动表，但它判断“大小”依赖统计信息。如果统计信息不准，它可能把一个百万行的表当驱动表。这时候你可以用STRAIGHT_JOIN（MySQL 语法）强制指定连接顺序，但这是最后手段，优先还是去更新统计信息。

ON和WHERE在LEFT JOIN里的位置差异，前面已经提过一次，这里再强调一遍它的影响范围。ON里的条件在连接匹配时生效，不影响主表行数保留；WHERE里的条件在连接完成后生效，会把不满足条件的行连同主表行一起删掉。所以过滤右表用ON，过滤最终结果用WHERE，这两个千万别写反。

2.3 聚合、分组与窗口函数的取舍

GROUP BY的本质是“压缩”，它把一组行压成一行，行数变少。窗口函数的本质是“贴标签”，它在每一行旁边加一列计算结果，行数不变。这个区别决定了它们的使用场景。

想看每个城市有多少订单、总金额多少，用GROUP BY。想看每笔订单占该用户总消费的比例，或者每笔订单在该用户的消费序列里排第几，就得用窗口函数，因为你要保留订单粒度的每一行。

窗口函数的语法结构是函数名() OVER (PARTITION BY 分组列 ORDER BY 排序列 帧范围)。PARTITION BY相当于分组但不压缩，ORDER BY决定窗口内的顺序，帧范围决定参与计算的行范围。默认帧是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，所以SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at)算出来的是累计值，而不是该用户的总和——想要总和就写SUM(amount) OVER (PARTITION BY user_id)，不带ORDER BY。

这个默认帧的行为坑过不少人。同样是SUM() OVER，带不带ORDER BY结果完全不同，而且不报错，只是数值对不上。我第一次用的时候对着报表核了半天，最后才发现是少了ORDER BY导致算成了累计。

WHERE和HAVING的分工也要说清楚：行级过滤用WHERE，组级过滤用HAVING。比如“订单金额大于 100 的用户里，总消费超过 1000 的”，前半句是WHERE amount > 100，后半句是HAVING SUM(amount) > 1000。把行级条件写到HAVING里虽然语法上可能过得去，但性能会明显变差，因为分组这个动作本身的开销已经被付出了。

2.4 子查询、CTE 与视图的边界

子查询分两类：非相关子查询和相关子查询。非相关的可以独立执行一次，把结果当成常量列表用，比如WHERE user_id IN (SELECT id FROM t_vip)，优化器通常会把它转成半连接（semi-join），效率不错。相关子查询则依赖外层每一行的值，逻辑上要为每一行执行一次，写法不当就是典型的外层行数 × 内层扫描量。

EXISTS和IN的选择经常被讨论，实际经验是：在数据量大、子查询结果集大的场景下，EXISTS通常更稳，因为它遇到第一个匹配就返回，不需要把整个子查询结果物化。但这不是硬规则，现代优化器对两者的改写能力很强，真正决定性能的还是索引有没有建对。

CTE（WITH ... AS (...)）是我这几年用得越来越多的东西，主要收益是可读性。一条需要四五层嵌套的查询，用 CTE 拆成几个有名字的步骤，读起来像流水账，排查时也能单独执行中间某一步验证。代价是部分数据库对 CTE 的处理是“内联展开”，不一定会物化，如果同一个 CTE 被引用多次，可能会重复计算。有些数据库提供了MATERIALIZED关键字强制物化，具体要查对应版本的文档。

视图更适合做“稳定的逻辑封装”，比如把复杂的权限过滤逻辑固定成一张视图给多个业务方用。但视图不适合做性能优化手段，它本质上就是一段被保存的 SQL，查视图和手写那段 SQL 在性能上没有区别，嵌套视图甚至会因为优化器改写能力受限而变慢。

3. 实操：从建表到复杂报表的完整落地

3.1 表结构与数据准备

光讲概念没意思，直接上手建一套订单表跑一遍。下面这个结构我在很多项目里都用过类似的，字段不多但足够说明问题。

CREATE TABLE t_order ( order_id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0待付 1已付 2已完成 3已取消', amount DECIMAL(12,2) NOT NULL DEFAULT 0.00, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, paid_at DATETIME NULL, PRIMARY KEY (order_id), KEY idx_user_created (user_id, created_at), KEY idx_status_created (status, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

几个设计上的取舍值得说。金额用DECIMAL而不是FLOAT，浮点数在累加时会出现精度漂移，财务数据绝对不能碰这个雷。时间用DATETIME而不是字符串，字符串比较虽然也能排序，但无法做时间函数运算，而且占空间更大。status用TINYINT存编码而不是直接存中文，一是省空间，二是避免拼写不一致，中文状态名放字典表或者代码常量里维护。

索引部分建了两个组合索引，(user_id, created_at)服务于“查某用户最近订单”这类高频查询，(status, created_at)服务于“按状态捞单”的运营后台。为什么不是给每个字段单独建索引？因为单列索引在多条件查询里通常只能用上一个，剩下的条件还是要回表过滤，组合索引能把多个条件一次性用上。

3.2 分步构造一条多层统计查询

需求是这样的：统计最近 30 天内，每个已完成订单的金额、该用户的历史累计消费、该用户在所有用户中的消费排名，以及该用户这是第几单。

这需求单靠GROUP BY做不了，因为要保留订单粒度。一步步来。先取基础数据：

SELECT order_id, user_id, amount, created_at FROM t_order WHERE status = 2 AND created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY);

接着加窗口函数。注意累计消费和总消费是两个不同的东西，前者要ORDER BY，后者不要：

SELECT order_id, user_id, amount, created_at, SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS user_cum_amount, SUM(amount) OVER (PARTITION BY user_id) AS user_total_amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at) AS user_order_seq, RANK() OVER (ORDER BY amount DESC) AS amount_rank FROM t_order WHERE status = 2 AND created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY);

这里SUM(...) OVER (PARTITION BY user_id)不带ORDER BY，窗口帧默认是整个分区，所以算出的是该用户全部已完成订单的总额。而带ORDER BY created_at的那个，默认帧变成从分区起点到当前行，算的是截至当前订单的累计值。ROWS和RANGE的区别在于，当排序列有重复值时，RANGE会把相同值的行一起算进来，ROWS严格按物理行算。订单时间通常精确到秒，重复概率低，但如果你用日期当排序列，这个差别就会很明显。

RANK()遇到并列会跳号（1、1、3），DENSE_RANK()不跳号（1、1、2），ROW_NUMBER()强制唯一（1、2、3）。选哪个取决于业务定义，排名场景一般用RANK或DENSE_RANK，去重取最新一条用ROW_NUMBER。

如果还要按城市维度汇总，就再套一层 CTE：

WITH recent_orders AS ( SELECT order_id, user_id, amount, created_at FROM t_order WHERE status = 2 AND created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY) ) SELECT user_id, COUNT(*) AS order_cnt, SUM(amount) AS total_amount, AVG(amount) AS avg_amount FROM recent_orders GROUP BY user_id HAVING SUM(amount) > 1000 ORDER BY total_amount DESC LIMIT 100;

这种“先 CTE 圈定范围，再聚合，再HAVING过滤”的写法，比起把所有逻辑塞进一层，排查时好太多了。中间那步想验证数据对不对，单独把 CTE 里的SELECT拎出来跑一下就行。

3.3 索引设计：从选择性算起

索引不是越多越好，每个索引都要占空间、都要在写入时维护。判断一个字段该不该建索引，先算选择性：不同值的数量除以总行数，结果越接近 1 越适合建索引。

假设订单表有 100 万行。status只有 4 个取值，选择性是 4 / 1000000 = 0.000004，意味着平均每个值对应 25 万行。这种情况下单列索引基本没用，因为走索引扫出 25 万行再回表，还不如直接全表扫描。但如果业务里 95% 的订单都是“已完成”，而你只查“待付款”的那 5%，那status索引就有价值了，因为数据分布极度倾斜，优化器会判断走索引更划算。

user_id假设有 50 万个不同用户，选择性是 500000 / 1000000 = 0.5，相当高，适合建索引。order_id是主键，选择性为 1，天然唯一。

组合索引的字段顺序是个大学问。规则是最左前缀：(a, b, c)这个索引能支持a、(a,b)、(a,b,c)三种查询条件组合，但支持不了单独的b或(b,c)。所以高频单条件字段放最左边，范围查询字段尽量放右边。WHERE user_id = ? AND created_at > ?这种组合，(user_id, created_at)的顺序是对的，反过来(created_at, user_id)就只能用到created_at的范围扫描，user_id的过滤还得回表做。

还有一个常被忽略的点：索引列上不要做运算。WHERE amount * 2 > 1000这种写法，amount上的索引会失效，改成WHERE amount > 500就行。同理，WHERE user_id + 0 = 123也是自毁索引的写法。

3.4 执行计划怎么读

EXPLAIN是排查性能问题的第一站，但很多人看完一脸懵。实际上只需要盯住几个字段。

type的等级从好到差大致是system > const > eq_ref > ref > range > index > ALL。看到ALL就意味着全表扫描，如果表只有几百行那无所谓，百万行就得处理了。

Using filesort不是真的用文件排序，而是指无法利用索引顺序、需要在内存或磁盘里额外排序。小结果集排序很快，但如果rows是几十万，这个排序会吃掉大量内存。解决办法是让ORDER BY的字段顺序和索引顺序一致。

Using temporary通常出现在GROUP BY或DISTINCT场景，表示需要建临时表。临时表在内存里还好，一旦超过阈值落到磁盘，性能断崖式下跌。

顺带说一个估算方法。InnoDB 的索引是 B+ 树结构，假设每个数据页 16KB，主键 8 字节、指针 6 字节，一条索引记录约 14 字节，一页能存大约 1170 条。三层 B+ 树可以容纳 1170 × 1170 × 1170 ≈ 16 亿条记录。也就是说，只要表在十几亿行以内，通过主键查询只需要三次磁盘 IO（根节点和两层非叶子节点通常常驻内存，实际可能只有一次）。这就是为什么主键查询这么快，也是为什么主键要尽量短——主键变长，一页存的条目变少，树高增加，IO 次数就上去了。

3.5 分页与批量写入的实战

深分页是经典问题。LIMIT 1000000, 20这种写法，数据库要先扫描 100 万零 20 行，再丢掉前 100 万行，越翻到后面越慢。优化思路是“延迟关联”：先用覆盖索引把主键捞出来，再回表取详细字段。

SELECT o.order_id, o.user_id, o.amount, o.created_at FROM t_order o INNER JOIN ( SELECT order_id FROM t_order WHERE status = 2 ORDER BY created_at DESC LIMIT 1000000, 20 ) t ON t.order_id = o.order_id;

内层子查询只取order_id，如果(status, created_at, order_id)有覆盖索引，整个过程不需要回表，扫描速度快很多。外层再按 20 个主键回表，代价可以忽略。

更彻底的做法是用游标分页，记住上一页最后一条的created_at和order_id，下一页直接从这之后取：

SELECT order_id, user_id, amount FROM t_order WHERE status = 2 AND (created_at, order_id) < ('2024-05-01 12:00:00', 88001) ORDER BY created_at DESC, order_id DESC LIMIT 20;

这种方式每页耗时基本恒定，缺点是只能顺序翻页，不能跳到第 N 页。后台列表类需求通常够用，前端要是非要有页码跳转，可以限制最大页数。

批量写入这块，核心是减少事务提交次数。逐条INSERT一千次，就是一千次事务提交、一千次日志刷盘。改成一条INSERT带一千组值，或者用批量接口分批提交（每批 500 到 1000 条），速度能差出十倍以上。

INSERT INTO t_order (user_id, status, amount, created_at) VALUES (1001, 0, 99.00, NOW()), (1002, 0, 158.50, NOW()), (1003, 0, 20.00, NOW());

批大小也不是越大越好，太大容易触发包大小限制或者长时间持锁，500 到 1000 是个比较稳的区间，具体看单行大小和网络状况。

4. 慢查询与逻辑错误的排查实录

4.1 慢查询的定位流程

线上告警说某接口变慢，第一步不是改 SQL，是确认慢在哪。我习惯按这个顺序走：先看监控里这条 SQL 的执行次数和平均耗时有没有突变，突变往往意味着数据量增长或者统计信息过期；再看执行计划有没有变化，同一句 SQL 昨天走索引今天走全表，八成是统计信息不准或者索引被删了；然后看锁等待，SHOW PROCESSLIST或者查性能视图，找有没有长时间处于Waiting for table metadata lock之类的状态。

如果确认是 SQL 本身的问题，接下来看三件事：扫描行数是不是远超返回行数、有没有Using filesort或Using temporary、有没有回表。扫描行数远大于返回行数，说明过滤条件没走索引或者选择性太差。有 filesort 且结果集大，考虑调整索引顺序或者业务上限制排序范围。回表次数多，考虑加覆盖索引。

有一个容易被忽略的点是参数嗅探。某些数据库会缓存第一次执行时的参数生成的计划，如果第一次传的参数恰好选择性极差（比如传了个查不到数据的值），后续所有查询都可能复用这个烂计划。遇到“同样的 SQL 不同参数耗时差几十倍”的现象，可以往这个方向查。

4.2 逻辑踩坑速查表

语法错误好修，逻辑错误才要命，因为它不报错。我把这些年踩过的整理成一张表，遇到结果不对先对着扫一遍。

其中“LEFT JOIN 后行数变多”是最常见的。很多人看到结果多了几万行，第一反应是 SQL 写错了，其实是右表存在一对多关系，连接之后自然放大。判断方法很简单：单独SELECT 连接字段, COUNT(*) FROM 右表 GROUP BY 连接字段 HAVING COUNT(*) > 1，能查出重复就说明是这个问题。

“排序结果不稳定”也很隐蔽。ORDER BY created_at DESC如果有大量相同时间戳的记录，每次查询返回的顺序可能不一样，前端翻页就会看到同一条数据出现两次、另一条消失。加上, order_id DESC作为次级排序键就能解决。

4.3 事务与并发下的数据一致性

SQL 不只是查询，写入场景要考虑并发。最典型的坑是“先查后改”的竞态：两个请求同时读到库存 10，各自扣减 1 写回 9，实际应该变成 8。解决办法要么用原子更新UPDATE t_stock SET qty = qty - 1 WHERE sku_id = ? AND qty >= 1，靠数据库的行锁和条件判断保证正确；要么用乐观锁，加版本号字段，更新时带上版本条件，影响行数为 0 就重试。

隔离级别也值得说清楚。多数数据库默认是“可重复读”，同一事务内多次读同一行结果一致，靠的是多版本并发控制。但这不意味着没有并发问题，比如幻读在某些实现下仍可能出现，需要间隙锁或者串行化级别来兜底。实际项目里，我更倾向于把关键逻辑收敛到单条原子语句，而不是依赖隔离级别去解决业务问题——把正确性建立在“默认配置”上，一旦运维调了参数就全崩了。

长事务是另一个隐患。一个事务开着不提交，它持有的锁会阻塞别人，回滚段也会不断膨胀。我见过有代码把查询结果集遍历和事务包裹在一起，中间还调了外部接口，一个事务开了几十秒，直接把整张表的写入卡住。原则很简单：事务里只放数据库操作，任何网络调用、文件读写都挪到事务外面。

5. 方言差异与迁移时的注意事项

5.1 常见方言差异对照

SQL 有标准，但各家实现都有自己的脾气。同一个需求换个数据库，写法可能要改。下面这张对照表覆盖了我遇到过的大多数差异点。

COALESCE是 SQL 标准函数，各数据库都支持，而IFNULL和ISNULL是各自的方言。写可移植代码时优先用标准函数，能省掉大量迁移工作量。

自增主键的差异在迁移时特别麻烦。老系统的AUTO_INCREMENT迁到新库要改语法，而且已有数据的序列起点要手动同步，否则新插入的数据主键会和历史数据撞车。迁移前一定要把当前最大主键记下来，在新库把序列起始值设到它之后。

标识符大小写这个问题更隐蔽。在一种环境下表名大小写不敏感，迁到另一种环境突然变成敏感，代码里的FROM T_Order就找不到t_order了。稳妥做法是全项目统一用小写下划线命名，不给自己留隐患。

5.2 迁移前的自检清单

跨库迁移不是改改连接串就完事，我一般会走一遍这几项检查。把所有用到方言函数的 SQL 搜出来，逐个替换成标准写法或者对应实现；把分页语句全部过一遍，LIMIT offset, size和OFFSET ... FETCH的语义虽然一样，但语法差异必须改；检查所有隐式类型转换的地方，新库的类型检查可能更严格，原来能跑的查询会直接报错；检查日期时间类型的精度，有的库DATETIME默认精确到秒，有的默认到微秒，字段定义不一致会导致数据截断。

还有一项容易被忘：排序规则。不同库的默认排序规则对中文、大小写、重音符号的处理不一样，同一个ORDER BY name在两边可能给出不同顺序。如果业务对顺序敏感，得显式指定排序规则。另外，聚合函数在空集上的返回值也要验证，SUM在无匹配行时返回NULL而不是 0，这个行为各库一致，但很多应用代码没做兜底，迁移后报表上突然出现一堆空白单元格。

我在实际迁移项目里的体会是，最耗时间的从来不是语法替换，而是那些“原来靠巧合能跑通”的代码。比如依赖了默认排序、依赖了隐式转换、依赖了某个库特有的函数行为。迁移之前把这些隐性依赖找出来，比迁完之后一个个救火要省事得多。

最后分享一个小习惯：每次写复杂查询，我都会先用小范围数据（比如加个LIMIT 100或者限定某一天）跑一遍，肉眼核对结果，确认逻辑对了再去掉限制跑全量。这个动作花不了一分钟，但能挡掉大部分“跑了半小时发现口径错了”的惨剧。SQL 这行当，快不等于急，先验证再放开，是我这些年最值钱的一条经验。