这里看到已经是使用索引来 SEARCH TABLE ，避免了全表扫描。但值得注意的是并不是所有 like 的情况都可以这样优化，如 like '%lo' 或 like '%lo%' ，不等式就做不到了。
再看个位操作导致索引不生效的例子：
位操作是最常见的导致索引不生效的语句之一。但有些时候也是有些技巧的利用上索引的，假如这个 case 里 flag 的业务取值只有 0x1，0x2，0x4，0x8 ，那么这条语句就可以通过穷举值的方式等效：
以上看到，把位操作转成 in 穷举就能利用索引了。
解决这类索引未生效导致的全表扫描 的问题，需要结合实际业务好好优化sql语句，甚至使用一些比较trick的技巧。也有可能没办法优化，这时需要添加到白名单。
3. 不必要的临时建树排序（对应查询计划的 USE TEMP B-TREE... )。
比如sql语句中 order by 、distinct 、group by 等就有可能引起对结果集临时额外建树排序，当然很多情况都是可以通过建立恰当的索引去优化的。举个例子：
以上看到，即便id和mark都分别建立了索引，即便只需要一行结果，依然会引起重新建树排序（ USE TEMP B-TREE FOR ORDER BY ）。当然这个case非常简单，不过如果对 SQLite 的索引不熟悉或者开发时松懈了，确实很容易发生这样的问题。同样这个问题也很容易优化:
这样就避免了重新建树排序，这对于数据量大的表查询，优化效果是立竿见影的好。
解决这类问题，一般就是建立合适的索引。
4. 不足够的索引组合
这个主要指已经建立了索引，但索引组合的列并没有覆盖足够 where 子句的条件式中的列。SQLiteLint 检测出这种问题，建议先关注该 sql 语句是否有性能问题，再决定是否建立一个更长的索引。举个例子：
以上看到，确实是利用了索引 genderIndex 来查询，但看到where子句里还有一个 mark=60 的条件，所以还有一次遍历判断操作才能得到最终需要的结果集。尤其对于这个 case，gender 也就是性别，那么最多 3 种情况，这个时候单独的 gender 索引的优化效果的已经不明显了。而同样，优化也是很容易的：
解决这类问题，一般就是建立一个更大的组合索引。
5. 怎么降低误报
现在看到 SQLiteLint 主要根据查询计划的某些关键字去发现这些问题，但SQLite支持的查询语法是非常复杂的，而对应的查询计划也是无穷变化的。所以对查询计划自动且正确的分析，不是一件容易的事。SQLiteLint 很大的功夫也在这件事情上
所以对查询计划自动且正确的分析，不是一件容易的事。SQLiteLint 很大的功夫也在这件事情上。SQLiteLint 这里主要对输出的查询计划重新构建了一棵有一定的特点的分析树，并结合sql语句的语法树，依据一定的算法及规则进行分析检测。建分析树的过程会使用到每条查询计划前面如 "0|1|0" 的数字，这里不具体展开了。 举个例子：是不是所有带有 "SCAN TABLE" 前缀的查询计划，都认为是需要优化的呢？明显不是。具体看个 case ：
这是一个联表查询，在 SQLite 的实现里一般就是嵌套循环。在这个语句中里， t3.id 列建了索引，并且在第二层循环中用上了，但第一层循环的 SCAN TABLE是无法优化的。比如尝试给t4的id列也建立索引：
可以看出,依然无法避免 SCAN TABLE 。对于这种 SCAN TABLE 无法优化的情况，SQLiteLint 不应该误报。前面提到，会对查询计划组织成树的结构。比如对于这个 case ，最后构建的查询计划分析树为：
