遊戲 Lag 白皮書 › 只有部分人遇到的問題
特定角色的資料過於龐大 One character with oversized data (inventory, mail, buffs)
原因 ID pt-heavy-char · 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（DB 基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
累積了數千個道具或信件，或好友、封鎖名單、buff 特別多的角色，在登入、儲存與通知周圍玩家時要處理的量是別人的好幾倍。與線路無關，只有用那個角色時才慢。
為什麼 練了很久的角色，背包、信箱裡累積了數千個道具或活動獎勵 → 於是 每次登入、切換地圖、儲存都要讀寫那麼多 DB 資料，要送給周圍的裝備與 buff 資訊也很大 → 畫面上 只有那個角色進場載入很久，開背包或信箱時會頓一下。若伺服器在遊戲執行緒上等待儲存完成，連周圍的人也會短暫定格
- 症狀
- 連不上／無限讀取, 輸入延遲, 定格
- 因素
- 停滯
- 誰會遇到
- 只有我, 只有特定功能
- 何時
- 剛登入／維護剛結束, 做特定動作時, 移動中／切換地圖時
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（DB 基礎設施）
- 遊戲開發團隊要做的事
- 設定背包與信件的保存上限並自動清理舊信件，只分批載入需要的部分，儲存只寫有變更的部分，並在遊戲執行緒以外進行。
- 基礎設施團隊要做的事
- 從慢查詢 log 找出同一角色反覆出現的慢查詢並轉給遊戲開發團隊，提供道具、信件資料列數最多的角色排行清單。
- 數值參考
- 若一個道具是 DB 的一列，擁有 5,000 個道具的角色每次登入就要讀 5,000 列，是一般角色的數十倍。
- 圖表上
- 只有部分偏高 · 各角色的登入、儲存時間，各角色的 DB 查詢資料列數
- 查看位置
- 在 DB 的慢查詢 log（MySQL slow query log、PostgreSQL log_min_duration_statement）中找出同一角色 ID 反覆出現的慢查詢與儲存，並列出道具、信件資料表中各角色資料列數的排行
- 符合的跡象
- 慢查詢集中在少數幾個角色 ID，這些角色的道具、信件資料列數是平均的數十倍，從其他電腦、線路登入也一樣慢
- 不符合的跡象
- 同帳號的其他角色或其他玩家也一起變慢時，是 DB 設備或鎖定的問題。那個角色在其他電腦上正常時，是玩家端環境
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 深入了解
- 用同一個角色從其他電腦、線路登入也一樣慢，而同帳號的其他角色正常時，就要懷疑角色資料。這也是回報時一定要附上角色名稱的原因。
出處
- Extraneous Fetching antipattern Microsoft Azure
取得超過需要的資料會加重 I/O 負擔、拖慢回應 - PostgreSQL Documentation: Error Reporting and Logging PostgreSQL
log_min_duration_statement：記錄執行超過一定時間的 SQL，用來追蹤慢查詢 - The Slow Query Log MySQL
記錄超過 long_query_time 之查詢的慢查詢 log
相關原因
同一層：只有部分人遇到的問題
同一症狀（連不上／無限讀取）在其他層的原因
查看含圖解與實驗的完整版卡片