今天在检查线上数据时，发现一个问题，用户购买出行宝支付成功，也收到了支付成功的回调，但是用户看到的结果居然是购买失败，支付也是超时的，之后就开始检查到底是哪里出问题了，把用户的流程全部走一遍，包括支付的成功与回调时间，发现回调时间是在支付的10s 之内，说明支付没有问题，那么哪里出问题了呢？一时也看不出问题，就想着先给用户退款了，其他事情可以慢慢查。
之后就给设置退款，发现退款失败，再去找日志，发现是数据库字段长度设置太短了，也是醉了，设计时都没计划到还会存在这种情况，设计数据库应该尽可能地包含最多的意外情况：
- 系统状态位可以设置为 tinyint
- 一般的购买次数这样的，可以为smallint
设计时对以后的数据表的数据量要的大致的估计，不能再有类似的问题，现在量级还比较小，一旦大起来，那肯定还要考虑其他问题
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
