Database
MongoDB, Redis and SQLite: queries, encoding and transactions.
SQLite FTS5 MATCH 的使用者輸入要先包成 phrase
memory-mcp 的搜尋把使用者輸入直接帶進 WHERE memories_fts MATCH ?。參數綁定不等於跳脫。
Redis ZREMRANGEBYRANK 不收縮 dict，判斷要不要瘦身一律看 ZCARD 不看 MEMORY USAGE
一支千萬級的 sorted set 用 ZREMRANGEBYRANK 分批刪到只剩 1000 筆之後，MEMORY USAGE 仍然回報 288 MB——合理值應該是 1000 × ~190 B ≈ 0.2 MB，差了三個數量級。「容器縮小了」和「容器佔用的記憶體縮小了」是兩件事。
Python sqlite3 的 with conn: 拿不到原子性——當 repo 函式自己 commit
Review 指出這不是原子操作：中途失敗（database is locked、process 被砍）會留下「事實寫進去了、但沒標記」，下一輪重跑就重複寫入同一批。with conn: 只在「區塊內沒有任何 commit」時才有原子性。
SQLite FTS5 trigram 搜不到兩個字的中文詞
一個中文聊天機器人用 FTS5 全文檢索翻歷史對話。不報錯、不拋例外，就是回空清單——跟「這件事從來沒被提過」長得一模一樣。測試資料剛好避開邊界，比沒有測試更危險。
後台顯示亂碼：先查是不是「歷史髒資料換了新展示層才曝光」而非現行系統新 bug
GM/BI 後台某個查詢頁面的文字欄位（例如「備注」）顯示亂碼，混雜 HTML entity 與亂碼字元（例如 äº 或直接顯示 以塰 這類字元）。亂碼只出現在特定時間窗口，是「歷史髒資料」的強訊號，不是「現行系統新 bug」。
MongoDB 慢查詢引發簽到 Race Condition
某平台 MongoDB 主機發生 CPU 告警，慢查詢 log 顯示 coinlog、fishlog collection 查詢時間過長（數十秒甚至數分鐘）。慢查詢不只是效能問題，在有狀態操作的流程中，過長的等待時間會放大 Race Condition 的觸發機率。