个人看法，其实我觉得大家说的两种都没有问题，关键有两点：1 、该项目主要由谁来制定标准，该标准是否在各个客户端兼容性良好。2 、风格要统一。
什么是风格要统一呢？就是比如：你这个项目，数据结构用的是第一种，那就从头到尾都用第一种风格；用第二种亦是如此。
满足了这两点，我觉得前后端沟通成本就能有效降低，达成共识后，双方也就不再会纠结，这个接口怎么返回这种，那个接口怎么返回那种。

那么说下，既然风格统一有这么多好处，还会出现多风格的接口呢？出现这个往往都是有历史原因，经手人比较多，后来的人，不够了解前人的风格和做法，最后就造成了这种局面。
如果你看不惯目前的局面，要坚持自己的标准，那么请统一它、重构它。请问你做好这样的决心了吗？没有的话，请不要吐槽它，因为你自己也并不想花时间去改造它

@hyd8323268 如果你需求一定要时间排序的话，我觉得你可以试试，给时间戳建立索引，然后使用微秒级时间戳，看下这样能不能避免时间戳太多重复的情况？这个就要看你业务了

请问你是执行 select 字段 from 表名 order by 时间戳 desc,id asc limit 0,10; 的时候慢，还是获取表的总行数的时候慢？可以提供你的具体分页需求吗？是只做下一页，还是需要做页码的？
就我所知，千万级，select 字段 from 表名 order by 时间戳 desc,id asc limit 0,10; 的效率还是能接受的

php7.2，mariadb10.12 ，不想升级 7.2 以上了，感觉没有必要去趟坑

@ZRS 连接上之后是一样，但是多台服务器的时候，xshell 界面切换非常方便

@liuxu 我尝试创建了不同长度的 int，从表面看起来，他们没有任何区别，长度 1 的，实际上也能存储 1111111111 这样的数字，那么对于 int 来说长度约束，是不是没有作用的呢？

@joyeu 索引是 （ username+type+number 和 username+type ）

@joyeu 抱歉，结果搞反了，是（ 0.034s 和 0.11s ）

@joyeu 就我自己的业务情况而言，我刚才做了查询时间测试，（ username+type+number 和 username+number ）的查询时间平均为（ 0.11s 和 0.034s ）

@joyeu 不是的，两个情况我都用 EXPLAIN 测试过了，只有加上 number 的时候，会出现 Using index 提示

@joyeu 另外想说的是，复合索引加上 number 字段，又会增加索引维护的成本，至于是维护成本高了，还是节省的查询时间多，就需要自己根据业务去具体考量了，所以说这个没有唯一的标准，适合自己的才是最好的

@joyeu 我刚用 EXPLAIN 测试了一下，单独给 number 建立索引是没有用的，还是需要回表，如果在复合索引里加上，是有效果的，username+type+number，这时候 Extra 给出的信息是 Using index，说明进行了索引覆盖。
但是我试到的查询时间的差别微乎其微，我猜想是：username+type 索引从大量数据中筛选出的数据量已经很小了，然后回表操作查询具体数据，花不了多少时间。
虽然差别小，但这确实是更优的选择，因为你不保证你以后会不会出现：username+type 筛选后，数据量仍然很多的情况

@sansanhehe 请问下，如果要实现 number 触发索引覆盖的话，单独给 number 建立索引是不是无效的？必须要建立复合索引（ username+type+number 或者 username+number ）？

@bbao 嗯，我刚才试了一下，username+type 的复合索引，效果非常好

@liuzhedash 如果 number 有索引的话，就不需要回表了，会直接进行索引覆盖

@liuzhedash 不是这样的哦，如果 number 没有索引，我觉得：通过 username 和 type 索引检索出来的数据，只包含了主键信息，这时候需要回表查询 number 的值，然后进行聚合统计。

@Jooooooooo 数据库的话，我用的是最新版的 MariDB，
type 字段的话，我觉得你说的对，我也觉得 type 的辨识度不高，这个字段类型，总共就只有 4 种。
用 sum 统计是业务有实时需求，没办法。