Query Selectivity & Custom Indexes

好，同学，咱们今天聊一聊 SOQL 查询的性能优化里一个特别重要的概念——“选择性查询”。这个知识点，你尤其要注意，因为它跟触发器的性能直接挂钩，触发器里要是写了不高效的查询，那整个保存流程都会变慢。 那什么叫“选择性查询”呢？你记着一句话就够了：，一个好的查询，是要能用好索引，把返回的行数压到很低很低，。系统其实有个自己的判断标准，如果查询条件里用到的字段是索引字段，并且筛选出来的数据量低于系统定义的阈值——通常我们按经验记，就是小于总行数的 10%——那这个查询就认为是选择性的，它会走索引，速度很快。反过来，如果一下子要捞大量数据，比如匹配了超过 10% 的记录，系统可能就放弃用索引，直接全表扫描了，那样性能就糟了，尤其在触发器里更不能这么干。 那哪些字段天生就有索引呢？Salesforce 给你在下面这些字段上默认建好索引了，你直接拿来做筛选就容易拿到“选择性”： - ，主键，，也就是我们最常见的 Id。 - ，外键，，也就是查找关系字段，比如指向 Account 的 `AccountId`。 - ，审计日期字段，，比如 `CreatedDate` 和 `LastModifiedDate`。 - ，RecordTypeId，，也就是记录类型字段。 - ，外部 ID 字段， 和 ，设置了唯一性的自定义字段，。 所以你设计查询的时候，尽量让 `WHERE` 条件用上这些字段，并且让过滤后剩下的数据少，这是最佳实践。 那反过来，有哪些地方我们，不能，创建自定义索引，也很难指望那些字段做高性能筛选呢？记住这几个特殊的： - ，多选选择列表，，那种可以勾选多个值的字段，没办法建索引。 - 在多货币组织中的 ，货币字段，，因为要考虑汇率转换，所以也不行。 - ，长文本区，和，长文本区域，，类型是 `LongTextArea` 的，内容太长，没法支持索引。 - ，部分公式字段，，尤其是那些引用其他对象值，或能跨记录变化的公式，多半不能索引。 - ，二进制字段，，存文件、附件之类的字段，也不能建索引。 还有一个常见的坑，就是，操作符，。如果你在查询里用了负数逻辑，比如 `!=` 或者 `NOT LIKE`，这类“找不是这个值的记录”的写法，几乎用不上索引，因为数据分布太散了。还有 `CONTAINS`，如果匹配出来的行数很多，一样不会走索引。所以写查询的时候，你脑子里的那根弦得绷着：，尽量把条件写在索引字段上，争取让结果集控制在总数据的 10% 以内。， 你只要记住这一套规律——为什么有的字段快，哪些字段天生有优势，哪些字段和操作符要避坑，就能写出既干净又高性能的 SOQL 查询了。尤其是写到触发器里的时候，先想一想能不能用个索引字段快速定位到少量记录，这是咱们提升程序稳定性的基本功。 好，这节课就讲到这儿，回去你可以看看自己项目里的查询，有没有可以这样优化一下的地方，我们下次再继续。