SQLite参数化SubStr函数参数无法命中索引问题咨询

SQLite执行查询的逻辑是：先对SQL语句做预编译、生成执行计划（这一步就会确定是否走索引、走哪个索引），之后才会完成参数绑定、执行查询。
SQLite对表达式索引的匹配规则非常严格：只有WHERE子句中的函数表达式和索引定义的表达式，在结构、常量参数上完全一致时，优化器才会选择该索引。
你创建的索引是固定参数的SubStr(MyString, 1, 5)表达式索引，硬编码查询时WHERE子句的SubStr参数和索引定义完全匹配，因此可以正常命中索引。当你把SubStr的第二个参数替换为绑定变量@param1时，预编译阶段参数值尚未传入，优化器无法判定带变量的SubStr表达式与索引上的固定表达式等价，因此不会选择走索引，35GB规模的表触发全表扫描后自然会出现查询长时间无返回的问题。

• 有限枚举偏移量场景：动态拼接校验后的常量值
  如果业务中子串的起始偏移量只有少数固定取值（比如1、2、3这类有限枚举），先为每个偏移量创建对应的表达式索引。代码生成SQL时，先对传入的偏移值做严格的整数类型校验、合法范围校验（必须是正整数，且不超过字段最大长度），校验通过后直接把整数值拼接到SubStr的参数位置，不通过绑定变量传入。这种写法生成的SQL表达式和索引定义完全匹配，可以正常命中索引，且拼接的是经过校验的数值，不存在SQL注入风险。
• 偏移量取值范围大的场景：预计算子串存为独立列
  如果起始偏移量取值范围大，无法提前为所有取值创建表达式索引，直接调整表结构：在数据插入、更新环节提前计算好需要查询的子串值，存入独立的普通字段，给该字段创建普通B树索引。查询时直接对这个预计算字段做等值匹配即可，不需要在SQL中调用SubStr函数，可稳定命中索引，查询性能比表达式索引更稳定。
• 不想调整表结构的场景：应用层重写SQL替换参数
  在数据访问层增加SQL重写逻辑：拿到传入的@param1参数值后，先完成严格的类型校验、范围校验，校验通过后直接把SQL语句中的@param1占位符替换为对应的字面量数值，再交给SQLite预编译执行。此时预编译阶段SubStr的参数为固定常量，和原有索引定义匹配，即可命中已创建的s01索引。

注意：所有直接替换到SQL语句中的值必须经过严格的类型、范围校验，禁止直接拼接未校验的用户输入，避免SQL注入风险。

内容的提问来源于stack exchange，提问作者robert5722