Google Sheets QUERY 函数中的 Col1、Col2、ColN，指的不是工作表的 A、B、C 列——而是你传入的数据区域中从左到右的第 1、第 2、第 N 列。如果你的区域是 C1:F100，那么 Col1 对应 C 列，Col2 对应 D 列，Col3 对应 E 列，Col4 对应 F 列。概念本身就这么简单。但截至 2026 年 4 月，这一个误解所引发的 #VALUE! 报错和解析错误，比 QUERY 公式中其他所有语法错误加起来还要多。
QUERY 函数底层使用的是 Google Visualization API 查询语言，支持 11 个独立子句（select、where、group by、pivot、order by、limit、offset、label、format、options、skipping）。ColN 表示法是该查询语言在无法使用列标题名称时识别列的方式——理解为什么这样设计，比死记语法更有价值。
QUERY Col1 Col2 语法与实际列的对应关系
ColN 中的序号，是从数据区域最左列开始从左到右计数的位置编号。以下是不同区域的对应示例：
| 区域 | Col1 | Col2 | Col3 | Col4 | Col5 |
|---|---|---|---|---|---|
A:D | A | B | C | D | — |
B:E | B | C | D | E | — |
C:F | C | D | E | F | — |
Revenue!D:H | D | E | F | G | H |
因此，=QUERY(C1:F100, "SELECT Col1, Col3 WHERE Col2 > 1000") 实际上是选取 C 列和 E 列，并以 D 列作为筛选条件。如果你写成 SELECT C, E WHERE D > 1000，QUERY 会直接抛出解析错误——它在这个上下文中不接受列字母。
这种混乱还有另一个根源：Google Sheets 官方帮助文档在不同位置分别使用了列字母示例和 ColN 示例，却没有始终说清楚哪种语法适用于哪种场景。
为什么插入列会让 QUERY 静默返回错误数据
这是 QUERY 语法中危害最大、也最容易被忽视的陷阱：公式不会报错——只是默默地返回错误数据。
ColN 的编号是在查询执行时相对于传入区域动态计算的，不存在静态绑定。假设你有一张运营看板，公式如下：
=QUERY(B:E, "SELECT Col1, Col2, Col4 WHERE Col3 = '已成交'")
这时 Col1 = B 列（客户名称），Col2 = C 列（所属 BU），Col3 = D 列（订单状态），Col4 = E 列（合同金额）。某位同事在 C 列和 D 列之间插入了一列，用来备注客户评级。
现在 B:E 区域纳入了新的 C 列。原来的筛选条件 WHERE Col3 = '已成交' 不再对应订单状态列，而是对应新插入的评级备注列——评级备注大概率都是空的，所以查询结果变成一片空白，或者返回一批不相关的数据。整个过程没有任何报错，绿色的单元格继续显示着数字，只是这些数字已经错了。
这类问题在团队协作的工作簿中格外常见——尤其是季度末赶数据的时候，有人在共享表格里加了一列备注，完全不知道会影响别人的 QUERY 公式。要降低这类风险，有几个实用做法：
- 使用命名区域：给数据区域起一个名字（如
sales_data），即使插入列也不会改变区域本身的结构定义 - 锁定具体范围：用
B2:E5000而非B:E，至少能防止区域边界被意外扩展 - 在公式旁加注释：在相邻单元格里写明
Col1=客户名 Col2=BU Col3=状态 Col4=金额，让团队成员修改前先看到映射关系
根据 Google Visualization API 查询语言的官方文档，ColN 的序号始终在查询执行时动态计算——这是设计本身的特性，不是 bug，但使用者必须主动管理这个风险。
在 QUERY 的 Col 语法中使用动态条件
硬编码的 WHERE 子句迟早会过时。季度结束了，筛选条件变了，或者有人忘了更新公式。真正经得起时间考验的做法，是将筛选条件与单元格绑定：
=QUERY(B2:F5000,
"SELECT Col1, Col3, Col5
WHERE Col4 = date '"&TEXT(A2,"yyyy-mm-dd")&"'",
1)
TEXT(A2,"yyyy-mm-dd") 将日期强制转换为 QUERY 解析器所要求的精确格式。使用其他任何格式——包括 Google Sheets 单元格自己显示的日期格式——都会导致类型不匹配。这在 Visualization API 规范中有明确规定：日期字面量必须遵循 ISO 8601 格式（yyyy-MM-dd），详见 Google Query Language Reference。
这个写法在按日期切片的滚动预测复盘中特别有用：把截止日期写在 A2 单元格，直接改单元格值即可切换时间窗口，不需要去动公式本身，也不需要再另建辅助列来过渡。
文本筛选遵循同样的原则：
=QUERY(B2:F5000,
"SELECT Col1, Col3, Col5
WHERE Col2 = '"&A1&"'",
1)
去掉内层引号，QUERY 会尝试将单元格的值解析为列名。加上引号，才会将其视为字符串字面量。末尾的 1 告诉 QUERY 第一行是标题行——省略这个参数，QUERY 会把标题行当作数据处理。
实际场景：用 QUERY 在多 BU 看板中替代手动粘贴
QUERY 在财务场景中最能发挥价值的地方，是运营看板的自动化汇总——也就是那种每周/每月需要按 BU 或产品线拆分数据、给业务团队看的视图。
假设你有一张原始数据表，结构如下：
| B 列 | C 列 | D 列 | E 列 | F 列 |
|---|---|---|---|---|
| 月份 | 业务单元 | 收入（万元） | 成本（万元） | 毛利率 |
你需要给每个 BU 的负责人生成一个只包含本 BU 数据的汇总视图，并且按月份升序排列。传统做法是手动筛选、复制、粘贴到各自的标签页——每次更新数据都要重做一遍。用 QUERY 可以改成这样：
=QUERY(原始数据!B2:F,
"SELECT Col1, Col3, Col4, Col5
WHERE Col2 = '"&B1&"'
ORDER BY Col1 ASC
LABEL Col1 '月份', Col3 '收入（万元）', Col4 '成本（万元）', Col5 '毛利率'",
0)
其中 B1 是下拉菜单或手动填写的 BU 名称。只要原始数据表在更新，每个 BU 的视图自动刷新，不需要任何手动操作。
如果需要同时展示多个 BU 的汇总对比（例如季度复盘时的横向对比表），可以在 GROUP BY 子句里完成聚合，而不是在 QUERY 外部再套 SUMIF：
=QUERY(原始数据!B2:F,
"SELECT Col2, SUM(Col3), SUM(Col4)
WHERE Col1 >= date '2026-01-01'
GROUP BY Col2
ORDER BY SUM(Col3) DESC
LABEL Col2 '业务单元', SUM(Col3) '一季度收入（万元）', SUM(Col4) '一季度成本（万元）'",
0)
这比在每个单元格里单独写 SUMIFS 更易维护：筛选条件、排序逻辑都集中在一处，改一个地方，整张表同步更新。
合并区域中的 ColN 重新计数
当你用花括号将两个区域拼合——如 {Sheet1!A:D, Sheet2!E:G}——QUERY 会将结果视为一张扁平的完整表格。ColN 从合并后区域最左列重新从 Col1 开始计数。Sheet2 的 E 列会变成 Col5（或其在合并表中实际所处的位置），而非 Col1。
这个技术本身没问题，但合并区域的公式可读性往往很差——三个月后回来维护会非常吃力。如果一定要跨表合并，建议把中间步骤拆开：先用一个辅助标签页把数据整合成一张干净的平表，再在看板标签页里对这张平表运行 QUERY。这样每一层都清晰可读，也方便后来的人接手。
QUERY Col 语法 vs. FILTER：如何选择
两个函数都能筛选行，但它们解决的是不同问题。
| 使用场景 | 用 QUERY | 用 FILTER |
|---|---|---|
| 需要列选择（SELECT） | 是 | 否 |
| 需要聚合计算（GROUP BY、求和） | 是 | 否 |
| 多条件筛选 | 均可 | 均可 |
| 新版 Sheets 动态数组输出 | 均可 | 是（更简洁） |
| 标题行处理 | 内置（第 3 个参数） | 需手动处理 |
| 复杂排序（ORDER BY） | 是 | 否 |
| 按 BU/类别分组汇总 | 是 | 否 |
对于基础的行筛选，FILTER 更简洁直观。一旦需要对数据进行重塑或聚合——从 8 列中选取 3 列、按类别汇总、按月份分组——QUERY 才是正确选择。
正如 Google Sheets 函数文档所述，QUERY"对数据运行 Google Visualization API 查询语言查询"——这意味着它是一个完整的查询引擎，而不仅仅是一个筛选层。
常见问题
QUERY 函数里的 Col1 和 Col2 是什么意思？
Col1 和 Col2 是 Google Sheets QUERY 函数所使用的 Google Visualization API 查询语言中的列位置编号。Col1 表示你传入的数据区域中最左边的第 1 列，Col2 表示第 2 列，以此类推。这与工作表的绝对列字母无关——如果你的区域是 D1:G100，那么 Col1 对应 D 列，Col2 对应 E 列，Col3 对应 F 列，Col4 对应 G 列。
为什么 QUERY 公式不能直接使用 A、B、C 这样的列字母？
因为 QUERY 底层运行的是 Google Visualization API 查询语言，而不是 Google Sheets 本身的引用语法。这套查询语言将传入的数据区域视为一张独立的数据表，并用 Col1、Col2、ColN 来标识其中的列。它不理解工作表坐标系中的 A、B、C，因此如果你在查询字符串中写 SELECT A, C WHERE B > 100，QUERY 会直接抛出解析错误（Parse error）。正确写法是 SELECT Col1, Col3 WHERE Col2 > 100，前提是你的区域从 A 列开始。
在 QUERY 区域前插入一列后，公式为什么会返回错误数据？
因为 ColN 的编号是相对于区域动态计算的，插入新列会导致所有 ColN 引用整体右移一位。举例来说，若原公式为 =QUERY(B:E, "SELECT Col1, Col2 WHERE Col3 = '已成交'")，在 B 列和 C 列之间插入一列后，原来对应 C 列的 Col2 现在变成了新插入列，原来的 C 列变成了 Col3，原来的筛选列 D 变成了 Col4。公式本身不会报错，但它筛选和返回的已经是完全不同的列。要降低这类风险，建议使用命名区域，或在公式旁边用注释记录各 ColN 对应的实际列名。
QUERY 适合用在正式的财务报告文件里吗？
这取决于场景。核心的损益表、资产负债表通常依赖 INDEX/MATCH 或直接引用，结构更清晰、审计更方便。QUERY 更适合运营看板和内部汇总视图——那些需要频繁按维度切片、对格式要求没那么严格的场景。如果你的受众是投资人或审计方，建议让公式链路尽可能透明；如果是给内部运营团队看的周报看板，QUERY 可以显著减少手动维护的工作量。