“我的芋泥流心酥呢？！”行政小丽的尖叫像按了喇叭，从茶水间穿透到18楼的每一个工位——她昨天刚囤的“打工人精神ICU套餐”（芋泥酥+冰可乐+卤味花生），现在只剩个空盒子，盒底还沾着半块被捏碎的酥皮，像被踩扁的梦想。
瞬间，全公司的“零食难民”涌了过来：
程序猿老张举着空可乐罐跳脚：“我的零度！昨天熬夜改支付BUG，特意冰了三小时，罐身的水珠都能当镜子照，现在只剩个凉透的空壳！”
运营小美翻着健身包哭：“我的高蛋白威化！教练说‘吃这个不会胖’，我昨天才拆封，咬了一口留着今天当下午茶，现在连包装纸都没了！”
连平时端着“高管架子”的王总都凑过来，扶着金丝眼镜皱眉：“我的挂耳咖啡呢？早上刚从抽屉里拿出来，准备开战略会时冲，现在只剩个空袋子！”
那台贴着“拒绝躺平·零食续命”的粉色零食柜，此刻像被洗劫的便利店——薯片袋散在地上，可乐罐滚到墙角，连最不受欢迎的芥末海苔都被摸走了，只剩个标签纸在风里飘：“今日推荐：芋泥流心酥（小丽私藏）”。
“这是这周第三次！”小丽抹着眼泪，粉底在脸颊上蹭出两道白印，“上次偷零食的人没抓到，这次连王总的咖啡都敢动？”
这时，人群后冒出个穿格子衫、啃着火腿肠的小伙子——是IT部实习的小周，上周才帮小丽修好了打印机，现在抱着笔记本电脑，像个举着放大镜的福尔摩斯：“丽姐，我有办法。我用零食柜的刷卡日志做了个‘零食强度’算法——谁拿得多、拿得勤，谁就是‘零食大盗’！”
二、实习生的"破案黑科技"：用 SQL 给零食柜"录口供"
小周的算法特接地气，用他的话说：“就像判断谁是‘奶茶霸王’——你一天喝三杯，每杯隔一小时，那是爱喝；但你一小时喝三杯，那肯定是‘偷带回去给室友’。”
公式简单到能贴在零食柜上：
零食强度 = 总拿取重量（g）÷ 相邻拿取的平均间隔（分钟）
“举个例子，”他咬了口火腿肠（幸好这根藏在抽屉里没被偷），“要是有人10分钟拿3次，每次200g，强度就是60；要是有人1小时拿1次，拿300g，强度才5。前者是‘搬零食’，后者是‘正常吃’——毕竟，谁会饿到10分钟就啃完一包薯片？”
而他的“证据库”，是公司那台“半智能”零食柜——其实是小丽用旧门禁卡改造的，刷工牌才能开，每笔记录都记着：
| emp_id | ||
| name | ||
| snack | ||
| weight | ||
| time |
emp_id
：工号（正式工是“Z”开头，外包是“W”开头，像古代的“良民证”）；name
：姓名（比如“Z-老张”“W-阿杰”）；snack
：零食名称（芋泥酥/可乐/威化饼）；weight
：重量（g，比如一包芋泥酥120g）；time
：时间（精确到秒，比如“2023-11-13 20:15:47”）。
三、SQL“审案”：三步揪出“零食搬运工”
小周抱着电脑冲进IT部，登录公司的Hive集群（其实是运维大哥用三台二手服务器搭的，开机时风扇响得像拖拉机），指尖在键盘上翻飞——
第一步：用LAG函数抓“连环作案”的现行
要知道谁“拿得勤”，得先找相邻两次拿取的间隔。小周用LAG
窗口函数，给每个人的记录“绑上前一次的时间”，就像给小偷“画行踪轨迹”：
SELECT
name,
snack,
weight,
time,
-- 同一人按时间排序，取前一次拿取时间
LAG(time, 1) OVER (PARTITION BY name ORDERBYtime) AS prev_time,
-- 计算间隔（分钟）：时间戳转分钟
(unix_timestamp(time) - unix_timestamp(prev_time)) 60AS interval_mins
FROM company_snack_log;
运行结果弹出来时，小周的火腿肠差点掉在键盘上——W-阿杰的记录像按了“自动重复键”：
10分钟一次？这哪是“吃零食”，分明是“给零食柜‘清库存’”！
第二步：聚合算“总重量+平均间隔”——谁是“大胃王”？
光看间隔不够，得结合“总拿了多少”。小周用SUM
和AVG
统计核心数据，像给每个人算“零食GDP”：
SELECT
name,
SUM(weight) AS total_weight, -- 总重量（g）
AVG(interval_mins) AS avg_interval -- 平均间隔（分钟）
FROM (第一步的结果) t1
GROUPBY name;
结果出来，小周倒吸一口凉气——
W-阿杰：总重量630g（薯片+可乐+威化+芋泥酥），平均间隔10分钟；
Z-老张：总重量1500g（5罐可乐+3包薯片），平均间隔120分钟；
Z-小美：总重量600g（5包威化饼），平均间隔240分钟；
Z-王总：总重量480g（4包挂耳咖啡+2条能量棒），平均间隔60分钟。
第三步：算“零食强度”——锁定“偷食王者”
最后一步，用公式算出“谁的偷食效率最高”，像给零食柜“选劳模”：
SELECT
name,
total_weight,
avg_interval,
total_weight avg_interval AS snack_intensity -- 核心指标
FROM (第二步的结果) t2
ORDERBY snack_intensity DESC;
不出所料，阿杰的强度碾压全公司，像“零食界的苏炳添”：
四、真相：外包小伙的“饥饿辩护”比零食被盗更扎心
“这...这也太夸张了吧？”小丽盯着屏幕，“阿杰怎么拿这么多？”
王总立刻让保安调监控——画面里，阿杰穿着洗得发白的外包工服（公司给外包的工服是去年的旧款，领口都起球了），抱着个帆布包（上面印着“XX职高”的字样，他是职高毕业的，外包公司招他来做客服），20点到20点30分，连续四次走向零食柜：第一次拿薯片时，他犹豫了一下，选了最便宜的原味；第二次拿可乐，他看了眼价格标签（3元），咬咬牙拿了罐零度（无糖，更便宜）；第三次拿威化饼，他翻了翻，选了“临期促销”的那包；第四次看到芋泥酥，他盯着标签上的“小丽私藏”看了三秒，终于伸手拿了——因为他妹上周打电话说：“哥，我们学校食堂的芋泥酥要5块钱一个，我舍不得买。”
最后他掏出手机看了眼时间（20:35），啃着薯片，转身去客服部接晚班电话——他要加班到22点，每小时赚18块，够买两包芋泥酥。
五、公司的“双标公告”：比偷零食更恶心的是“身份滤镜”
当天下午，HR的公告贴在了公司门口的公示栏上，红底黑字，像张“通缉令”：
关于严格规范外包员工零食取用的通知
正式员工（Z开头工号）：按需取用，每日限额2000g（含饮料、零食）；
外包员工（W开头工号）：每日限取50g（仅可拿单价≤2元的零食），超出部分按市场价3倍赔偿；
严禁“批量拿取”（间隔<30分钟、单次>50g），违者立即终止外包合同并扣除当月工资。
下面还附了张“零食强度TOP1”的截图，阿杰的名字被红圈画得像个靶子，旁边写着：“外包员工违规典型：10分钟拿4次，严重占用公司资源”。
小周盯着公告，突然觉得喉咙发紧——
老张昨天拿了5罐可乐（1650g），说是“熬夜改BUG需要”，HR说“合理”；小美拿了5包威化饼（600g），说是“写方案饿了”，HR说“理解”；王总拿了4包挂耳咖啡（480g），说是“见客户来不及吃饭”，HR说“支持”；而阿杰拿了630g，就是“严重占用资源”？
六、最后：技术能破案，却破不了“身份歧视”
后来，小周把算法改了——给正式员工和外包员工设了一样的“强度阈值”，但运维大哥看了，摇摇头说：“没必要，正式员工是‘自己人’，外包是‘外人’。”
小周突然明白：技术能找出“谁拿了零食”，却找不出“为什么拿零食”；能算出“强度”，却算不出“生存的重量”；能揪出“外包偷食犯”，却治不了“公司的身份滤镜”。
就像阿杰说的：“我不是偷，我只是饿——饿到连给妹妹带包芋泥酥，都要被当成‘罪犯’。”
而公司的公告，不过是用“规则”包装的“恶”——正式员工的“贪心”，叫“工作需要”；外包员工的“生存”，叫“偷吃”。
公众号：会飞的一十六用SQL写尽职场荒唐，用段子戳破“高端职场”的遮羞布～ 关注我，下次带你用SQL算“老板的咖啡偷喝率”！😜
（本文根据真实事件改编，如有雷同，那你可能也在“双标公司”待过——毕竟，有些规则，比零食被盗更让人恶心。）
往期精彩
读者提问：缓慢变化维能进行维度退化吗？答案可能和你想的不一样
读者提问：如果维度退化或下沉的维度属性发生了变化，事实表该如何处理？
面试提问：数据开发中如何通过指标拆解来编写正确的SQL？（附拆解模板）
京东数据研发一面：用HiveSQL计算新用户近7日留存率（不允许使用JOIN）
