HA 變慢、歷史頁面要轉好幾秒？十分鐘的資料庫急救三步驟

charles

這篇的內容（14 段）

1. 背景：為什麼它會長大
2. 2-1 裝它
3. 2-2 跑查詢
4. 4-1 找到設定檔
5. 4-2 加上 recorder 區塊
6. 4-3 檢查語法再重啟
7. 步驟 6：驗證（一分鐘）
8. 6-1 看數字
9. 6-2 看速度
10. 6-3 確認長期資料還在
11. 三件不要做的事
12. 不要 3：不要急著換 MariaDB
13. 接下來會自己維持嗎
14. 十分鐘檢查表

這一篇是急救，不是調校。目標很窄：十分鐘之內讓你量出資料庫現在多大、找出誰在狂寫、把空間拿回來，而且每一步都有一個可以自己看的數字。不需要會 SQL，不需要 SSH。



先確認你的症狀是不是資料庫造成的

三個都中，八成就是：

• 點側邊欄的歷史之後要轉好幾秒才出現圖
  
• 重新啟動 Home Assistant 的時間比以前長很多
  
• 每天的自動備份檔案變得很大（幾百 MB 以上）
  

只有儀表板卡住、歷史很快 → 那是前端或某個整合的問題，不是資料庫，這一篇幫不了你。

背景：為什麼它會長大

Home Assistant 有一個叫 recorder 的元件，預設會把每一個實體的每一次狀態變化寫進一個 SQLite 檔案（home-assistant_v2.db，放在設定目錄裡）。

預設保留 10 天，每晚 04:12 自動清理一次。聽起來很安全 —— 問題出在「每一次變化」這五個字。一顆每 5 秒回報一次的電表，一天就是 17,280 筆；十天就是十七萬筆。而這種感測器一個家裡常常有二三十個。

⚠ 一件要先講清楚的事：清理不會刪掉你的長期統計。 有 state_class 屬性的實體（電量、能源、溫度那些）除了明細之外還會另外存一份每小時一筆的長期統計，而那一份是永久保留的，不受保留天數影響。所以能源頁面上去年的用電量不會因為下面這些動作而消失。

步驟 1：量出它現在多大（三分鐘）

不要憑感覺。 後面每一步都要靠這個數字判斷有沒有效。

這一步用 Home Assistant 內建的 SQL 整合，不用裝任何東西、不用碰設定檔。

• 設定 → 裝置與服務 → 右下角 新增整合
  
• 搜尋 SQL，選它
  
• 出現一個表單，照下面填
  

名稱：

1. HA 資料庫大小

複製代碼

資料庫 URL：留空。官方說明是「如果沒有指定資料庫 URL，SQL 整合會連到 Home Assistant 的 recorder 資料庫」—— 正是我們要的。

查詢（整段貼進去，包含最後的分號）：

1. SELECT ROUND(page_count * page_size / 1024 / 1024, 1) as size
2. FROM pragma_page_count(), pragma_page_size();

複製代碼

欄位：

1. size

複製代碼

測量單位：

1. MiB

複製代碼

按提交。

你會看到：到 設定 → 工具 → 狀態，搜尋 ha_zi_liao 或 sql，會出現一個實體，狀態是一個數字：

1. sensor.ha_zi_liao_ku_da_xiao    1847.3    unit_of_measurement: MiB

複製代碼

把這個數字抄下來。 這是你的起點。

大概多少算正常：

• 200 MiB 以下 —— 很健康，你的問題大概不在這裡
  
• 200 到 1000 MiB —— 偏大但還能跑，做完這一篇會明顯變快
  
• 1000 MiB 以上 —— 已經在拖慢系統，而且每天的備份都在複製它
  

實體出現但狀態是 unknown 或 unavailable → 查詢貼錯了，最常見是漏了分號或漏了 as size。回到 設定 → 裝置與服務 → SQL → 齒輪 → 重新設定。

找不到「工具」 → 它在 2026.2 被移進設定裡（不在側邊欄了），2026.8 從「開發者工具」改名成「工具」。按 Ctrl+K 打「工具」最快。

步驟 2：找出誰在狂寫（四分鐘）

要看前 20 名，需要一個能執行任意 SQL 的工具。裝 SQLite Web 這個應用程式。

以下還有約 81% 的內容
登入後即可閱讀完整教學

登入繼續閱讀使用 Google 登入