本文參考自官方文檔。原文鏈接
大量數據部署對Salesforce的影響
當用戶需要在Salesforce中部署大量數據的時候，部署的過程往往會變慢。這時就需要架構師或開發者設計出更好的過程來提高大量數據的部署效率。
多租戶架構和元數據
Salesforce使用元數據驅動機制來實現多租戶架構。
不同於傳統的關系數據庫，Salesforce中對每個“租戶”系統內部的數據結構並沒有相對應的數據表。Salesforce中使用統一的數據結構來保存各個“租戶”系統內部數據結構的定義，這就是元數據。
Salesforce自己擁有一套通用的數據表，將所有“租戶”系統中的對象、字段、索引、數據、關系等作為元數據分別保存到相應的表中。
在某“租戶”系統運行時，Salesforce會從這套通用數據表中取出該“租戶”系統擁有的對象、字段等，動態編譯成一個虛擬的數據庫，其中只包含該“租戶”系統中的數據和結構。
通過這樣的機制，Salesforce可以高效的保存多租戶的內容（只使用一套數據結構），讓各個“租戶”的內容保持相互獨立，互不影響，易於修改（動態編譯數據結構）。
搜索機制
Salesforce中所有可搜索的數據都必須擁有索引。
在一條數據被創建之后，系統會自動將其中可以被搜索的內容（比如各種字符串數據）進行歸類索引。這個過程需要花費一定的時間，所以在記錄被創建以后可能無法馬上被搜索到。最長的等待時間可以達到15分鍾。
在執行搜索時，Salesforce會首先對這些索引進行搜索，然后使用諸如用戶權限、搜索數量限制等條件對於搜索結果進行過濾，創建一個結果集（result set）。結果集中保存的是最符合搜索條件的數據。最后Salesforce將結果集中對應的數據在數據庫中進行查詢，從而返回用戶需要的字段等信息。
大量數據相關機制和最佳實踐
Salesforce中針對大量數據處理設計了不同的機制來提高效率。
Force.com查詢優化器（Force.com Query Optimizer）
查詢優化器是Salesforce內置的工具，對於報表、列表視圖、SOQL查詢語句、搜索操作進行優化，計算出最優的搜索方式。
它會遵循以下幾點進行優化：
- 尋找最符合查詢語句的索引。如果查詢語句中擁有過濾條件，則過濾條件優先被考慮作為查詢的索引。
- 尋找最符合的數據表。
- 對被查詢的數據表進行排序，使得查詢的開銷盡可能小。
- 引用外鍵定義來創建最有效的聯合（JOIN）操作。
- 更新數據庫統計數據。
數據庫統計數據（Database Statistics）
數據庫統計數據是對於數據庫中數據的統計。基於數據的種類、數量，查詢操作可以選擇出最有效率的進行方式。
SOQL 和 SOSL 對比
SOQL 是類似於 SQL 的查詢語句，而 SOSL 是全文檢索查詢。
當我們確定被查詢的文本存在於某個字段中，使用 SOSL 的速度要優於 SOQL。
與此同時，在一個 Apex 事務（Transaction）的執行中，SOSL 查詢的記錄上限是2000，而 SOQL 是50000。
批量查詢方法
使用 Batch Apex 可以查詢高達50,000,000條記錄，但是它並不一定適合所有的情景。
使用 Bulk API 可以查詢多達 15GB 的數據，它們會保存在15個 1GB 的文件中。
Bulk API 的查詢超時時限是2分鍾。如果成功進行了查詢，但是在返回結果的過程中用時超過10分鍾，或者數據文件大小超過了 1GB，那么 Salesforce 會將當前的結果緩存起來，然后重試。當失敗15次以后，才會返回錯誤信息。
主鍵分塊（PK Chunking）查詢
主鍵分塊查詢是 Bulk API 提供的一個選項。
對於千萬級的數據，普通的查詢優化可能已經沒法將查詢結果限制在一定的數量范圍。這時，使用主鍵分塊會優化查詢。
每條數據都有主鍵，也就是ID，在整個系統中是唯一的值，也是索引字段。
使用主鍵分塊查詢，系統會自動將數據依據主鍵的值分塊，每塊包含的數據量默認是10萬條。用戶可以設置每塊的數據量，最大不超過25萬條。在分塊之后，系統會對每塊進行分別查詢，從而將本來很大的數據表分解成無數的小塊，同時進行查詢，提高了效率。
精簡數據表（Skinny Tables）
Salesforce中將所有對象的標准字段和自定義字段分別存儲於兩張表中。在對這些對象進行查詢操作的時候，就必須對這兩張表進行聯合（JOIN）操作。而聯合操作會提高查詢的開銷。為了提高這些效率，Salesforce引入了精簡數據表機制。
精簡數據表是一個單獨的表，其中存儲着若干標准或自定義字段的值，但並不包括被“軟刪除”的那些。精簡數據表相當於存儲了已經進行了聯合操作的字段和內容，從而可以更有效率地支持前台的查詢。
精簡數據表的一些特性：
- 一個精簡數據表最多可以包含100個字段（列）。
- 每一個精簡數據表都對應一個對象，所以其包含的字段必須屬於此對象，不能有其他對象的字段。與此同時，也不能有公式（formula）字段和查找（look up）字段。
- 精簡數據表會被拷貝到完整沙盒（Full sandbox）中，但不會被拷貝到其他類型的沙盒中。如果想要拷貝到其他類型的沙盒，必須通過Salesforce的客戶支持幫助。
- 精簡數據表必須要通過Salesforce的客戶支持來啟用。
索引字段
索引字段最多的被用於數據庫的查詢語句。Force.com的查詢優化器對於標准和自定義的索引字段有着不同的規定。
- 對於標准索引字段，查詢結果必須在前100萬條記錄中有少於30%的符合率，並且在余下最多100萬條記錄中有少於15%的符合率。否則該索引不會被查詢語句所使用。
- 對於自定義索引字段，查詢結果必須在所有記錄中有少於10%的符合率，查詢結果最多為333333條記錄。否則該索引不會被查詢語句所使用。
與此同時，Force.com的查詢優化器對WHERE語句中的AND、OR條件有着單獨的規定。
- 對於AND條件中使用的索引字段，其返回的查詢結果必須少於總記錄數的20%，並且不超過66666條。
- 所有在OR條件中使用的字段必須是索引字段。對於這些索引字段，其返回的查詢結果必須少於總記錄數的10%，並且不超過333333條。
SOQL和SOSL語句中的null值
在查詢語句中，要盡量避免在WHERE條件中判斷null值。
比如下面的查詢語句（偽代碼）：
SELECT Name FROM Account WHERE Account_ID__C = :acctid;
如果變量acctid為null，則整個Account表都會被搜索，嚴重降低了查詢效率。
可以改寫為：
if (acctid != null) {
SELECT Name FROM Account WHERE Account_ID__C = :acctid;
} else {
...
}
SOQL和SOSL語句中的公式字段
在查詢語句中，要盡量避免在WHERE條件中以公式字段（Formula）作為過濾條件。
這么做的原因是公式字段的值總是在被引用的時候即時計算的，並且在不經過 Salesforce 客服的幫助下是不能做索引的。所以如果以公式字段作為過濾條件，查詢的速度會非常慢。
查詢的最佳實踐原則
總結起來，進行數據查詢的最佳實踐原則有兩條：
- 為查詢語句增加過濾條件，從而使查詢過程涉及的數據盡可能少
- 讓系統內存在的有效數據盡可能少