这些数据库为什么不跟进新版本呢…诶…破玩意儿

Go 标准库很多 API 设计得都比较有特色。抛开 Go 不谈对于 HTTP 库一个典型设计是 response / body 都有独立的 close ，response 的关闭会导致 body 被连带关闭。

悲观锁定能不用就不用，看上去你不需要锁定啊，你只是需要确保记录更新的事务性而已，那为什么不调高事物隔离级别？此外看了下您这个触发器，似乎默认的 RC 级别已经够用了

我这的东西能被我换成 PostgreSQL 的都被我换成 PostgreSQL 了，MySQL 的各种蛋疼问题太麻烦了，糟糕的全文搜索，糟糕的 join ，糟糕的事物隔离，糟糕的数据类型（别的可以不提，就时间类型就够蛋疼），糟糕的排序（第一次见到排序内存不足会报错的）。其他高级特性就不说了，像递归 CTE 这种东西本来也很少用。

@utodea 看你的需求是什么，如果你的需求是 OIDC 开放互联，你就只能去读这些文档了。规格文档只会说要什么，到底怎么落地得自己想。

@annoygaga 正确实现 OAuth 2.0 ，你需要熟悉 IETF RFC 6749 6750 6819 ，这类平台一般还要实现 OIDC ，这部分规格不属于 IETF RFC ，但也有洋洋洒洒大几百页。这仅仅是开放互联的内容，尚未涉及到业务域，比如账号体系，授权认证体系等等。也不见得有多难，但是完全让你一个人做你可以估算估算自己要做多久。

有些不想自己针对这块造轮子，主项账号数据这个东西你说它重要吧，它确实重要，但是它往往和核心业务关系不大。至于难点，只能说业务上想把任何一个东西做好都难，无非就是你怎么定义“好”了。

看上去不同注册时间的号表现不一样

再注意下，数据序列化/反序列化

什么 gal 啊，第一次听说这样的

@xxfye MySQL 8.x 还没有并行查询能力吗？有点弱啊

你自己都说了 ClickHouse 需要跑 12s 才能完成的全表求和，你觉得大家的“轻轻松松”能是什么标准呢？反正面对一亿行全表统计，我个人视能在分钟内完成就是可以忍受的，到底是不是轻轻松松要看需求，如果数据再大一点，能完成而不因为各种内存空间不足报错就是可以忍受的。

@zzNucker 他这是全表扫描，索引并不能提供太多价值。

成功/失败作为鉴别子，如果出现在带内（响应体），将意味着响应体的形式受到限制，起码响应体得固定是个 JSON 了。而 HTTP 一般用法中并不鼓励这种行为，除非你仅以 HTTP 承载传输，在 HTTP 之上运行其它协议，这样也就不是 RESTful 了。代价是失去 HTTP 提供的特化功能。
失败信息一般是相对固定的报告，将具体表述，比如错误码、错误消息等写于带内并无不可。

我觉得 #6 说的没太大毛病，就是说的太绕，不熟悉的人难以理解。Go 的 slice 设计本来就是个大坑，是缺乏思考或者说设计上懒惰的直接体现。append 操作返回值的模糊性导致相当场合 append 只有 x=append(x, blah) 这一个用法。

出错时可以遵守 RFC 7807 Problem Details for HTTP APIs ，不喜欢用 URL 也可以自己塞一个供前端判定的枚举值

用户/业务触发错误 4XX ，服务端故障 5XX ，RESTful 就请遵守 HTTP 。不要搞 POST 200 然后里面塞个 30008 之类的事，喜欢这样干的去用 RPC over HTTP ，比如 JSONRPC 2.0 / gRPC

取决于实际情况，大部分情况下都倾向于设置，同时做好约束

单机搞定的话，PostgreSQL 。如果是大宽表低频率的分析，再考虑 ClickHouse 单机版这种事

装了监控软件不会让你干这种事的