单纯的记录一个 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 实现如何困难，结果变成了需求沟通不一致。
文章首发于微信公众号：卡戎。
网友评论