本篇参考：
https://developer.salesforce.com/blogs/engineering/2012/04/avoid-account-data-skew-for-peak-performance.html
https://developer.salesforce.com/blogs/engineering/2012/06/architect-salesforce-record-ownership-skew-for-peak-performance-in-large-data-volume-environments.html
性能以及稳定性对于一个系统来说是至关重要的。 今天说的是数据Lookup倾斜我们在一个系统中，表和表的关系不可能是完全独立的存在，有关系就要创建其关联， lookup也好， MD也好。有些表作为主数据，数据量可能很庞大，Lookup数据倾斜简单的定义可以理解为，当一条记录有10K条同个表记录进行关联情况下，便会很影响性能，变成一个沉默的杀手，看不出来程序配置哪里有问题，但是可能出现崩溃或者性能堪忧的风险。
举几个例子更好的去理解一下：
符合 Lookup Data Skew
1. 一条顾客数据，绑定了超过10000的案件数据；
2. 一个自定义表，绑定了超过10000条他的子表的数据；
不符合 Lookup Data Skew
1. 一个user，拥有10000条记录。（之所以不属于原因是 要求同一个表，如果一个 user拥有10000条顾客或者案件记录则符合）
lookup skew通常可以分成三个类型：
- Account Data Skew：某些Salesforce对象，如Account和 Opportunity，在 sharing model 是private情况下，维护父子数据访问会有一个特殊的数据关系，如果同一个 account记录拥有太多的Opportunity记录，则容易产生 account data skew从而导致性能的风险；
- Ownership Skew：当一个user针对同一个表拥有超过10K的数据，在管理 role hierarchy 和 sharing rule场景下就很容易造成 ownership的倾斜
- Lookup Skew：当具有lookup关系的两个表，一个父表的数据如果关联了超过10K的这个子表的数据，则造成了 lookup skew。
上面的内容都是概念性描述，那么在我们实际场景中是否出现过因为lookup skew导致的问题呢，这样才能让我们能更好的知道为什么 lookup skew如此堪忧？
最常见的场景：unable_to_lock_row。根据salesforce 数据DML的原理，当一个子表进行DML（这里通常使用 insert / update）时，需要先锁定父表，然后进行子表的DML操作，当子表的记录操作完成，会解锁父表记录，然后下一条记录来了，锁定它这条记录的父表，然后进行相同的后续操作。
如果一个父表绑定了太多的同一个子表的数据，则容易造成 unable_to_lock_row的情况，这种事情偶发存在，可能重新执行就通过。客户出现这个问题，提case，作为开发人员修改也是很痛苦的事情。
针对这种情况如何去处理呢？大概有几种处理方式（不一定齐全，可以参看上方文档）
1. 针对 Account Data Skew尽量做到多建几个子 account，通过 parent account形成关联关系以后，将数据进行分发，从而减少每条account绑定的数量；
2. 针对 ownership skew，尽量做到user不存在 role或者在 role hierarchy最上层，这样在 role hierarchy变更情况下，不用有share的性能风险。
总结：Data Skew在设计上是一个很重要的一环，它会影响你的 sharing 性能以及系统稳定性。篇中只是简单介绍了概念以及常用情况的处理方式，具体的细节还请参看上方的文档。篇中有问题欢迎指出，有不懂欢迎留言。