分析树，有个主要的特点：叶子节点有兄弟节点的是联表查询，其循环顺序对应从左往右，而无兄弟节点是单表查询。而最后的分析会落地到叶子节点的分析。遍历叶子节点时，有一条规则（不完整描述）是：
叶子节点有兄弟节点的，且是最左节点即第一层循环，且 where 子句中不含有相关常量条件表达式时，SCAN TABLE 不认为是质量问题。
这里有两个条件必须同时满足，SCAN TABLE 才不报问题：第一层循环 & 无相关常量表达式。第一层循环前面已经描述，这里再解释下后面一个条件。
由上看到,当select子句中出现常量条件表达式 “t4.id=666” , 若 t3.id,t4.id 都建了索引，是可以优化成没有 SCAN TABLE 。
而把 t4.id 的索引删除后，又出现了 SCAN TABLE 。而这种 SCAN TABLE 的情况，不满足规则里的的第二个条件，SQLiteLint 就会报出可以使用索引优化了。
这里介绍了一个较简单语句的查询计划的分析，当然还有更复杂的语句，还有子查询、组合等等，这里不展开讨论了。巨大的复杂性，无疑对准确率有很大的挑战，需要对分析规则不断地迭代完善。当前 SQLiteLint 的分析算法依然不足够严谨，还有很大的优化空间。 这里还有另一个思路去应对准确性的问题：对所有上报的问题，结合耗时、是否主线程、问题等级等信息，进行优先级排序。这个“曲线救国”来降低误报的策略也适用本文介绍的所有检测问题。
二、检测冗余索引问题SQLiteLint 会在应用启动后对所有的表检测一次是否存在冗余索引，并建议保留最大那个索引组合。
先定义什么是冗余索引：如对于某个表，如果索引组合 index1，index2 是另一个索引组合 index3 的前缀，那么一般情况下 index3 可以替代掉 index1 和 index2 的作用，所以 index1，index2 就冗余了。而多余的索引就会有多余的插入消耗和空间消耗，一般就建议只保留索引 index3 。 看个例子：
以上看到，如果已经有一个 length 和 type 的组合索引，就已经满足了单 length 列条件式的查询，没必要再为 length 再建一个索引。
三、检测 select * 问题SQLiteLint这里通过扫描 sql 语法树，若发现 select * 子句，就会报问题，建议尽量避免使用 select * ，而是按需 select 对应的列。
select * 是SQLite最常用的语句之一，也非常方便，为什么还认为是问题的呢？这里有必要辩驳一下：
对于 select * ，SQLite 底层依然存在一步把 * 展开成表的全部列。
select * 也减少了可以使用覆盖索引的机会。覆盖索引指索引包含的列已经覆盖了 select 所需要的列，而使用上覆盖索引就可以减少一次数据表的查询。
对于 Android 平台而言，select * 就会投射所有的列，那么每行结果占据的内存就会相对更大，那么 CursorWindow（缓冲区）的容纳条数就变少，那么 SQLiteQuery.fillWindow 的次数就可能变多，这也有一定的性能影响。
基于以上原因，出于 SQLiteLint 目标最佳实践的原则，这里依然报问题。
四、检测 Autoincrement 问题SQLiteLint 在应用启动后会检测一次所有表的创建语句，发现 AUTOINCREMENT 关键字，就会报问题，建议避免使用 Autoincrement 。
这里看下为什么要检测这个问题，下面引用 SQLite 的官方文档：
The AUTOINCREMENT keyword imposes extra CPU, memory, disk space, and disk I/O overhead and should be avoided if not strictly needed. It is usually not needed.
可以看出 Auto Increment 确实不是个好东西。 ps. 我这里补充说明一下 strictly needed 是什么是意思，也就是为什么它不必要。通常 AUTOINCREMENT 用于修饰 INTEGER PRIMARY KEY 列，后简称IPK 列。而 IPK 列等同于 rowid 别名，本身也具有自增属性，但会复用删除的 rowid 号。比如当前有 4 行，最大的rowid是 4，这时把第 4 行删掉，再插入一行，新插入行的 rowid 取值是比当前最大的 rowid 加 1，也就 3+1=4 ，所以复用了 rowid 号 4 。而如果加以 AUTOINCREMENT 修饰就是阻止了复用，在这个情况，rowid 号是 5 。也就是说，AUTOINCREMENT 可以保证了历史自增的唯一性，但对于客户端应用有多少这样的场景呢？
五、检测建议使用 prepared statementSQLiteLint 会以抽样的时机去检测这个问题，比如每 50 条执行语句，分析一次执行序列，如果发现连续执行次数超过一定阈值的相同的（当然实参可以不同）而未使用 prepared statement 的 sql 语句，就报问题，建议使用 prepared statement 优化。 如阈值是 3 ，那么连续执行下面的语句，就会报问题：
使用 prepared statement 优化的好处有两个：
对于相同（实参不同）的 sql 语句多次执行，会有性能提升
如果参数是不可信或不可控输入，还防止了注入问题
六、检测建议使用 without rowid 特性