@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 统计是业务有实时需求，没办法。

mysql 的查询优化器，会预估多种查询方式的成本，来生成最佳的查询计划，如果某个字段的辨识度不高，那么 mysql 优化器进行采样预估的时候，可能会认为使用索引的成本较高（采样失误可能原因：基数太小、采样小概率采集到一样的）转而进行全表扫描

一般数据库，不要出现 null 这种值，你应该限制这种值插入

非常感谢各位，我已经解决了。
我反编译了 apk 文件，查看了源代码，获取到了盐值

@CEBBCAT 我需要多提供什么资料？我把这个 API 接口的 安卓 APP 包发出来可以的吗？

在线等，急