HA 越用越慢？資料庫是頭號嫌疑犯

charles

裝了幾十個裝置之後，HA 開始變慢、SD 卡開始壞、備份越來越大。

八成是 recorder 的問題。



recorder 在做什麼

HA 預設會把「每一個實體的每一次狀態變化」寫進資料庫。

聽起來合理，直到你算一下：

1. 一個功率感測器，每 10 秒回報一次
2.   → 一天 8,640 筆
3.   → 一個月 259,200 筆
5. 五個這種感測器
6.   → 一個月 130 萬筆

複製代碼

再加上：

• 每個裝置的 LQI、電量、訊號強度
  
• 每個實體的所有屬性
  
• 所有自動化的觸發記錄
  

結果：

• 資料庫幾 GB
  
• HA 啟動要好幾分鐘
  
• 歷史記錄頁面卡住
  
• SD 卡被寫爆
  

先看你的資料庫多大

用 SQL 整合：

1. sensor:
2.   - platform: sql
3.     db_url: !secret db_url
4.     queries:
5.       - name: 資料庫大小
6.         query: >
7.           SELECT ROUND(page_count * page_size / 1024 / 1024, 1) as size
8.           FROM pragma_page_count(), pragma_page_size();
9.         column: size
10.         unit_of_measurement: MB

複製代碼

（這是 SQLite 的寫法。MariaDB 要用別的查詢。）

或者直接看檔案：

1. ls -lh /config/home-assistant_v2.db

複製代碼

參考值：

• 500MB 以下 —— 正常
  
• 1-2GB —— 偏大，該整理了
  
• 3GB 以上 —— 一定有問題
  

解法一：排除不需要的實體（最有效）

在 configuration.yaml：

1. recorder:
2.   purge_keep_days: 10
3.   commit_interval: 30
4.   exclude:
5.     domains:
6.       - device_tracker
7.       - automation
8.       - updater
9.       - sun
10.     entity_globs:
11.       - sensor.*_linkquality
12.       - sensor.*_rssi
13.       - sensor.*_signal_strength
14.       - sensor.*_uptime
15.       - sensor.*_last_seen
16.       - sensor.clock_*
17.     entities:
18.       - sensor.time
19.       - sensor.date
20.       - sensor.uptime

複製代碼

這一段通常能減少 50-70% 的資料量。

該排除什麼

• LQI、RSSI、訊號強度 —— 每次通訊都變，但你幾乎不看
  
• uptime、last_seen —— 一直在變
  
• sensor.time / sensor.date —— 每分鐘變一次，完全沒必要存
  
• device_tracker —— 資料量大
  
• 診斷類的實體
  

不要排除什麼

• 任何你要放進能源儀表板的
  
• 任何你要看歷史圖表的
  
• 任何自動化會用到「過去狀態」的
  

重要：exclude 和 include 不能混用

• 用 include 的話，沒列到的全部不記錄
  
• 用 exclude 的話，沒列到的全部都記錄
  
• 兩個同時用邏輯會很難懂
  

建議：只用 exclude（比較安全，不會漏掉重要的）。

解法二：調整保留天數

1. recorder:
2.   purge_keep_days: 10

複製代碼

預設就是 10 天。

• 調短（3-5 天）→ 資料庫小很多
  
• 調長（30 天）→ 可以看比較久的歷史，但會變大
  

關鍵的觀念：

「長期統計」是另一套機制，不受 purge_keep_days 影響。

• 有 state_class 的感測器會每五分鐘 / 每小時產生一筆統計
  
• 這些統計是永久保留的
  
• 能源儀表板、長期趨勢圖用的是這個
  

所以：purge_keep_days 設短一點不會讓你失去能源資料。



解法三：換資料庫引擎

預設是 SQLite

• 檔案式，不用額外服務
  
• 小型系統很夠用
  
• 但資料量大的時候會變慢
  

換成 MariaDB

• HA 有 MariaDB 附加元件，一鍵安裝
  
• 大資料量的效能好很多
  
• 支援並行查詢
  

設定：

1. recorder:
2.   db_url: mysql://homeassistant:密碼@core-mariadb/homeassistant?charset=utf8mb4

複製代碼

注意：

• 換資料庫之後歷史記錄會重來（不會自動搬移）
  
• 長期統計也會重來
  
• 所以要換就趁早
  

什麼時候該換：

• 實體超過 500 個
  
• 資料庫超過 2GB
  
• 歷史記錄頁面明顯卡
  

一般家庭（100-200 個實體）用 SQLite 完全沒問題。

解法四：減少寫入頻率

1. recorder:
2.   commit_interval: 30

複製代碼

預設是 1 秒 —— 每秒都在寫 SD 卡。

改成 30 秒：

• 寫入次數大幅減少
  
• SD 卡壽命延長
  
• 代價：斷電時最多損失 30 秒的資料
  

對家庭用途來說這個代價完全可以接受。

解法五：定期清理

手動清理：

• 開發者工具 → 動作
  
• 找 recorder.purge
  

1. action: recorder.purge
2. data:
3.   keep_days: 5
4.   repack: true

複製代碼

repack: true 很重要 ——
它會真的把檔案縮小（不然刪了資料檔案大小不變）。

注意：repack 會花幾分鐘，期間 HA 會很卡。

清理特定實體：

1. action: recorder.purge_entities
2. data:
3.   entity_id:
4.     - sensor.某個吃很兇的感測器
5.   keep_days: 0

複製代碼

資料庫以外的效能問題

一、自動化寫得太兇

• 監聽 all entities 的自動化
  
• 每分鐘觸發的 time_pattern
  
• 模板裡用了 states.sensor（會監聽所有 sensor）
  

檢查方法：

• 開發者工具 → 統計 → 看哪些實體更新最頻繁
  
• 設定 → 系統 → 日誌 看有沒有「自動化執行太久」的警告
  

二、模板感測器太多

每個模板感測器都會監聽它引用的所有實體。

寫法的差別很大：

1. # 差：會監聽所有 sensor 實體
2. {{ states.sensor | selectattr(...) | list | count }}
4. # 好：只監聽這三個
5. {{ [states('sensor.a'), states('sensor.b'), states('sensor.c')]
6.    | select('eq', 'on') | list | count }}

複製代碼

三、整合本身很吃資源

• 看設定 → 系統 → 修復 有沒有警告
  
• 某些整合的輪詢間隔可以調
  
• 攝影機的整合特別吃資源
  

四、硬體不夠

• 樹莓派 3 跑現在的 HA 會很吃力
  
• 樹莓派 4 / 5 或 N100 迷你主機比較舒服
  
• 記憶體至少 4GB（要跑 Node-RED、Z2M、資料庫的話 8GB）
  

一個實用的診斷自動化

1. template:
2.   - sensor:
3.       - name: 資料庫大小
4.         unit_of_measurement: MB
5.         state: >
6.           {{ (states('sensor.db_size') | float(0)) | round(0) }}
8. automation:
9.   - alias: 資料庫太大提醒
10.     triggers:
11.       - trigger: numeric_state
12.         entity_id: sensor.資料庫大小
13.         above: 2000
14.     actions:
15.       - action: persistent_notification.create
16.         data:
17.           title: 資料庫超過 2GB
18.           message: 該檢查 recorder 設定了

複製代碼

建議的起手式

如果你什麼都還沒調，先做這三件事：

• 排除 linkquality、rssi、uptime、sensor.time
  
• commit_interval 設成 30
  
• 跑一次 recorder.purge 加 repack: true
  

這三件事通常能讓資料庫縮一半以上，而且五分鐘就做完。

---

下一篇：一個完整的專案 ——
從零做一套浴室的智慧通風系統，含所有程式碼。