真實世界的 Rails 實戰（三）：ActiveRecord 效能優化三大絕招

基礎打好：資料庫設計不馬虎

• 索引：大表、非 ID 查詢欄位必建索引。用 Migration 建立：add_index :members, :email。
• 非空約束：預設欄位可為 NULL，需顯式 :null => false。
• 欄位長度：預設 varchar(255) 過大，依業務限制縮減（如 :limit => 10）。
• 靜態頁面快取：優先考慮頁面/片段快取，回報率高於查詢優化。

殺手鐧一：解決 N+1 查詢問題 — Eager Loading

預設關聯載入懶惰。範例：Member.find([1,2,3]).each { |m| puts m.address.city } 產生 1+3=4 條 SQL。

加入 :include => :address：

Member.find([1,2,3], :include => :address).each { |m| puts m.address.city }

單條 SQL 完成 LEFT OUTER JOIN，效能大幅提升。支援一層巢狀 :include => { :contacts => :address }。

殺手鐧二：繼承模型的替代方案 — 多態關聯

單表繼承 (STI) 導致寬表、空值多、不適用於差異大的子類型 (如 Cause、Gift、Nonprofit)。

改用多態關聯：

class Cause < ActiveRecord::Base
  has_one :content_base, :as => :displayable, :dependent => :destroy
end

class ContentBase < ActiveRecord::Base
  belongs_to :displayable, :polymorphic => true
end

Migration：t.string :displayable_type; t.integer :displayable_id。優點：共用邏輯集中於 ContentBase，各子類型表結構獨立，避免寬表問題。缺點：無資料庫層級外鍵約束，工具難自動識別關聯。

殺手鐧三：報表與複雜查詢 — 繞過 ActiveRecord 直連 SQL

需跨多表、複雜聚合時，直接使用 ActiveRecord::Base.connection.execute("SELECT ...") 或資料庫 View，避免 ActiveRecord 物件建立開銷。

總結

1. 索引、約束、欄位長度 — 資料庫基礎建設。
2. :include Eager Loading — 消除 N+1。
3. 多態關聯替代 STI — 彈性建模。
4. 複雜報表直寫 SQL — 實用主義。

ActiveRecord 功能強大，但必須理解其生成的 SQL，適時調整策略，才能構建可擴展、高效能的 Rails 系統。