BigQuery SQL 和 MySQL SQL 有哪些区别，迁移查询时需要注意什么

很多开发人员第一次把 MySQL 查询搬到 BigQuery 时，会产生一种错觉：两边都是 SQL，SELECT、WHERE、JOIN、GROUP BY 看起来几乎一样，把原来的 SQL 稍微修改一下应该就能运行。

这种理解在简单查询上通常没问题，一旦进入复杂报表、时间计算、JSON、窗口函数、分页、事务、存储过程以及大规模数据处理，差异很快就会暴露出来。

原因并不只是“语法不一样”。MySQL 主要服务于关系型数据库和在线事务处理，典型应用包括网站、SaaS、CMS、电商和业务系统；BigQuery 则是面向分析型工作负载的数据仓库，采用 GoogleSQL，并针对大规模数据扫描、聚合和分析进行了不同的执行与存储设计。Google 官方也明确将 GoogleSQL 定位为 BigQuery 推荐使用的 SQL 方言。

因此，MySQL 到 BigQuery 的迁移不能理解为简单的“SQL 翻译”，更准确的说法应该是 SQL 语法、数据类型、查询语义、数据模型和执行方式一起迁移。

先搞清楚 BigQuery 使用的到底是什么 SQL

现在讨论 BigQuery SQL，首先应该区分历史上的 Legacy SQL 和今天使用的 GoogleSQL。

GoogleSQL 是 BigQuery 当前推荐的 SQL 方言，它兼容大量 ANSI SQL 标准，同时加入了 BigQuery 自己的能力，例如 ARRAY、STRUCT、复杂子查询、窗口函数、DML、分析函数以及针对嵌套和重复数据的处理方式。Google 已经在持续推动用户从 Legacy SQL 迁移到 GoogleSQL。

所以，如果你现在准备把 MySQL 查询迁移到 BigQuery，目标应该是 MySQL SQL 到 GoogleSQL，而不是过去一些旧教程里所谓的“MySQL 到 BigQuery SQL”。

最直观的区别之一就是标识符和表名写法。

MySQL 经常使用反引号处理表名和字段名，例如：

SELECT `name`
FROM `users`;

BigQuery 同样使用反引号，但完整表名通常采用：

SELECT name
FROM `project_id.dataset_id.users`;

这里的项目、数据集和表三级命名，是 BigQuery 数据仓库环境非常常见的结构。

数据类型不能机械对应

MySQL 和 BigQuery 的数据类型并不是一一对应。

MySQL 常见的 INT、BIGINT、DECIMAL、VARCHAR、TEXT、DATETIME、TIMESTAMP、JSON 等类型，在进入 BigQuery 后需要重新考虑。

例如 BigQuery 常见整数类型是 INT64，浮点数是 FLOAT64，字符串统一使用 STRING，高精度数值则可以使用 NUMERIC 或 BIGNUMERIC。

更麻烦的是，一些 MySQL 类型在 BigQuery 中并不存在完全相同的语义。

MySQL 的 ENUM 和 SET 不应该简单理解成 BigQuery 中存在同名类型。实际迁移时通常需要根据业务语义转换成 STRING、数组或者其他结构。

DATETIME 和 TIMESTAMP 也必须特别小心。它们都涉及日期和时间，但语义不同。TIMESTAMP 表示一个绝对时间点，而 DATETIME 不携带时区信息。原来 MySQL 系统依赖服务器时区工作的查询，迁移到 BigQuery 后很容易出现日期跨天、报表日期偏移等问题。

Google 官方的 MySQL 到 BigQuery 数据迁移文档也提供了具体的数据类型映射，而且 Google 正在更新 MySQL Connector 的类型映射规则。例如后续映射中，MySQL DATETIME 对应 BigQuery DATETIME，MySQL JSON 对应 BigQuery JSON，MySQL GEOMETRY 则对应 GEOGRAPHY。因此，实际项目不能只按照几年前博客中的类型转换表操作。

函数差异比 SELECT 语法更容易制造问题

很多迁移失败并不是 SELECT 本身的问题，而是函数。

例如 MySQL 中大量使用：

IFNULL(price, 0)

BigQuery 同样支持：

IFNULL(price, 0)

也支持标准 SQL 中常见的：

COALESCE(price, 0)

所以没有必要把 IFNULL() 错误地理解成必须转换成 TRY_CAST()。

TRY_CAST() 的作用是尝试进行类型转换，在转换失败时返回 NULL，解决的是类型转换异常，而不是空值替换。

例如：

SAFE_CAST(price AS NUMERIC)

与：

COALESCE(price, 0)

解决的是两个完全不同的问题。

这类差异在自动转换 SQL 时尤其危险。语法翻译工具可以帮助改写函数，却不能替工程师判断原查询到底想表达什么业务逻辑。

日期和时间是 MySQL 迁移中最容易踩坑的地方之一

MySQL 项目里经常可以看到：

DATE_ADD(created_at, INTERVAL 7 DAY)

BigQuery 也支持 DATE_ADD()，但函数参数、数据类型和时间运算方式需要根据 DATE、DATETIME、TIMESTAMP 分别处理。

例如：

DATE_ADD(order_date, INTERVAL 7 DAY)

如果操作的是 TIMESTAMP，则应该根据具体需求使用相应的时间函数，而不是简单把 MySQL 原句复制过去。

时区尤其需要单独检查。

一个系统如果在 MySQL 中按照本地时区保存或者解释时间，而 BigQuery 查询使用 UTC 语义，那么下面这种查询：

WHERE created_at >= '2026-08-31 00:00:00'

两边得到的结果未必相同。

因此迁移时应该首先定义“业务日期”的标准，到底按照 UTC、服务器时区、用户时区还是某个固定业务时区计算，而不是看到 CURRENT_TIMESTAMP() 就直接复制。

LIMIT 可以迁移，但不要把分页方式当成性能策略

MySQL 常见：

SELECT *
FROM orders
ORDER BY id
LIMIT 1000, 100;

BigQuery 可以写成：

SELECT *
FROM `project.dataset.orders`
ORDER BY id
LIMIT 100
OFFSET 1000;

但这并不意味着 MySQL 的分页策略可以原封不动搬过去。

当数据量达到数亿甚至数十亿行时，传统的深度 OFFSET 分页本身就可能成为性能问题。对于大规模分析系统，更应该考虑基于稳定排序键的分页方式，或者直接采用批处理、分区过滤以及结果表等方案。

BigQuery 的优势并不是让传统 Web 应用中的“第 500000 页，每页 100 条记录”变得更快。

如果业务实际上是后台管理系统、订单系统或者 CMS 列表，那么 MySQL 往往仍然更适合这种 OLTP 查询。

JOIN 可以用，但不能按照 MySQL 的索引思维理解性能

MySQL 开发人员非常习惯考虑：

PRIMARY KEY
INDEX
COMPOSITE INDEX
COVERING INDEX

然后通过索引减少扫描。

BigQuery 的性能模型不同。

BigQuery 是面向分析的数据仓库，查询大量数据时重点应该考虑扫描的数据量、分区裁剪、聚类、JOIN 规模、数据倾斜、Shuffle 和执行阶段，而不是把 MySQL 的 B-Tree 索引思维完整复制过来。

例如一张几 TB 的订单表，如果按照日期进行分析，那么设计合理的分区表，并在查询中提供有效的分区过滤条件，往往比单纯把 MySQL 查询原样搬过去更重要。

BigQuery 的 clustering 也不要翻译成传统意义上的“分桶表”。更准确的理解是聚类表，通过指定聚类字段，让相关数据在存储层形成更有利于过滤和扫描的组织方式。

COUNT、GROUP BY 和窗口函数需要重点做结果校验

很多基础聚合语句在两边都可以直接使用：

SELECT
customer_id,
COUNT(*) AS order_count,
SUM(amount) AS total_amount
FROM orders
GROUP BY customer_id;

真正需要警惕的是复杂聚合和窗口函数组合。

例如：

ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY created_at DESC
)

BigQuery 支持这种标准窗口函数写法。

而原稿中说 BigQuery 不支持 RANK() 和 DENSE_RANK() 是错误的。BigQuery 支持包括 RANK()、DENSE_RANK()、ROW_NUMBER() 在内的窗口函数。

因此迁移时不能为了“兼容 BigQuery”把所有排名函数都改成 ROW_NUMBER()。因为三者语义并不相同。

例如两个员工工资都是第一名：

RANK() 可能得到 1、1、3；

DENSE_RANK() 得到 1、1、2；

ROW_NUMBER() 则得到 1、2、3。

把一个函数机械替换成另一个函数，SQL 虽然能运行，业务结果却已经变了。

子查询和 CTE 不应该被误解为 BigQuery 的限制

原稿中称 BigQuery 不支持子查询中直接使用 LIMIT，这种表述过于绝对，也容易误导。

GoogleSQL 支持 CTE、子查询以及复杂 JOIN 条件。

实际迁移时需要检查的是查询结构和语义，而不是简单记住一份“BigQuery 禁止什么”的列表。

例如 MySQL 中经常看到：

SELECT *
FROM (
SELECT *
FROM orders
ORDER BY created_at DESC
LIMIT 100
) t;

这种查询是否适合 BigQuery，应该根据实际执行需求重新设计，而不是因为看到 LIMIT 就认为必须换成 ARRAY_AGG()。

ARRAY_AGG() 是聚合函数，不是一个万能的子查询 LIMIT 替代品。

BigQuery 并非“不支持事务”

这是原稿里需要纠正的另一个重要错误。

BigQuery 现在支持多语句事务，可以在单个查询或者 Session 中执行多语句事务，对多个表执行修改，并提供提交和回滚能力。官方文档明确说明 BigQuery 的多语句事务提供 ACID 属性和 Snapshot Isolation。

因此，不能再简单地写成“BigQuery 不支持事务，所有一致性必须交给应用层”。

但是，BigQuery 的事务能力和 MySQL InnoDB 的事务使用场景仍然不同。

MySQL 的核心优势之一就是高频、小事务、低延迟的 OLTP。例如用户注册、库存扣减、订单写入、支付状态变化，这类业务天然适合关系型数据库。

BigQuery 的主要任务则是分析和数据处理。

因此迁移的时候真正需要问的问题不是“BigQuery 有没有事务”，而是“这个业务为什么要运行在 BigQuery 上”。

如果一个应用每天产生数百万订单，然后后台分析这些订单，合理架构通常不是把原来的 MySQL OLTP 数据库直接改造成 BigQuery，而是让事务系统和分析系统承担不同职责。

存储过程也不能简单说成 BigQuery 不支持

BigQuery 支持 GoogleSQL 存储过程，可以使用变量、条件判断、循环以及多语句 SQL。

但是，MySQL 存储过程和 BigQuery 存储过程的生态环境、执行模型和使用场景不同。

因此，如果原 MySQL 系统存在大量：

CREATE PROCEDURE
CREATE TRIGGER
EVENT

不能只做关键字替换。

尤其是 MySQL Trigger 经常承担“数据写入后立即执行某项业务逻辑”的职责，这类逻辑迁移到分析平台时，通常需要重新设计数据流水线，而不是寻找一个名字相似的 BigQuery 功能。

BigQuery 支持 DML，但不要把它当 MySQL 来大量 UPDATE

BigQuery 支持：

INSERT
UPDATE
DELETE
MERGE

官方文档明确将这些列为 GoogleSQL 的 DML 能力。

但“支持”不代表“适合”。

MySQL 可以非常自然地执行：

UPDATE users
SET last_login = NOW()
WHERE id = 10001;

一个网站一天执行几百万次类似的小更新，在 MySQL 中是正常业务。

如果把这种工作负载直接搬到 BigQuery，数据模型和成本模型都可能出现问题。

BigQuery 更适合批量数据处理、分析、聚合以及数据仓库工作负载。对于高频单行事务，继续使用 MySQL、Cloud SQL 等 OLTP 数据库通常更加合理。

JSON 迁移不能只看函数名称

MySQL 和 BigQuery 都支持 JSON，但两边的 JSON 数据模型和函数体系并不完全一致。

例如 MySQL 中可能大量使用：

JSON_EXTRACT()
JSON_EXTRACT_SCALAR()
JSON_OBJECT()
JSON_ARRAY()

迁移到 BigQuery 后，需要根据字段到底是 JSON 类型、STRING 中保存的 JSON 文本，还是结构化字段重新设计查询。

如果一张 MySQL 表中有一个巨大的 JSON 字段，里面同时保存订单、用户、商品、地址和日志信息，那么简单复制这个字段到 BigQuery 并不一定是最佳方案。

BigQuery 的 STRUCT、ARRAY 等类型可以直接表达嵌套数据，这也是它与传统 MySQL 表结构非常不同的地方。GoogleSQL 本身就针对嵌套和重复数据提供了专门能力。

MySQL 的索引设计不能直接转换成 BigQuery 的表设计

这是实际迁移项目中最容易被低估的问题。

假设 MySQL 有：

orders
users
products
order_items
payments

每张表都有多个索引。

把这些表完整复制到 BigQuery，然后期待原来的索引继续发挥作用，通常不是一个好的数据仓库设计。

BigQuery 更需要考虑：

数据应该按照什么字段分区；

哪些字段适合 clustering；

哪些表适合事实表和维度表；

哪些查询是每天运行几万次的报表；

哪些历史数据几乎不会修改；

哪些数据应该做汇总表或物化结果；

哪些查询需要扫描 TB 级数据。

这也是为什么 Google 的迁移文档强调数据仓库迁移应该采用分阶段、迭代式方式，而不是一次性把整个旧系统机械复制过去。

BigQuery 的成本和 MySQL 的成本模型完全不同

这是迁移前必须重新学习的一部分。

MySQL 常见成本主要是服务器、实例、磁盘、备份、网络以及运维资源。查询本身通常不会因为扫描了 500 GB 数据就按照扫描数据量直接产生一笔新的查询费用。

BigQuery 则不同。

BigQuery 有按需分析和容量型计费等不同模式。按需模式下，查询成本与处理的数据量直接相关；容量型模式则使用 BigQuery 的计算容量模型。因此不能简单说“BigQuery 每个 Slot 都按照多少美元收费”，也不能把 Slot 和 MySQL CPU 核心直接等价。Slot 是 BigQuery 的计算资源单位，而具体计费取决于所采用的 BigQuery 计费模式。

所以迁移后必须重新审查 SQL。

例如：

SELECT *
FROM huge_table
LIMIT 100;

在 MySQL 中可能非常普通。

在 BigQuery 中，如果底层数据没有因为分区、聚类等机制减少需要处理的数据，单纯增加 LIMIT 100 并不意味着扫描成本就会按照 100 行计算。

这也是为什么 BigQuery 查询设计强调选择需要的字段、使用有效过滤条件、合理设计分区和聚类，而不是简单地把 MySQL 查询复制过去。

SQL 翻译工具可以帮忙，但不能替工程师做业务迁移

Google 已经提供 BigQuery Migration Service，其中包含 SQL Translation，可以把其他数据库和数据仓库中的 SQL 转换成 GoogleSQL。Google 还提供 Interactive SQL Translator、Batch SQL Translator 和 Translation API。

这些工具非常有价值，尤其是大型项目存在几千甚至几万条 SQL 时。

但自动转换解决的是“代码转换问题”，不是“业务语义验证问题”。

例如一个 MySQL 查询：

SELECT *
FROM orders
WHERE created_at >= CURDATE() - INTERVAL 7 DAY;

即使转换工具能够生成可以运行的 GoogleSQL，也仍然应该检查：

时间窗口是不是完全一致；

时区是不是一致；

NULL 行为是否一致；

重复记录处理是否一致；

JOIN 后的数据量是否一致；

金额和 decimal 精度是否一致；

最终报表数字是否一致。

SQL 能运行只是迁移成功的第一关。

MySQL 数据迁移与 SQL 迁移是两件事情

不要把“数据搬过去”和“查询搬过去”混为一谈。

Google 提供 BigQuery Data Transfer Service 的 MySQL connector，可以从本地 MySQL、Cloud SQL 以及其他云环境中的 MySQL 向 BigQuery 传输数据，并支持定期传输。

但数据迁移之后，还要验证 Schema、NULL、字符集、时间类型、主键、重复数据以及增量同步逻辑。

例如增量同步依赖 watermark 字段时，字段是否单调递增、是否在更新时可靠变化，会直接影响增量数据是否完整。

如果使用 upsert，还必须确认用于匹配的主键或唯一键确实唯一，否则数据同步可能产生严重的数据完整性问题。Google 官方 MySQL Transfer 文档也特别强调了这些限制。

不要拿 EXPLAIN 的结果直接比较两个数据库

MySQL 的：

EXPLAIN
EXPLAIN ANALYZE

和 BigQuery 的查询执行计划虽然都可以帮助分析性能，但两边的执行架构并不相同。

BigQuery 查询分析需要关注执行阶段、数据读取、Shuffle、Stage 耗时、数据倾斜以及计算资源使用情况。

因此迁移测试应该比较最终结果和实际资源消耗，而不是看到两个 EXPLAIN 输出长得不一样就认为其中一个查询有问题。

更合理的验证方式是准备一组具有代表性的真实业务查询，然后同时验证：

结果行数；

聚合结果；

NULL 行为；

日期边界；

金额精度；

重复记录；

JOIN 后的数据量；

执行时间；

扫描数据量；

实际成本。

对于大型迁移，还应该把这些查询纳入自动化回归测试。

一个成熟的迁移项目应该这样做

第一步不是打开 BigQuery，然后把 MySQL SQL 一条条复制进去。

应该先盘点 MySQL 中到底有哪些工作负载，把查询分成事务查询、报表查询、ETL 查询、后台管理查询、批处理和实时业务逻辑。

第二步确定哪些数据应该进入 BigQuery。不是所有 MySQL 表都值得原样搬过去。

第三步处理 Schema，重新评估数据类型、时间字段、JSON、枚举字段以及主键等约束。

第四步使用 BigQuery Migration Service 的 SQL Translation 等工具处理大量 SQL，再对复杂查询人工检查。

第五步重新设计分区和 clustering，而不是把 MySQL 索引照搬。

第六步建立结果一致性测试。尤其是财务、订单、用户统计和历史报表，不能因为 SQL 成功执行就认为迁移成功。

第七步检查成本。把高频查询、全表扫描、SELECT *、深度分页以及重复计算找出来。

第八步逐步切换工作负载，而不是一次性关闭 MySQL。

对于仍然需要高频写入、行级事务、锁竞争控制和低延迟响应的业务，MySQL 依然可以作为 OLTP 系统存在；BigQuery 则负责分析和数据仓库工作负载。两者并不是谁取代谁，而是承担不同层次的任务。

MySQL 到 BigQuery 最容易犯的错误，就是把迁移理解成“换一个数据库，把 SQL 改到能运行”。

真正困难的部分往往发生在 SQL 已经成功运行之后。因为数据库迁移最危险的情况并不是语法报错，而是查询没有报错，结果却悄悄变了；或者结果看起来正确，成本却从原来的可控水平变成了无法接受的规模。

因此，一次成熟的 MySQL 到 BigQuery 迁移，应该同时验证 SQL 语法、数据类型、时间语义、NULL 处理、JOIN 结果、聚合逻辑、数据模型、执行计划和成本模型。只有这些环节全部经过验证，才能说完成了从 MySQL 到 BigQuery 的迁移，而不是仅仅把一批 SQL 改成了另一种方言。