做自助分析的人大概都遇到过这种场景看板上的毛利率比财务口径少了两个点来回查了半天最后发现分母的聚合层级错了SUM 和 SUM_AGG 用反了。FineBI 里可用的函数数量不算多但每一个都有自己的脾气有的对数据类型极敏感有的在明细表和指标卡里返回完全不同的结果还有的在筛选器一动之后名次就全变了。这些问题官方文档不会逐条写只能靠自己一条一条踩出来、记下来。我这份清单最开始只有三行全是报错信息后来慢慢长成了现在这个样子每个函数记三样东西签名、边界、搭配。它解决的不是“会不会写公式”的问题而是“写完敢不敢用”的问题。适合两类人看一类是刚接手自助报表、被字段类型和聚合方式绕晕的新手另一类是用了一两年、能写出公式但偶尔被奇怪的空值和排名坑到的老手。下面这些内容都是围绕 FineBI 公式编辑器里的常见函数展开的涉及版本差异的地方我会明确标出来你照着试一遍就知道自己那边是哪一种。1. 我为什么把函数写成带坑位的清单1.1 函数在自助分析里的真实位置很多人对 BI 里函数的期待是做炫酷计算实际上日常 90% 的公式都在干三件事补口径、清脏数据、对齐时间粒度。补口径是把业务定义的算法落到字段上比如有效订单要排除测试单和已取消单清脏数据是处理从上游系统导出来的各种奇葩字符串对齐粒度则是让明细行和汇总行能在同一个组件里算得通。这三件事都不需要多高级的函数但对函数的边界条件要求极高一旦出错看板上的数字就是错的而且错得很安静。我在清单里给每个函数都留了一个边界位置就是专门写它在什么情况下会给你错误答案而不是报错。这一栏的价值远大于作用说明那一栏——报错你至少知道自己错了返回一个看起来合理的错值才最要命。比如文本转日期时格式串不匹配很多版本不会抛异常而是直接返回空值整列变成空白你在图表上看到的是数据缺失而不是格式写错了。1.2 一条函数笔记该记什么签名、边界、搭配我用的结构很简单三条签名参数顺序和类型、边界空值、零值、负数、超长文本、格式不匹配时分别返回什么、搭配它常和谁一起用组合起来能解决什么。第三条是最容易被忽略的但恰恰最有用。因为实际工作中你几乎不会单独用一个函数绝大多数公式都是三层嵌套起步。举个我记了很久的例子LEFT单看没什么可说的但它和LEN、FIND搭配就能做出按分隔符取第 N 段的效果再和IF搭配就能做容错——找不到分隔符时返回原值而不是截断出半截脏数据。这种搭配记忆比背参数表有用得多因为它直接对应一个能复用的解决方案。记录项写什么为什么重要签名参数顺序、必填项、类型要求少一个参数就报错类型不对可能静默失败边界空值、0、负数、超长、格式不匹配静默返回错值是最难排查的一类问题搭配常见组合写法直接对应可复用的解决方案验证一组能跑出期望值的最小数据版本升级或改公式后能快速回归1.3 一个被低估的前置动作把字段类型设对在写任何公式之前有一个动作比公式本身更影响结果确认参与计算的字段到底是什么类型。BI 工具里日期可能是文本、数字可能是文本、ID 可能是数字这些都会在你写出公式之后才暴露出来。文本型数字参与求和时有的版本会隐式转换有的版本直接返回空或者 0文本型日期做日期运算更是直接翻车。我的习惯是新建计算字段时先给它定类型数值就是数值、日期就是日期、标识类字段一律设为文本。ID 类字段设成数值是个典型的自找麻烦——订单号、工单号这类字段经常有前导零转成数值之后前导零就没了你在明细表里看到的号和业务系统里的号对不上排查起来能耗掉半天。2. 数值与聚合算得对比赛得巧重要2.1 取整家族的四种口径选错就返工取整这件事看着简单但我见过太多因为取整口径不一致导致对不上账的案例。常见的几个是ROUND四舍五入到指定小数位、ROUNDUP/ROUNDDOWN向上/向下舍入到指定小数位、CEILING/FLOOR向上/向下取到指定基数的倍数、INT向下取整到整数。名字都带取整行为完全不同尤其是碰到负数的时候。关键差异在于向哪个方向。INT(-1.5)在多数实现里得到 -2因为是向数轴左侧取ROUNDDOWN(-1.5)得到 -1因为是向零的方向截断。这两个在正数区间结果一样一旦数据里出现负数退款、冲销、负库存结果就分叉了。做金额调账和分档的时候这个分叉会让你算出来的档位和业务方对不上。函数典型写法3.7 的结果-3.7 的结果适合场景ROUNDROUND(值, 0)4-4金额展示、常规四舍五入ROUNDDOWNROUNDDOWN(值, 0)3-3向零截断避免多算INTINT(值)3-4向下取整分箱下界CEILINGCEILING(值, 1)4-3向上取整容量估算FLOORFLOOR(值, 5)0-5按固定步长分档我自己的取舍原则是展示层用ROUND因为人眼习惯四舍五入分档层用FLOOR或CEILING配合明确基数因为业务规则通常是每满 50 元一档这种左闭右开区间调账和结算层一律用ROUNDDOWN宁可少算不可多算。这三条定下来之后同一份数据在不同报表里的口径就不会打架。注意金额计算不要在明细层就取整取整只在最终展示层做一次。中间过程每取一次整误差就累积一次几百行数据累下来能差出几块钱这种差异对不上账最难解释。2.2 聚合函数的层级差SUM 和 SUM_AGG 到底差在哪这是 FineBI 里最需要先搞清楚的一对概念。SUM(销售额)是对当前分析粒度做汇总把很多行压成一个值而SUM_AGG(销售额)是在明细级别做聚合保留每一行同时对整列或指定范围做聚合。听起来绕用一句话概括前者改变行数后者不改变行数。这个差别在做占比、排名、明细对比时是决定性的。你在明细表里直接写SUM(销售额)每一行显示的都是整列合计值看起来像每行都一样很多人第一次遇到会以为是组件出问题。而如果公式本身已经是聚合函数字段的求和方式又设成了求和有的版本会直接报聚合嵌套错误。我的经验是先确定这个组件的分析粒度是什么——一行代表一个订单、还是一个客户、还是一个品类。粒度定了才知道公式里该用哪一层。粒度是订单要算该订单占客户总额的比例分子用明细值分母就必须用SUM_AGG按客户分组如果分母也用SUM整张表会被压缩成一行。2.3 占比、环比里最容易翻车的分母占比公式的经典错误是分子分母同粒度。写SUM(销售额) / SUM(销售额)得到的一定是 1因为两边的计算范围完全一致。正确的分母必须是更大的范围也就是把分组维度清空之后的总额。FineBI 里实现这件事有三条路用组件自带的快速计算→占比最省事推荐、用DEF_ADD(SUM(销售额), [])这种把维度置空的写法、或者单独建一个合计字段做关联。我更推荐第一条因为它是工具内置的语义切换维度之后会自动跟着变。手写分母的问题在于它是硬编码的你今天按品类分组明天想看按区域分组公式里的维度得手改改漏了就是错的数字。用DEF_ADD的时候尤其要注意第二个参数——维度列表传空和传当前维度是两回事传空才是全表。提示任何占比加起来等于 100%的检查都应该做成固定动作。如果加起来是 98% 或者 102%大概率是某一类的值为空被排除了而不是计算错误。3. 字符串函数脏数据的第一道过滤器3.1 截取、拼接与按分隔符拆列文本处理的基本盘是LEFT、RIGHT、MID、LEN、CONCATENATE、SPLIT。MID(文本, 起始位置, 长度)需要特别注意起始位置是从 1 开始还是从 0 开始FineBI 沿用的是从 1 开始的习惯和 Excel 一致但你如果脑子里想着编程语言的索引就会差一位截出来的字符串整体偏移一个字符肉眼还不容易发现。按分隔符拆列是高频需求比如省-市-区这种合在一起的字段。稳妥的写法是配FIND定位分隔符再用LEFT/MID去截。但更省事的是SPLIT(文本, 分隔符, 序号)直接取第几段。代价是它对异常值不友好——如果某行只有两段而你要第三段有的版本返回空有的返回原值需要自己测一遍。我在清单里给SPLIT标了个红上线前必须用段数不足的样本验一遍。CONCATENATE拼接时要注意空值。多数实现里空值参与拼接会得到空而不是忽略空值拼其他的。所以拼地址这类字段时正确写法是先用IFNULL把空值兜成空字符串再拼接否则一个区县字段为空整条地址就全空了。拼接容错写法示例 CONCATENATE(IFNULL(省,), IFNULL(市,), IFNULL(区,), IFNULL(详细地址,))3.2 替换、去空格与看不见的字符TRIM只清首尾的空格中间连续的空格不处理而且对全角空格和制表符经常无能为力。从各类系统导出来的数据里全角空格、不换行空格、\t、回车符是常客肉眼在明细表里看不出来但做分组汇总时北京和北京 会变成两个不同的组图上就多出来一根莫名其妙的柱子。我的处理链条固定三步先REPLACE掉已知的特殊字符再TRIM最后如果不是关键字段就统一做一次规范化。全角空格的处理可以直接写替换把它换成空字符串。文本清洗常用组合 TRIM(REPLACE(REPLACE(REPLACE(字段, , ), \t, ), \r, ))REPLACE(文本, 旧串, 新串)是全量替换SUBSTITUTE在某些实现里支持指定替换第几次出现做只替换最后一个分隔符这类操作时用得上。这两个的差别不大但如果你需要精确控制替换次数就得用后者。注意清洗类公式改完之后务必用COUNTD(字段)对比清洗前后的去重计数。数字没变说明洗的是同一个值数字变小说明确实合并了之前被误判为两个的值这个对比是最快的验证手段。3.3 把明细压成一行分组内文本聚合给客户做汇总表时经常会遇到想看每个客户下所有订单号拼成一行的需求。这类需求在公式层面不一定有现成函数取决于你用的版本——有的版本提供了分组内字符串拼接的聚合函数参数是字段和分隔符没有的话走自助数据集的分组汇总配合自关联或者干脆在 SQL 数据集那层用字符串聚合函数处理好再进来。我的判断标准是如果拼接后的字段只用于展示比如在明细表里给业务看该客户涉及哪些品类就在数据集层做如果还需要参与后续计算就不要拼接老实用一对多关联。拼接出来的长字符串在后续计算里几乎没法用还容易超长截断。另外提醒一句拼接后的长度是有上限的客户下挂几千个订单号拼起来超出限制会被截断而且截断是静默的你在表里看到的就是少了几个。需要完整清单的场景直接导出明细别指望一个单元格装下。4. 日期函数时间序列分析的地基4.1 文本转日期与格式化的双向路TODATE(文本, 格式)和FORMAT(日期, 格式)是一对反向操作几乎所有日期相关的坑都出在这两个身上。第一条铁律格式串必须和文本的实际长相完全一致包括分隔符和位数。2024/3/5和2024-03-05是两个完全不同的格式串混在一列里就会有一部分转不出来。第二条格式串是区分大小写的。MM是月份mm是分钟HH是 24 小时制hh是 12 小时制yyyy是四位年份YY是两位。这个大小写规则来自底层的 Java 日期格式写错了不会报错只会给你一个看起来很像但不是你要的结果——比如把月份的MM写成mm格式化出来的月其实取的是当前时间的分钟数整列数据的月份就成了 0 到 59 之间的随机数。格式串含义容易写错的点yyyy-MM-dd四位年-月-日写成 YYYY 在某些实现里是周年yyyy-MM年-月用 mm 会变成分钟MM-dd月-日排序时需要补零HH:mm:ss24 小时时分秒用 hh 会变成 12 小时制yyyy-MM-dd HH:mm:ss完整时间戳分隔符 T 或空格必须一致4.2 年月周粒度的对齐截断和偏移要分清做月度趋势时最常见的错误是把日期格式化成yyyy-MM之后直接用来排序结果2024-10排在了2024-2前面——因为格式化之后它是文本文本排序是按字符比大小的。解决办法有两个一是格式化时用补零的yyyy-MM月份两位1会变成01文本排序就正确了二是保留日期类型用构造月初日期的方式做截断DATE(YEAR(日期), MONTH(日期), 1)出来的始终是日期型排序和图表的横轴都不会出问题。我倾向第二种。因为文本型的月份虽然能排序但你在它上面做日期运算比如往前推一个月做同比就做不了了还得再转回去。多一次转换就多一个出错点。日期型字段从进入模型到画成图最好全程都保持日期类型只在最终的标签展示上用FORMAT转一次文本。周粒度的坑更多。一周从周几开始不同系统不一样有的从周日算有的从周一开始。WEEKNUM这类函数通常有第二个参数控制起始日但默认值未必符合你们业务的习惯。如果业务是按自然周周一到周日结算而函数默认从周日开始你算出来的每一周都会多含一天上周末的数据做周环比时数字会持续偏移。提示周粒度上线前拿一个已知的完整周比如跨月的那一周单独验证一遍把结果和业务方手里的周报对一下。十分钟的验证能省掉后面无数次的解释。4.3 同比环比日期怎么挪同比是把本期和去年同一时期比环比是和上一个相邻周期比。实现上都需要把日期做位移常用的是DATEDELTA(日期, 偏移量, 单位)和DATESUBDATE(日期, 偏移量, 单位)一个加一个减单位可以是天、月、年。做同比时最稳的写法不是今年 3 月比去年 3 月而是先确定一个比较基准比如本期累计到 3 月 15 日去年同期也取到 3 月 15 日。如果去年同期直接取整个 3 月你比的就是 15 天的量和 31 天的量出来的增长率毫无意义。这个细节在月度看板上尤其重要——月初打开看板本期只有 5 天数据同比却拿了去年整月图上的线一定是断崖式下跌。差值计算用DATEDIF(开始, 结束, 单位)返回两个日期之间的间隔数。用它算距今天数是高频写法距今天数与客户账龄 DATEDIF(下单日期, TODAY(), D) DATEDIF(首次成交日, TODAY(), M) / 124.4 三个高频的粒度陷阱第一个是月末。用DATEDELTA(日期, 1, M)去推下个月的同一天如果当前是 1 月 31 日推出来可能是 2 月 28 日或者 3 月 3 日取决于实现。需要精确控制月末的场景要用构造月末的逻辑而不是简单加一个月。第二个是跨年。按月做序列时只取月份数字会漏掉年份2023 年 1 月和 2024 年 1 月会被归到同一组。所有按月聚合的字段都必须带上年份yyyy-MM或者DATE(YEAR(日期), MONTH(日期), 1)都可以别只取MONTH。第三个是时区与时间戳。如果数据源里的时间是带时分秒的字符串直接按日期分组会和你想的不一样——2024-03-15 23:30和2024-03-16 00:30在按天截断后分属两天但如果原始数据用的是别的时区边界上的数据就会串天。日汇总类看板建议在数据集层就统一截断到天不要留到组件里再处理。5. 逻辑与空值最容易被低估的一段5.1 IF 的嵌套和更适合它的替代品IF(条件, 真值, 假值)是最常写的函数也是最快失控的函数。三层以上嵌套之后公式变成一坨括号改一个条件要花十分钟找匹配而且嵌套的求值顺序是从内向外你读的时候是从左向右两边对不上就容易改错分支。我的做法是超过三档就用SWITCH或者改成分段字段 排序的思路先建一个数值型的分档字段用多个简单的IF逐条判断并赋值1、2、3、4再用这个分档字段去关联一张维表拿到中文名称。这样每个IF都是单层、可独立验证的出问题只影响一个档位不会全盘错乱。条件里还要注意AND/OR的优先级和括号。IF(A1 OR B1 AND C1, ...)这类写法在不同实现里的结合顺序可能不同括号不加就是给自己埋雷。我现在的习惯是只要条件里出现两个以上的逻辑运算符一律把每个子条件用小括号包起来可读性也一起解决了。5.2 NULL 不是 0也不是空字符串这三个东西在 BI 里是完全不同的NULL是没有值0是值为零是值为空字符串。它们在明细表里可能都显示成空白但参与计算时行为完全不同。最常见的翻车是求和NULL参与算术运算结果还是NULL一个空值能让整个计算结果变成空白而0参与运算不影响结果。ISNULL(字段)用来判断是不是空返回布尔IFNULL(字段, 兜底值)或者NVL(字段, 兜底值)用来给空值兜底。后两个在很多版本里是等价的用哪个看你那边函数列表里有哪个。兜底值的选择也有讲究数值字段兜0文本字段兜空字符串日期字段不要硬兜因为日期兜一个假值比如 1970 年会污染时间序列分析宁可让它空着并用ISNULL单独标记。注意COUNT(字段)和COUNT(*)的区别就在这里。前者统计非空值的个数后者统计行数。算有手机号的客户数时要用前者算客户总数时要用后者或者COUNTD(客户ID)。用错了两个口径的差异能达到几十个百分点而且数字看起来都很合理不容易发现。5.3 除零保护和异常兜底除法是 BI 里最容易出问题的一类计算因为分母为 0 或者为NULL时有的版本返回NULL有的版本直接报错导致整个组件加载失败。保单写法是把分母包起来判断安全的比率计算 IF(ISNULL(分母) OR 分母 0, 0, 分子 / 分母)如果业务上分母为 0和分母为空需要区分展示比如一个显示 0%一个显示—就把兜底值分开写别统一兜成 0。因为这两件事的含义不一样一个是确实没有量一个是数据没采到。混在一起看会让人误判某个区域业绩为零实际只是那天没传数据。另外异常兜底不要过度。我见过有人给每个公式都套三层IF防错结果公式本身变成了一团乱麻真正出问题时根本没法定位。防错的重点应该放在分母、日期转换、类型转换这三个高危动作上其他地方的错就让它错报出来反而好查。6. 窗口类函数在明细和汇总之间来回跳6.1 三种排名口径的差别排名是 BI 里最日常的需求也是口径分歧最大的地方。三种常见口径并列名次且后续跳号1、1、3、并列名次且不跳号1、1、2、不并列直接按行编号1、2、3。同样一批数据三种口径出来的名次全不一样业务方说我们排第五你得先问清楚是哪种。口径出现并列时示例适用场景跳号排名同名次后续跳号1、1、3排行榜、竞赛名次不跳号排名同名次后续连号1、1、2分档、等级划分行编号不并列强行区分1、2、3取 TopN 明细行FineBI 里这类排名通常通过组件的快速计算→排名配置可以选跳号或不跳号。如果你的需求是取排名前三的产品用不跳号会得到可能超过三个的结果因为并列的都会被选进来用行编号则严格三个但并列的顺序是随机的翻页刷新可能变。这两种结果都能用关键是先跟需求方确认他要哪一种。6.2 分组占比与累计筛选器一动数字就变分组内占比和累计求和这类计算最容易踩的坑是它跟着当前视图走。你在组件里放了一个区域筛选器排名和占比就会在被筛选后的范围内重算看起来名次变了、占比超过 100% 了实际公式没错是计算范围变了。判断方法很简单把筛选器去掉看数字是否回到预期。如果回去了说明是范围问题不是公式问题。要固定范围就得用能锁维度的写法把计算范围显式声明出来而不是依赖组件当前的视图范围。这类固定维度的函数在 FineBI 里是DEF_ADD这一族第二个参数传维度列表传空表示全表。我的经验是把跟着视图走设成默认预期因为大多数交互式看板就是希望筛选后重算。只有当你需要全局占比或者全公司排名这种固定口径时才去锁维度而且要在组件标题或者备注里写清楚此指标为全局口径不受筛选影响不然一定有人来问为什么筛了区域之后占比没变。6.3 明细级参与汇总计算怎么组织最复杂的一类需求是每一行都要展示但每一行的值又依赖它所在分组的汇总。比如明细表里每个订单一行要同时显示订单金额、该客户的总金额、该订单占客户总额的比例。这三列的计算层级分别是明细、客户分组、两者相除。做法上订单金额就是原始字段客户总金额用SUM_AGG(订单金额)并按客户分组占比则是两者相除。这里的关键是SUM_AGG不会压缩行数所以明细行的数量保持不变。如果你用的是SUM整张表会被压成客户粒度订单行就没了。还有一层要注意SUM_AGG这类函数的计算是在组件渲染时做的数据量大十万行以上明细时会有明显性能损耗。我的处理是能预聚合就先预聚合把客户总额在数据集层算好存成一列组件里直接取比每次渲染都算一遍快得多。明细表超过五万行时这个优化基本是必须的。7. 三个可以直接抄的组合模板7.1 客户价值分层把连续金额切成档分层需求随处可见做法是先用明细级聚合算出每个客户的核心指标再用IF或分档逻辑切段。下面是按累计消费金额分四档的写法档位边界用业务定的实际值替换。客户分层金额单位元 IF(ISNULL(SUM_AGG(消费金额)), 未消费, IF(SUM_AGG(消费金额) 10000, 高价值, IF(SUM_AGG(消费金额) 3000, 中价值, IF(SUM_AGG(消费金额) 0, 低价值, 未消费))))写这类公式有两个细节值得注意。第一判断顺序必须从大到小或者从小到大单向走不能交叉否则某个区间的数据会被先命中的条件吃掉。第二边界值用还是要和业务确认尤其是刚好等于 3000这种卡在边界上的客户归到哪一档事后争论起来很费劲不如一开始就写进公式注释里。分层字段做完之后建议不要直接删掉中间的计算字段保留一列原始金额方便业务方核对。我踩过一次坑分层结果和财务的名单对不上查了半天发现是分层用的金额口径含不含运费和财务不一样但因为中间字段被删了只能从头重算一遍。7.2 一列搞定同比环比同比环比也可以用组件的快速计算直接出但如果要放在同一个表格里对比多个指标手写公式更灵活。核心思路是把本期和同期分别算出来再相除同期的取值靠日期偏移或者靠时间维表的关联。同比增长率同期口径 IF(ISNULL(同期销售额) OR 同期销售额 0, NULL, (本期销售额 - 同期销售额) / 同期销售额)分母为 0 时返回NULL而不是 0这是有意的增长率在基数为 0 时没有数学意义显示 0% 会误导人以为没增长显示空白或者—更诚实。这个取舍我在好几个项目里都坚持业务方一开始会问为什么这里是空的解释一次之后就都认可了。7.3 敏感字段的展示脱敏手机号、身份证号这类字段在明细表里直接展示是有风险的常见的处理是保留头尾、中间打码。用LEFT加RIGHT拼接就能做注意长度不足时要兜底别把短号也按固定位数截。手机号脱敏保留前3后4 IF(ISNULL(手机号) OR LEN(手机号) 7, —, CONCATENATE(LEFT(手机号, 3), ****, RIGHT(手机号, 4)))脱敏要在展示层做不要在数据集层把原值覆盖掉。原因很实际业务方迟早会需要原始号码去做回访覆盖掉之后就得重新接一次数据源。更好的做法是同一张表里同时保留原字段和脱敏字段原字段设权限只有特定角色可见脱敏字段给所有人看。8. 让这份清单不断更新下来的维护方法8.1 我给每条函数笔记定的固定格式清单能不能长期用下去取决于格式是否统一。我的模板是五栏函数名、一句话作用、最小可用写法、踩过的坑、验证数据。第三栏强制要求写成能直接复制粘贴的完整公式不要写参数填字段名这种废话因为真正需要抄的时候你根本不想再想一遍参数顺序。第四栏只写亲身遇到的不抄文档抄来的坑记不住。栏目内容示例填写要求函数名SPLIT写全名别名另起一行一句话作用按分隔符取第 N 段文本不超过 20 字最小写法SPLIT(地址, -, 2)可直接复制运行踩过的坑段数不足时返回原值不是空只写亲测过的验证数据京-沪-穗 / 京-沪 / 京至少三条边界样本这个格式最大的好处是逼着你去验证。填第五栏的时候你会发现很多你以为理所当然的行为其实没测过一测就露馅。我给每个函数都留了三条样本正常值、边界值、异常值。这三条样本本身也成了回归测试集版本升级或者公式改动之后跑一遍几分钟就能确认没问题。8.2 踩雷登记比函数清单更值钱的部分单独拉一张表记踩过的雷格式是现象、定位过程、根因、修复写法。这张表的价值比函数清单本身还高因为函数行为查文档总能查到而为什么这个报错看起来完全不相干只有踩过的人知道。举几个我记下来的典型一是文本型数字参与求和返回空现象是这个指标一片空白根因是字段类型被识别成文本修复是在数据集层改类型或者用转换函数强转二是明细表里出现每行都一样的值根因是用了SUM而不是SUM_AGG分析粒度被压缩了三是排名在刷新页面后变了根因是并列值的排序不稳定需要加一个唯一的次级排序字段。第三条特别值得说一句给排名加次级排序是个小动作但能解决刷新一次换一个结果这种让人怀疑人生的现象。次级排序字段选主键或者时间戳都行目的是让并列项之间有一个确定的先后这样每次渲染出来的顺序都是同一个。维护这件事没什么技巧就是顺手记。每次排查完一个公式问题花两分钟把现象和根因敲进表里三个月之后你会感谢当时的自己。我现在这份清单已经长到需要分页了但每次接手新的分析需求翻一遍就能找到七八成的参考答案比重新摸索快太多。最后分享一个小习惯每次改动公式把旧写法在注释里留一行写上改的原因和日期。半年后回头看那一行注释往往比公式本身更能帮你回忆起当时的业务背景。
做自助分析的人大概都遇到过这种场景看板上的毛利率比财务口径少了两个点来回查了半天最后发现分母的聚合层级错了SUM 和 SUM_AGG 用反了。FineBI 里可用的函数数量不算多但每一个都有自己的脾气有的对数据类型极敏感有的在明细表和指标卡里返回完全不同的结果还有的在筛选器一动之后名次就全变了。这些问题官方文档不会逐条写只能靠自己一条一条踩出来、记下来。我这份清单最开始只有三行全是报错信息后来慢慢长成了现在这个样子每个函数记三样东西签名、边界、搭配。它解决的不是“会不会写公式”的问题而是“写完敢不敢用”的问题。适合两类人看一类是刚接手自助报表、被字段类型和聚合方式绕晕的新手另一类是用了一两年、能写出公式但偶尔被奇怪的空值和排名坑到的老手。下面这些内容都是围绕 FineBI 公式编辑器里的常见函数展开的涉及版本差异的地方我会明确标出来你照着试一遍就知道自己那边是哪一种。1. 我为什么把函数写成带坑位的清单1.1 函数在自助分析里的真实位置很多人对 BI 里函数的期待是做炫酷计算实际上日常 90% 的公式都在干三件事补口径、清脏数据、对齐时间粒度。补口径是把业务定义的算法落到字段上比如有效订单要排除测试单和已取消单清脏数据是处理从上游系统导出来的各种奇葩字符串对齐粒度则是让明细行和汇总行能在同一个组件里算得通。这三件事都不需要多高级的函数但对函数的边界条件要求极高一旦出错看板上的数字就是错的而且错得很安静。我在清单里给每个函数都留了一个边界位置就是专门写它在什么情况下会给你错误答案而不是报错。这一栏的价值远大于作用说明那一栏——报错你至少知道自己错了返回一个看起来合理的错值才最要命。比如文本转日期时格式串不匹配很多版本不会抛异常而是直接返回空值整列变成空白你在图表上看到的是数据缺失而不是格式写错了。1.2 一条函数笔记该记什么签名、边界、搭配我用的结构很简单三条签名参数顺序和类型、边界空值、零值、负数、超长文本、格式不匹配时分别返回什么、搭配它常和谁一起用组合起来能解决什么。第三条是最容易被忽略的但恰恰最有用。因为实际工作中你几乎不会单独用一个函数绝大多数公式都是三层嵌套起步。举个我记了很久的例子LEFT单看没什么可说的但它和LEN、FIND搭配就能做出按分隔符取第 N 段的效果再和IF搭配就能做容错——找不到分隔符时返回原值而不是截断出半截脏数据。这种搭配记忆比背参数表有用得多因为它直接对应一个能复用的解决方案。记录项写什么为什么重要签名参数顺序、必填项、类型要求少一个参数就报错类型不对可能静默失败边界空值、0、负数、超长、格式不匹配静默返回错值是最难排查的一类问题搭配常见组合写法直接对应可复用的解决方案验证一组能跑出期望值的最小数据版本升级或改公式后能快速回归1.3 一个被低估的前置动作把字段类型设对在写任何公式之前有一个动作比公式本身更影响结果确认参与计算的字段到底是什么类型。BI 工具里日期可能是文本、数字可能是文本、ID 可能是数字这些都会在你写出公式之后才暴露出来。文本型数字参与求和时有的版本会隐式转换有的版本直接返回空或者 0文本型日期做日期运算更是直接翻车。我的习惯是新建计算字段时先给它定类型数值就是数值、日期就是日期、标识类字段一律设为文本。ID 类字段设成数值是个典型的自找麻烦——订单号、工单号这类字段经常有前导零转成数值之后前导零就没了你在明细表里看到的号和业务系统里的号对不上排查起来能耗掉半天。2. 数值与聚合算得对比赛得巧重要2.1 取整家族的四种口径选错就返工取整这件事看着简单但我见过太多因为取整口径不一致导致对不上账的案例。常见的几个是ROUND四舍五入到指定小数位、ROUNDUP/ROUNDDOWN向上/向下舍入到指定小数位、CEILING/FLOOR向上/向下取到指定基数的倍数、INT向下取整到整数。名字都带取整行为完全不同尤其是碰到负数的时候。关键差异在于向哪个方向。INT(-1.5)在多数实现里得到 -2因为是向数轴左侧取ROUNDDOWN(-1.5)得到 -1因为是向零的方向截断。这两个在正数区间结果一样一旦数据里出现负数退款、冲销、负库存结果就分叉了。做金额调账和分档的时候这个分叉会让你算出来的档位和业务方对不上。函数典型写法3.7 的结果-3.7 的结果适合场景ROUNDROUND(值, 0)4-4金额展示、常规四舍五入ROUNDDOWNROUNDDOWN(值, 0)3-3向零截断避免多算INTINT(值)3-4向下取整分箱下界CEILINGCEILING(值, 1)4-3向上取整容量估算FLOORFLOOR(值, 5)0-5按固定步长分档我自己的取舍原则是展示层用ROUND因为人眼习惯四舍五入分档层用FLOOR或CEILING配合明确基数因为业务规则通常是每满 50 元一档这种左闭右开区间调账和结算层一律用ROUNDDOWN宁可少算不可多算。这三条定下来之后同一份数据在不同报表里的口径就不会打架。注意金额计算不要在明细层就取整取整只在最终展示层做一次。中间过程每取一次整误差就累积一次几百行数据累下来能差出几块钱这种差异对不上账最难解释。2.2 聚合函数的层级差SUM 和 SUM_AGG 到底差在哪这是 FineBI 里最需要先搞清楚的一对概念。SUM(销售额)是对当前分析粒度做汇总把很多行压成一个值而SUM_AGG(销售额)是在明细级别做聚合保留每一行同时对整列或指定范围做聚合。听起来绕用一句话概括前者改变行数后者不改变行数。这个差别在做占比、排名、明细对比时是决定性的。你在明细表里直接写SUM(销售额)每一行显示的都是整列合计值看起来像每行都一样很多人第一次遇到会以为是组件出问题。而如果公式本身已经是聚合函数字段的求和方式又设成了求和有的版本会直接报聚合嵌套错误。我的经验是先确定这个组件的分析粒度是什么——一行代表一个订单、还是一个客户、还是一个品类。粒度定了才知道公式里该用哪一层。粒度是订单要算该订单占客户总额的比例分子用明细值分母就必须用SUM_AGG按客户分组如果分母也用SUM整张表会被压缩成一行。2.3 占比、环比里最容易翻车的分母占比公式的经典错误是分子分母同粒度。写SUM(销售额) / SUM(销售额)得到的一定是 1因为两边的计算范围完全一致。正确的分母必须是更大的范围也就是把分组维度清空之后的总额。FineBI 里实现这件事有三条路用组件自带的快速计算→占比最省事推荐、用DEF_ADD(SUM(销售额), [])这种把维度置空的写法、或者单独建一个合计字段做关联。我更推荐第一条因为它是工具内置的语义切换维度之后会自动跟着变。手写分母的问题在于它是硬编码的你今天按品类分组明天想看按区域分组公式里的维度得手改改漏了就是错的数字。用DEF_ADD的时候尤其要注意第二个参数——维度列表传空和传当前维度是两回事传空才是全表。提示任何占比加起来等于 100%的检查都应该做成固定动作。如果加起来是 98% 或者 102%大概率是某一类的值为空被排除了而不是计算错误。3. 字符串函数脏数据的第一道过滤器3.1 截取、拼接与按分隔符拆列文本处理的基本盘是LEFT、RIGHT、MID、LEN、CONCATENATE、SPLIT。MID(文本, 起始位置, 长度)需要特别注意起始位置是从 1 开始还是从 0 开始FineBI 沿用的是从 1 开始的习惯和 Excel 一致但你如果脑子里想着编程语言的索引就会差一位截出来的字符串整体偏移一个字符肉眼还不容易发现。按分隔符拆列是高频需求比如省-市-区这种合在一起的字段。稳妥的写法是配FIND定位分隔符再用LEFT/MID去截。但更省事的是SPLIT(文本, 分隔符, 序号)直接取第几段。代价是它对异常值不友好——如果某行只有两段而你要第三段有的版本返回空有的返回原值需要自己测一遍。我在清单里给SPLIT标了个红上线前必须用段数不足的样本验一遍。CONCATENATE拼接时要注意空值。多数实现里空值参与拼接会得到空而不是忽略空值拼其他的。所以拼地址这类字段时正确写法是先用IFNULL把空值兜成空字符串再拼接否则一个区县字段为空整条地址就全空了。拼接容错写法示例 CONCATENATE(IFNULL(省,), IFNULL(市,), IFNULL(区,), IFNULL(详细地址,))3.2 替换、去空格与看不见的字符TRIM只清首尾的空格中间连续的空格不处理而且对全角空格和制表符经常无能为力。从各类系统导出来的数据里全角空格、不换行空格、\t、回车符是常客肉眼在明细表里看不出来但做分组汇总时北京和北京 会变成两个不同的组图上就多出来一根莫名其妙的柱子。我的处理链条固定三步先REPLACE掉已知的特殊字符再TRIM最后如果不是关键字段就统一做一次规范化。全角空格的处理可以直接写替换把它换成空字符串。文本清洗常用组合 TRIM(REPLACE(REPLACE(REPLACE(字段, , ), \t, ), \r, ))REPLACE(文本, 旧串, 新串)是全量替换SUBSTITUTE在某些实现里支持指定替换第几次出现做只替换最后一个分隔符这类操作时用得上。这两个的差别不大但如果你需要精确控制替换次数就得用后者。注意清洗类公式改完之后务必用COUNTD(字段)对比清洗前后的去重计数。数字没变说明洗的是同一个值数字变小说明确实合并了之前被误判为两个的值这个对比是最快的验证手段。3.3 把明细压成一行分组内文本聚合给客户做汇总表时经常会遇到想看每个客户下所有订单号拼成一行的需求。这类需求在公式层面不一定有现成函数取决于你用的版本——有的版本提供了分组内字符串拼接的聚合函数参数是字段和分隔符没有的话走自助数据集的分组汇总配合自关联或者干脆在 SQL 数据集那层用字符串聚合函数处理好再进来。我的判断标准是如果拼接后的字段只用于展示比如在明细表里给业务看该客户涉及哪些品类就在数据集层做如果还需要参与后续计算就不要拼接老实用一对多关联。拼接出来的长字符串在后续计算里几乎没法用还容易超长截断。另外提醒一句拼接后的长度是有上限的客户下挂几千个订单号拼起来超出限制会被截断而且截断是静默的你在表里看到的就是少了几个。需要完整清单的场景直接导出明细别指望一个单元格装下。4. 日期函数时间序列分析的地基4.1 文本转日期与格式化的双向路TODATE(文本, 格式)和FORMAT(日期, 格式)是一对反向操作几乎所有日期相关的坑都出在这两个身上。第一条铁律格式串必须和文本的实际长相完全一致包括分隔符和位数。2024/3/5和2024-03-05是两个完全不同的格式串混在一列里就会有一部分转不出来。第二条格式串是区分大小写的。MM是月份mm是分钟HH是 24 小时制hh是 12 小时制yyyy是四位年份YY是两位。这个大小写规则来自底层的 Java 日期格式写错了不会报错只会给你一个看起来很像但不是你要的结果——比如把月份的MM写成mm格式化出来的月其实取的是当前时间的分钟数整列数据的月份就成了 0 到 59 之间的随机数。格式串含义容易写错的点yyyy-MM-dd四位年-月-日写成 YYYY 在某些实现里是周年yyyy-MM年-月用 mm 会变成分钟MM-dd月-日排序时需要补零HH:mm:ss24 小时时分秒用 hh 会变成 12 小时制yyyy-MM-dd HH:mm:ss完整时间戳分隔符 T 或空格必须一致4.2 年月周粒度的对齐截断和偏移要分清做月度趋势时最常见的错误是把日期格式化成yyyy-MM之后直接用来排序结果2024-10排在了2024-2前面——因为格式化之后它是文本文本排序是按字符比大小的。解决办法有两个一是格式化时用补零的yyyy-MM月份两位1会变成01文本排序就正确了二是保留日期类型用构造月初日期的方式做截断DATE(YEAR(日期), MONTH(日期), 1)出来的始终是日期型排序和图表的横轴都不会出问题。我倾向第二种。因为文本型的月份虽然能排序但你在它上面做日期运算比如往前推一个月做同比就做不了了还得再转回去。多一次转换就多一个出错点。日期型字段从进入模型到画成图最好全程都保持日期类型只在最终的标签展示上用FORMAT转一次文本。周粒度的坑更多。一周从周几开始不同系统不一样有的从周日算有的从周一开始。WEEKNUM这类函数通常有第二个参数控制起始日但默认值未必符合你们业务的习惯。如果业务是按自然周周一到周日结算而函数默认从周日开始你算出来的每一周都会多含一天上周末的数据做周环比时数字会持续偏移。提示周粒度上线前拿一个已知的完整周比如跨月的那一周单独验证一遍把结果和业务方手里的周报对一下。十分钟的验证能省掉后面无数次的解释。4.3 同比环比日期怎么挪同比是把本期和去年同一时期比环比是和上一个相邻周期比。实现上都需要把日期做位移常用的是DATEDELTA(日期, 偏移量, 单位)和DATESUBDATE(日期, 偏移量, 单位)一个加一个减单位可以是天、月、年。做同比时最稳的写法不是今年 3 月比去年 3 月而是先确定一个比较基准比如本期累计到 3 月 15 日去年同期也取到 3 月 15 日。如果去年同期直接取整个 3 月你比的就是 15 天的量和 31 天的量出来的增长率毫无意义。这个细节在月度看板上尤其重要——月初打开看板本期只有 5 天数据同比却拿了去年整月图上的线一定是断崖式下跌。差值计算用DATEDIF(开始, 结束, 单位)返回两个日期之间的间隔数。用它算距今天数是高频写法距今天数与客户账龄 DATEDIF(下单日期, TODAY(), D) DATEDIF(首次成交日, TODAY(), M) / 124.4 三个高频的粒度陷阱第一个是月末。用DATEDELTA(日期, 1, M)去推下个月的同一天如果当前是 1 月 31 日推出来可能是 2 月 28 日或者 3 月 3 日取决于实现。需要精确控制月末的场景要用构造月末的逻辑而不是简单加一个月。第二个是跨年。按月做序列时只取月份数字会漏掉年份2023 年 1 月和 2024 年 1 月会被归到同一组。所有按月聚合的字段都必须带上年份yyyy-MM或者DATE(YEAR(日期), MONTH(日期), 1)都可以别只取MONTH。第三个是时区与时间戳。如果数据源里的时间是带时分秒的字符串直接按日期分组会和你想的不一样——2024-03-15 23:30和2024-03-16 00:30在按天截断后分属两天但如果原始数据用的是别的时区边界上的数据就会串天。日汇总类看板建议在数据集层就统一截断到天不要留到组件里再处理。5. 逻辑与空值最容易被低估的一段5.1 IF 的嵌套和更适合它的替代品IF(条件, 真值, 假值)是最常写的函数也是最快失控的函数。三层以上嵌套之后公式变成一坨括号改一个条件要花十分钟找匹配而且嵌套的求值顺序是从内向外你读的时候是从左向右两边对不上就容易改错分支。我的做法是超过三档就用SWITCH或者改成分段字段 排序的思路先建一个数值型的分档字段用多个简单的IF逐条判断并赋值1、2、3、4再用这个分档字段去关联一张维表拿到中文名称。这样每个IF都是单层、可独立验证的出问题只影响一个档位不会全盘错乱。条件里还要注意AND/OR的优先级和括号。IF(A1 OR B1 AND C1, ...)这类写法在不同实现里的结合顺序可能不同括号不加就是给自己埋雷。我现在的习惯是只要条件里出现两个以上的逻辑运算符一律把每个子条件用小括号包起来可读性也一起解决了。5.2 NULL 不是 0也不是空字符串这三个东西在 BI 里是完全不同的NULL是没有值0是值为零是值为空字符串。它们在明细表里可能都显示成空白但参与计算时行为完全不同。最常见的翻车是求和NULL参与算术运算结果还是NULL一个空值能让整个计算结果变成空白而0参与运算不影响结果。ISNULL(字段)用来判断是不是空返回布尔IFNULL(字段, 兜底值)或者NVL(字段, 兜底值)用来给空值兜底。后两个在很多版本里是等价的用哪个看你那边函数列表里有哪个。兜底值的选择也有讲究数值字段兜0文本字段兜空字符串日期字段不要硬兜因为日期兜一个假值比如 1970 年会污染时间序列分析宁可让它空着并用ISNULL单独标记。注意COUNT(字段)和COUNT(*)的区别就在这里。前者统计非空值的个数后者统计行数。算有手机号的客户数时要用前者算客户总数时要用后者或者COUNTD(客户ID)。用错了两个口径的差异能达到几十个百分点而且数字看起来都很合理不容易发现。5.3 除零保护和异常兜底除法是 BI 里最容易出问题的一类计算因为分母为 0 或者为NULL时有的版本返回NULL有的版本直接报错导致整个组件加载失败。保单写法是把分母包起来判断安全的比率计算 IF(ISNULL(分母) OR 分母 0, 0, 分子 / 分母)如果业务上分母为 0和分母为空需要区分展示比如一个显示 0%一个显示—就把兜底值分开写别统一兜成 0。因为这两件事的含义不一样一个是确实没有量一个是数据没采到。混在一起看会让人误判某个区域业绩为零实际只是那天没传数据。另外异常兜底不要过度。我见过有人给每个公式都套三层IF防错结果公式本身变成了一团乱麻真正出问题时根本没法定位。防错的重点应该放在分母、日期转换、类型转换这三个高危动作上其他地方的错就让它错报出来反而好查。6. 窗口类函数在明细和汇总之间来回跳6.1 三种排名口径的差别排名是 BI 里最日常的需求也是口径分歧最大的地方。三种常见口径并列名次且后续跳号1、1、3、并列名次且不跳号1、1、2、不并列直接按行编号1、2、3。同样一批数据三种口径出来的名次全不一样业务方说我们排第五你得先问清楚是哪种。口径出现并列时示例适用场景跳号排名同名次后续跳号1、1、3排行榜、竞赛名次不跳号排名同名次后续连号1、1、2分档、等级划分行编号不并列强行区分1、2、3取 TopN 明细行FineBI 里这类排名通常通过组件的快速计算→排名配置可以选跳号或不跳号。如果你的需求是取排名前三的产品用不跳号会得到可能超过三个的结果因为并列的都会被选进来用行编号则严格三个但并列的顺序是随机的翻页刷新可能变。这两种结果都能用关键是先跟需求方确认他要哪一种。6.2 分组占比与累计筛选器一动数字就变分组内占比和累计求和这类计算最容易踩的坑是它跟着当前视图走。你在组件里放了一个区域筛选器排名和占比就会在被筛选后的范围内重算看起来名次变了、占比超过 100% 了实际公式没错是计算范围变了。判断方法很简单把筛选器去掉看数字是否回到预期。如果回去了说明是范围问题不是公式问题。要固定范围就得用能锁维度的写法把计算范围显式声明出来而不是依赖组件当前的视图范围。这类固定维度的函数在 FineBI 里是DEF_ADD这一族第二个参数传维度列表传空表示全表。我的经验是把跟着视图走设成默认预期因为大多数交互式看板就是希望筛选后重算。只有当你需要全局占比或者全公司排名这种固定口径时才去锁维度而且要在组件标题或者备注里写清楚此指标为全局口径不受筛选影响不然一定有人来问为什么筛了区域之后占比没变。6.3 明细级参与汇总计算怎么组织最复杂的一类需求是每一行都要展示但每一行的值又依赖它所在分组的汇总。比如明细表里每个订单一行要同时显示订单金额、该客户的总金额、该订单占客户总额的比例。这三列的计算层级分别是明细、客户分组、两者相除。做法上订单金额就是原始字段客户总金额用SUM_AGG(订单金额)并按客户分组占比则是两者相除。这里的关键是SUM_AGG不会压缩行数所以明细行的数量保持不变。如果你用的是SUM整张表会被压成客户粒度订单行就没了。还有一层要注意SUM_AGG这类函数的计算是在组件渲染时做的数据量大十万行以上明细时会有明显性能损耗。我的处理是能预聚合就先预聚合把客户总额在数据集层算好存成一列组件里直接取比每次渲染都算一遍快得多。明细表超过五万行时这个优化基本是必须的。7. 三个可以直接抄的组合模板7.1 客户价值分层把连续金额切成档分层需求随处可见做法是先用明细级聚合算出每个客户的核心指标再用IF或分档逻辑切段。下面是按累计消费金额分四档的写法档位边界用业务定的实际值替换。客户分层金额单位元 IF(ISNULL(SUM_AGG(消费金额)), 未消费, IF(SUM_AGG(消费金额) 10000, 高价值, IF(SUM_AGG(消费金额) 3000, 中价值, IF(SUM_AGG(消费金额) 0, 低价值, 未消费))))写这类公式有两个细节值得注意。第一判断顺序必须从大到小或者从小到大单向走不能交叉否则某个区间的数据会被先命中的条件吃掉。第二边界值用还是要和业务确认尤其是刚好等于 3000这种卡在边界上的客户归到哪一档事后争论起来很费劲不如一开始就写进公式注释里。分层字段做完之后建议不要直接删掉中间的计算字段保留一列原始金额方便业务方核对。我踩过一次坑分层结果和财务的名单对不上查了半天发现是分层用的金额口径含不含运费和财务不一样但因为中间字段被删了只能从头重算一遍。7.2 一列搞定同比环比同比环比也可以用组件的快速计算直接出但如果要放在同一个表格里对比多个指标手写公式更灵活。核心思路是把本期和同期分别算出来再相除同期的取值靠日期偏移或者靠时间维表的关联。同比增长率同期口径 IF(ISNULL(同期销售额) OR 同期销售额 0, NULL, (本期销售额 - 同期销售额) / 同期销售额)分母为 0 时返回NULL而不是 0这是有意的增长率在基数为 0 时没有数学意义显示 0% 会误导人以为没增长显示空白或者—更诚实。这个取舍我在好几个项目里都坚持业务方一开始会问为什么这里是空的解释一次之后就都认可了。7.3 敏感字段的展示脱敏手机号、身份证号这类字段在明细表里直接展示是有风险的常见的处理是保留头尾、中间打码。用LEFT加RIGHT拼接就能做注意长度不足时要兜底别把短号也按固定位数截。手机号脱敏保留前3后4 IF(ISNULL(手机号) OR LEN(手机号) 7, —, CONCATENATE(LEFT(手机号, 3), ****, RIGHT(手机号, 4)))脱敏要在展示层做不要在数据集层把原值覆盖掉。原因很实际业务方迟早会需要原始号码去做回访覆盖掉之后就得重新接一次数据源。更好的做法是同一张表里同时保留原字段和脱敏字段原字段设权限只有特定角色可见脱敏字段给所有人看。8. 让这份清单不断更新下来的维护方法8.1 我给每条函数笔记定的固定格式清单能不能长期用下去取决于格式是否统一。我的模板是五栏函数名、一句话作用、最小可用写法、踩过的坑、验证数据。第三栏强制要求写成能直接复制粘贴的完整公式不要写参数填字段名这种废话因为真正需要抄的时候你根本不想再想一遍参数顺序。第四栏只写亲身遇到的不抄文档抄来的坑记不住。栏目内容示例填写要求函数名SPLIT写全名别名另起一行一句话作用按分隔符取第 N 段文本不超过 20 字最小写法SPLIT(地址, -, 2)可直接复制运行踩过的坑段数不足时返回原值不是空只写亲测过的验证数据京-沪-穗 / 京-沪 / 京至少三条边界样本这个格式最大的好处是逼着你去验证。填第五栏的时候你会发现很多你以为理所当然的行为其实没测过一测就露馅。我给每个函数都留了三条样本正常值、边界值、异常值。这三条样本本身也成了回归测试集版本升级或者公式改动之后跑一遍几分钟就能确认没问题。8.2 踩雷登记比函数清单更值钱的部分单独拉一张表记踩过的雷格式是现象、定位过程、根因、修复写法。这张表的价值比函数清单本身还高因为函数行为查文档总能查到而为什么这个报错看起来完全不相干只有踩过的人知道。举几个我记下来的典型一是文本型数字参与求和返回空现象是这个指标一片空白根因是字段类型被识别成文本修复是在数据集层改类型或者用转换函数强转二是明细表里出现每行都一样的值根因是用了SUM而不是SUM_AGG分析粒度被压缩了三是排名在刷新页面后变了根因是并列值的排序不稳定需要加一个唯一的次级排序字段。第三条特别值得说一句给排名加次级排序是个小动作但能解决刷新一次换一个结果这种让人怀疑人生的现象。次级排序字段选主键或者时间戳都行目的是让并列项之间有一个确定的先后这样每次渲染出来的顺序都是同一个。维护这件事没什么技巧就是顺手记。每次排查完一个公式问题花两分钟把现象和根因敲进表里三个月之后你会感谢当时的自己。我现在这份清单已经长到需要分页了但每次接手新的分析需求翻一遍就能找到七八成的参考答案比重新摸索快太多。最后分享一个小习惯每次改动公式把旧写法在注释里留一行写上改的原因和日期。半年后回头看那一行注释往往比公式本身更能帮你回忆起当时的业务背景。
