单纯的记录一个 sql 语句的修改过程。
- 业务场景
运营后台需要对用户金币变动信息按照时间段(以天为最小单位)统计查询。
- 数据表抽象
id(记录数据唯一标识,主键,
account(用户登录唯一标识)
cost(单日金币变动汇总)
type(变动类型,收入和支出)
vip(记录当前的 vip 等级)
date(当天变动的最新时间)
- 特殊说明
一个用户一天最多两条记录汇总,一个收入一个支出,数据是现成。
第一个版本
select id,account,cost,type,vip,date from xxx where xxx(具体时间条件)
最原始的版本就出来,当然 where 后面的语句耗费了大量的时间构建。时间条件是核心,要满足运营的查询需求,这里不做过多描述,根据各自业务需求来确定。
重新理解需求
发布测试版本,产品很快找到我说效果不对,重新给我仔细讲解了一遍新的需求。
是对一段时间内用户金币变更记录汇总,即一个用户(account)只能出现一次,对该用户这个时间段内的所有 cost 按照查询条件(时间和变动类型 type)汇总。
第二个版本
select id,account,sum(cost) as cost,vip,date from xxx where xxx group by account
测试版本发布,测试说:「vip 等级不对。」汇总记录的 vip 等级不是最新的 vip 等级。做过的应该都知道,这种日志记录一般都是记录当时的用户状态,后续新增记录也不会修改以前的记录状态。
经过和产品认(斗)真(智)沟(斗)通(勇),最后妥协的方案就是 vip 等级显示为查询时间段内的最新等级。举个例子:2018.1.1-2018.2.28,显示就是时间段内最新记录的 vip 等级,28 号有就显示 28号,27 号有就显示 27 号(因为业务原因,不能从 vip 等级表里面查询最新的等级)。
最终版本
网上一搜,发现 last() 这么一个函数,可以直接获取最新的记录。
select id,account,sum(cost) as cost,last(vip),date from xxx where xxx group by account
毫无疑问的报错了,因为 MySQL 不支持这个函数。经过大量搜索后,发现对此都没有很好的解决方案,大部分都不适用我当前的业务场景。曾经一度想在业务层进行聚合,但是复杂的业务使我放弃这个更加不靠谱的决定。
最终找到了这么一篇文章「First() and Last() in mySql」,里面的思路给我我很大的启发。
select id,account,sum(cost) as cost,vip,max(date) as date from xxx where xxx group by account
这就是最终版本的 sql 语句,算是一种取巧手段,其实这里使用 max(id) 更加合适。
回顾总结
作为一个合格的开发人员,应该正确的理解需求,遇见需求不明确的时候,应该多和产品沟通,确保自己所做的和目标需求一致。自己 sql 基础薄弱,这方面需要多多弥补。
写到最后,发现这次文章写偏了,本来应该是讲这个 sql 实现如何困难,结果变成了需求沟通不一致。
本文首发于微信公众号:卡戎,欢迎关注。