Salesforce 大数据量处理篇（二）Index

本篇参考：

https://developer.salesforce.com/docs/atlas.en-us.202.0.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_indexes.htm

https://baike.baidu.com/item/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%B4%A2%E5%BC%95/8751686?fr=aladdin

https://help.salesforce.com/articleView?id=000325257&type=1&mode=1

https://help.salesforce.com/articleView?id=000334796&type=1&mode=1

https://developer.salesforce.com/blogs/engineering/2013/09/collecting-selectivity-statistics-for-force-com-queries.html

咱们在作项目得时候，一般会有需求是根据不少入力条件进行SOQL查询，而后展现 List。好多程序最开始跑的是没有问题得，当数据达到必定数据量好比百万级别之后，可能特别慢，或者更很差的状况下，直接崩溃了。针对这种状况有不少种可能状况致使，其中最多见的一种状况是：你当前的SOQL 语句不是selective的，或者是selective的状况下没有达到最大的优化。那什么样的SOQL语句是selective的，有什么定义或者特色去区分，如何去更好的优化SOQL呢？接下来的内容就抛砖引玉，引出相关的话题。

一. selective的SOQL语句

咱们想肯定一个SOQL是否为selective的，当前SOQL应该具备如下的特征：

1. where后面的filter的字段应该最少有一个索引字段（字段应该是 indexed的）。索引字段的概念咱们后面会单独做为一个部分来说；

2. 若是filter的字段包含了索引字段，咱们将肯定一下当前的SOQL返回了多少条数据。针对返回的数据的条数，咱们须要看当前的索引字段是标准的索引仍是自定义索引。对于标准索引，阈值是第一个百万目标记录的30%，以及第一个百万目标记录以后全部记录的15%。此外，标准索引的选择性阈值最大为100万条总目标记录，只有在总记录数超过560万条时才能达到。对于自定义索引，选择性阈值为第一个百万目标记录的10%，以及第一个百万目标记录以后全部记录的5%。此外，自定义索引的，只有在这个表记录数超过5，6百万条的状况下，选择性阈值最大为333333条目标记录被认为是selective的。

（注：阈值咱们能够理解成临界值，即当前的SOQL语句在当前系统经过当前 filter能查询出来的最大值）

举个例子。咱们搜索一个自定义表，目前数据量有30万条，由于他是100万条之内，因此若是使用了标准的索引，阈值 = 300000 * 30% = 90000条，也就是说当查询的SQL返回的数据若是使用标准索引只要返回的数量在90000条之内，就表明当前的SOQL是selective的。针对自定义要求是10% * 300000 = 30000条，即返回数据在这个之内表明当前的数据是selective的。

因此一言以蔽之，selective的SOQL的语句具有的特性有两个： 1. filter包含 索引字段；2.查询出来的数据知足当前要求的阈值。只有当前的SOQL是selective的状况下，咱们才可使用工具去进行优化。什么工具呢？看下面。

二. Query Plan Tool

概念和使用暂且不提，先看一下Query Plan Tool如何启用以及在哪里。咱们打开 develop console，点击menu部分的help,选择 Preferences，而后弹出的地方咱们即可以看到针对 Enable Query Plan的设置，默认就是true表明已经启用，这样咱们在下面的 Query Editor中输入相关的SOQL之后，即可以使用 Query Plan Tool来了解官方对当前的SOQL的建议了。

使用Query Plan Tool用于SOQL运行缓慢的检测以及优化建议，因此不是全部的场景都须要了解他，当你的数据量特别大，当前SOQL运行特别缓慢，使用它。不然了解这个概念和工具就好。

咱们先写一个SQL看一下效果。下图为使用 Query Plan的效果图。包含两个大部分，上面的列表（Plan List）以及下面的Notes部分。

 咱们看到每一个Plan里面都会包括 Cardinality / Fields / Leading Operation Type / Cost / sObject Cardinality / sObject Type。这些列什么含义，如何去理解？

• Cardinality（基数）：使用 Leading Operation Type操做方式状况下，预估的返回的数据条数；
• Fields：查询优化器(Query Optimizer)中使用的索引字段。若是 Leading Operation Type是 索引的，则当前的列将会展现索引字段，若是是全表扫描的模式，则当前的这个列将展现空；
• Leading Operation Type：Salesforce将用于优化查询的主要操做类型。这里有4个值：

1. 1. Index：当前查询的对象使用索引进行查询；
   2. Sharing：当前的查询将会使用索引进行查询。当前的索引基于当前执行SQL的人的共享规则来决定的。若是有 sharing rule限制了user能够访问的记录状况下，salesforce能够根据这些共享规则去进行优化；
   3. TableScan：当前的查询方式为查询当前表的全部数据；
   4. Other：salesforce将使用内部的优化方式去查询。

• Cost：与Force.com查询优化器的选择性阈值相比，查询的成本。 若是这个值大于1表示查询不会是selective的。
• sObject Cardinality：查询当前对象大概的记录数；
• sObject Type：当前查询表的 object的名字。

以上的就是关于查询的Plan表的各个列的名词解释。下图附上一张 Cost超过1的状况，由于查询的 filter没有索引字段，因此查询非 selective，cost超过了1.

咱们经过Notes等信息以及上面的表格即可以查看到对SOQL进行优化建议。细节得 Query Plan Tool介绍咱们能够查看上方得连接中官方描述得文档。上面咱们提到了 selective的SOQL必须是包含索引字段，那么在salesforce的世界里面哪些是索引字段，怎么设置索引字段呢？？？

三. Index（索引）

索引这个概念不止针对salesforce的SOQL，其余的相似SQL server以及 Oracle都有索引的概念，查询的filter中经过索引字段能够加快查询的速度。具体的索引的含义也能够查看上面的百度百科的文档。Salesforce针对索引字段有标准和自定义两种。咱们如何知道当前哪些字段是索引字段呢？只须要进入field中，查看Indexed这列信息便可，下图展现Account表中的一些索引字段的截图。

 1. 标准索引字段

salesforce针对几乎全部的表的如下字段维护了索引。分别是：RecordTypeId 、 Division、 CreatedDate、Systemmodstamp (LastModifiedDate)、Name、Email (for contacts and leads)、Foreign key relationships (lookups and master-detail)、Salesforce记录得 Record Id。也就是说表中的这些的字段，salesforce大部分已经自行维护了索引字段用来优化查询，无需在进行设置索引。

2. 自定义索引字段

固然，一个项目不可能只使用标准字段，咱们仍是须要建立自定义字段去实现相关得自定义逻辑。针对自定义字段一样能够设置成索引字段。固然不是全部得类型均可以设置索引字段，如下得类型salesforce不支持设置索引字段：multi-select picklists / text area (long) / text area (rich) / non-deterministic formula fields / encrypted text。编辑字段之后，勾选external Id外键之后，便成了被标记成索引得字段。外键仅能够Auto Number / Email / Number / Text类型中建立。固然，凡事不是那么绝对，若是须要在其余得字段类型中建立自定义得索引字段，包括标准字段，能够联系salesforce得support人员，他们能够进行设置。

上面有一个描述是non-deterministic formula fields不支持建立索引字段得，并非表明formula不支持索引，只是部分状况不支持。上方得index文档中有具体描述，感兴趣自行查看。

这里扩充两个对大量数据的SOQL比较灾难的两个filter，又经常是咱们常常用到的。一个是使用 formula字段进行 filter，一个是使用 null 进行filter。怎么样，项目上使用的是否是很常见？数据量少的时候OK，当真正数据量达到必定程度，你会发现这两种都是灾难性的。由于这两个默认的都是不带索引的！！！若是项目中遇到了这两种使用在filter中，而且数据量很庞大，找salesforce提support设置索引，salesforce能够针对 null单独设置索引。好比咱们针对某个自定义字段 XX__c设置了 index，咱们的SOQL ： 

select Id,Name from Account where XX__c = null

即便XX__c是索引字段也不行，须要额外的联系salesforce，将这个字段设置显示的 index用来支持null索引。

总结：当咱们运行得SOQL随着数据量增长而变缓慢或者超时等错误状况下，咱们可使用 Query Plan Tool去查看是否有优化得解决方案。了解哪些类型能够进行索引设置，掌握哪些条件能够知足一个SOQL是 selective。针对上面得各个点讲的都很浅，感兴趣得查看上方提供得各个官方得文档以便更深刻学习。篇中有错误欢迎指出，有不懂欢迎留言。