本篇參考：
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 效能以及系統穩定性。篇中只是簡單介紹了概念以及常用情況的處理方式，具體的細節還請參看上方的文件。篇中有問題歡迎指出，有不懂歡迎留言。