每月銷售報表為甚麼把兩年的 10 月加在一起？

先準備用來排查的資料

讀者要看各段日曆月份的時間線。「10」只是月份分類，不是唯一時段。分組鍵要保留年份，不能先合計再在標題加年份，因為數值已混在一起。

以下完整建表及資料只在新的 SQLite 測試資料庫執行。全部紀錄均為假設，數量以件計，輸入的 cents 金額欄以貨幣的分存整數；計算後的平均數可能不足整分。小型例子的各表均完整列在預覽。

CREATE TABLE sales(id TEXT PRIMARY KEY,sold_on TEXT,amount_cents INTEGER);
INSERT INTO sales VALUES ('S1','2025-10-01',10000),('S2','2026-10-02',20000);

重現錯誤結果，再核對更正

SELECT strftime('%m',sold_on) AS period,SUM(amount_cents) AS sales_cents FROM sales GROUP BY period ORDER BY period;

SELECT strftime('%Y-%m',sold_on) AS period,SUM(amount_cents) AS sales_cents FROM sales GROUP BY period ORDER BY period;

2025 年 10 月有 10000 分，2026 年 10 月有 20000 分；錯誤分組只剩 30000 分的「10 月」。更正後保留兩個時段，才不會把多年累計誤讀為某月增加。

套用前先測邊界及資料範圍

加入 2026 年 10 月 31 日銷售，只令該月變 25000 分，上一年不變。

邊界測試要另開新的假設資料庫，重做完整建表及資料，只套用以下改動，再執行更正查詢。測試改動不可用於正式系統。

INSERT INTO sales VALUES ('S3','2026-10-31',5000);

日期均有效且同一貨幣；財政期、退款及已確認收入須另訂規則。

以上錯誤、更正及邊界結果都已在 SQLite 執行，並與另行編寫的預期資料逐行核對。證據只適用於這組假設條件，未測其他資料庫、正式效能或你的現有資料結構。