现象：同一条 SQL，每天处理的数据行数基本相近，但计算费用却突然飙升，甚至增长了好几倍。这类问题一旦出现，通常会让人很困惑——明明业务规模没有变化，为什么 MaxCompute 账单却突然大幅上涨？
分析：
先明确 MaxCompute SQL 后付费的计费公式：一条 SQL 执行费用 = 扫描输入量 × SQL 复杂度 × 0.3（￥/GB）。这个公式里，最关键的变量主要是输入量和复杂度。如果 SQL 逻辑本身没有改动，复杂度通常也比较稳定，那么费用突然上涨的主要原因，大概率就是扫描输入量异常变大。因此，排查这类 SQL 费用暴涨问题时，重点就要放在输入量上，逐步定位到底是哪个环节把数据量“撑大”了。
排查：
可以先选取两个不同时间段的 Job Logview 进行对比，重点查看输入量变化。推荐直接使用 MaxCompute Studio 的作业对比功能，查看起来更直观、效率也更高。输入量数据如下：
从图中可以看到，数据行数并没有明显翻倍，但数据大小（bytes）却增加了一倍左右。这说明基本可以排除“数据条数暴增”这一原因。那么，在行数变化不大的前提下，数据大小却明显上升，就意味着数据内容本身很可能发生了变化——例如某些字段值长度变长，导致整体占用存储空间变大。此时可以沿着数据上游链路继续排查，重点确认是否有某一列或某几个字段的值长度突然增大。如果这一步也没有发现异常，那么就需要进一步考虑数据存储压缩率下降的问题。
在 MaxCompute 中，表数据通常是经过压缩存储的，而且无论是存储计费还是 SQL 扫描计费，统计的都是压缩后的数据量。压缩率并不是固定不变的，它和表中数据的具体特征密切相关，例如平均字段长度、字段唯一值数量、数据重复度、内容相似性等。通常情况下，一个表里总会有一两个字段对整体存储空间影响最大，而这些字段往往也是影响压缩效果的关键因素。理解这个原理后，再回过头去分析费用暴涨当天的数据，就要重点关注这些输入数据在生成方式、字段处理方式上是否发生了变化。
下面举两个实际遇到的案例，都是因为数据产出方式发生变化，导致压缩率下降、数据 size 变大，最终引发 SQL 扫描输入量增加和费用上涨：
- 数据中的时间字段计算方式发生变化。原来入库时会统一处理为"yyyy-mm-dd 00:00:00"格式，在这种格式下，yyyy-mm-dd这一部分重复度较高，对压缩算法非常友好，因此压缩率也比较高。后来改成不做处理，直接存储原始时间"yyyy-mm-dd hh:mi:ss"，由于秒级时间差异增多，重复度下降，压缩率随之降低，数据 size 变大，最终 SQL 扫描输入量提升，费用自然上涨。
- 数据中的敏感字段处理方式发生变化。原来存储时不做额外处理，字段值相对有序，因此压缩率较高。后来出于数据安全考虑，通过自定义函数对该字段进行了加密，加密后的内容变得随机且无序，导致压缩率明显下降，数据 size 增大，同样会带来 SQL 扫描输入量上升，进而造成计算费用增加。
类似情况可能不止这两种，只是目前实际遇到的主要是这些。如果你也碰到了“SQL 没变、数据行数差不多、但 MaxCompute 费用突然上涨”的问题，不妨按照这个排查思路逐步分析，一般都能较快定位到根本原因。
