目前位置： 正文

MySQL GROUP_CONCAT 清單只出一半：先查連線的長度上限

2026-11-04 精品教程 0 0

分類標籤明明有三筆，匯出後卻只剩「alpha,be」，連 beta 都少了一截。若查詢使用 GROUP_CONCAT()，先檢查輸出長度上限，不要立刻認定資料已遺失。這個函式把多列值串成一個字串，結果過長時可能被截斷。

網站的標籤清單、附件名稱或後台報表都可能遇到這種情況。下面用 MySQL 8.4 的三筆文字示例分清兩件事：來源查到幾列，以及最後串出的文字是否完整。示例只讀臨時組出的資料，不建立或修改資料表。

先查執行那筆查詢的連線

SELECT VERSION(),
       @@SESSION.group_concat_max_len,
       @@GLOBAL.group_concat_max_len;

MySQL 8.4 的 group_concat_max_len 預設值是 1024，但站點可能已調整。它限制的是位元組數，不是可容納幾個標籤或幾個中文字；分隔符號也占輸出長度。因此要讀實際設定，不能只按「大約幾個字」估算。

尤其要看 SESSION 值。管理工具開的一條連線，和網站程式使用的連線可能不同；在工具裡調好了，不表示網站的那筆查詢已採用相同設定。

用小上限重現：三列資料，結果卻只剩半個名稱

在獨立測試連線依序執行以下內容，先保存原設定，再暫時將這條連線的上限設成 8：

SET @saved_limit = @@SESSION.group_concat_max_len;
SET SESSION group_concat_max_len = 8;

SELECT COUNT(*) AS source_rows,
       GROUP_CONCAT(name ORDER BY id SEPARATOR ',') AS names
FROM (
  SELECT 1 AS id, 'alpha' AS name
  UNION ALL SELECT 2, 'beta'
  UNION ALL SELECT 3, 'gamma'
) AS sample;
SHOW WARNINGS;

這筆查詢的 source_rows 仍是 3，但 names 是 alpha,be；緊接著的警告會指出 GROUP_CONCAT 有內容被截斷，這個例子會出現代碼 1260。原資料沒有因為截斷而被刪除，只是串接結果不完整。

請在那筆 SELECT 後立即查看警告，別先執行一串其他查詢，才回頭找截斷原因。若你的客戶端自動執行額外查詢，也要確認看到的是哪一筆操作的警告。

提高本連線上限後，再核對完整結果

仍在同一條測試連線，把上限改成足夠容納這個例子的 64，重跑相同的 SELECT：

SET SESSION group_concat_max_len = 64;

SELECT COUNT(*) AS source_rows,
       GROUP_CONCAT(name ORDER BY id SEPARATOR ',') AS names
FROM (
  SELECT 1 AS id, 'alpha' AS name
  UNION ALL SELECT 2, 'beta'
  UNION ALL SELECT 3, 'gamma'
) AS sample;
SHOW WARNINGS;

SET SESSION group_concat_max_len = @saved_limit;

這次應得到 3 與 alpha,beta,gamma。這組 ASCII 文字連同兩個逗號共占 16 位元組，64 只為了讓示例容易重現，並不是正式站的建議通用值。測完要在同一連線還原原值；若中途換了連線，保存原值的使用者變數也不能沿用。

正式報表要同時檢查長度與資料規則

確認是截斷後，再按實際資料量估算所需上限。不要直接設成極大值：MySQL 文件提醒，過高設定可能影響效能，甚至耗盡記憶體；輸出的有效最大長度也受 max_allowed_packet 限制。

如果資料量會一直增加，匯出程式可考慮逐列讀取，而非把所有名稱塞進一個大字串。程式確實需要串接時，應在執行查詢的那條連線設定並讀回 SESSION 值。使用連線池時，依框架的連線初始化與重設方式處理，避免把測試設定留給下一個借用者。

最後也別把每種「少了項目」都歸咎於長度：GROUP_CONCAT() 會略過 NULL，DISTINCT 會去掉重複值，JOIN 與 WHERE 則可能先改變來源列。範例把排序寫在 GROUP_CONCAT 內，是為了固定名稱串接順序；只在外層對查詢結果排序，不能替代這個順序要求。先核對來源，再看警告與最後字串，才知道應改查詢條件還是長度設定。

參考資料

原文鏈接：https://wntheme.com/mysql-group-concat-truncated-session-limit/，轉載請註明出處。
0

猜妳喜歡

MySQL訂單金額加總翻倍：兩張明細表先彙總再JOIN
精品教程
MySQLSQL查詢資料彙總

訂單報表原本對得上，加入商品數量與付款金額後，營業額卻突然變多。這時先別改訂單資料，也別急著在SUM裡加DISTINCT。常見原因是同一筆訂單有多件商品、也有多筆付款；兩張明細表直接JOIN，會讓彼此的資料重複出現。 修正的關鍵是讓每張明細表先變成「一筆訂單一列」，再連回訂單表。下面用三筆虛構訂單比較原始總額、錯誤查詢與修正查詢，連沒有商品或付款的訂單也一起保留。 先算出三張表各自的答案 這組範例只放在自有測試資料庫。第一、第二筆訂單刻意使用相同金額120，第三筆為80；這樣才能看出按金額去重會漏算。items代表商品明細，qty是數量；payments代表付款紀錄，其amount與訂單表的amount是不同統計。 CREATE TABLE orders ( id INT PRIMARY KEY, amount DECIMAL(10,2) NOT NULL ); CREATE TABLE items ( id INT PRIMARY KEY, order_id INT NOT NULL, qty INT NOT NULL ); CREATE TABLE payments ( id INT PRIMARY KEY, order_id INT NOT NULL, amount DECIMAL(10,2) NOT NULL ); INSERT INTO orders VALUES (1,120), (2,120), (3,80); INSERT INTO items VALUES (11,1,2), (12,1,1), (21,2,1); INSERT INTO payments VALUES (31,1,60), (32,1,60), (33,2,120); 單看orders，三筆訂單總額是320；items的商品總數是4；payments的付款總額是240。第三筆訂單還沒有商品或付款明細，因此不能把訂單總額320與已付款240當成同一個數字。真實網站還要定義取消、退款與付款狀態，這裡先把連接造成的重複算清楚。 SELECT COUNT(*) AS orders_n, SUM(amount) AS order_total...
2026-10-05 138 0
文尼先生 2026-10-05
MySQL upsert觸發更新：先看唯一鍵
精品教程
MySQLSQL

會員匯入原本想新增一筆資料，結果卻改了舊會員的名稱。檢查SQL時不能只看新傳入的id，也要看資料表有哪些唯一鍵。INSERT ... ON DUPLICATE KEY UPDATE在新增資料碰到PRIMARY KEY或UNIQUE衝突時，會轉去更新既有列。這個分支是資料庫的鍵約束觸發，並不是程式先查到某個欄位就自動選對會員。 新id不代表這筆一定新增 以下例子用訂閱者表，id是主鍵，email另有UNIQUE約束。資料表先存一位id為1、email為[email protected]、name為old的訂閱者。接著送入id為2的新資料，但email仍是同一個地址。id沒有重複，不代表整列沒有唯一鍵衝突：email的UNIQUE仍會攔住新增。 CREATE TABLE subscribers ( id INT PRIMARY KEY, email VARCHAR(100) NOT NULL UNIQUE, name VARCHAR(30) NOT NULL ); INSERT INTO subscribers (id, email, name) VALUES (1, '[email protected]', 'old'); 先看表結構再讀upsert，會比只追應用程式傳入的id清楚。這裡email使用NOT NULL，避免把「沒有email」的NULL情況混進判斷；email比較仍受欄位型別與collation影響。這篇案例只用相同的小寫字串驗證衝突，沒有測試不同大小寫或所有郵件地址的相等規則，也不把資料庫字串相等當成完整郵件驗證。 用新列別名寫出更新來源 INSERT INTO subscribers (id, email, name) VALUES (2, '[email protected]', 'updated') AS incoming ON DUPLICATE KEY UPDATE name = incoming.name; AS incoming替原本嘗試新增的列取別名。更新分支的incoming.name是這次送入的updated，不是資料表目前的old。例子只更新name，沒有指定id或email的更新，因此舊列仍保留id為1與原email。使用新列別名也讓更新來源一眼可辨；MySQL文件已將更新分支中的VALUES()寫法列為棄用，不宜再把舊寫法當成新範例。這裡討論的是MySQL，不保證其他資料庫採用相同語法。 實際讀回是哪一列被更新 本地隔離案例使用MySQL 8.4.9，在新資料庫執行以上SQL後讀回整表。結果只有id為1的列，name已變成updated，沒有產生id為2的列。接著送入id為3、email為[email protected]、name為new，因兩個唯一鍵都不衝突，這次才走新增分支。兩次操作的差異是鍵是否衝突，不是名稱內容或輸入順序。 SELECT id, email, name FROM subscribers ORDER BY id; -- after same-email upsert -- 1 [email protected]...
2026-10-05 51 0
文尼先生 2026-10-05
MySQL加欄位後ROLLBACK沒撤回：DDL隱式提交的邊界
精品教程
MySQLSQL

測試腳本先START TRANSACTION，再插入一筆資料、加一個欄位，最後ROLLBACK。你以為全部會撤回，結果資料與欄位都還在。先查中間有沒有造成隱式提交的語句：MySQL的ALTER TABLE會打斷原本交易，不能只因腳本外面寫了交易，就把資料變更與結構變更視為一整包可回滾。 ROLLBACK只處理仍在交易中的變更 一般InnoDB資料操作可以在明確交易中由COMMIT提交或ROLLBACK回滾，但一些語句會自己形成提交邊界。MySQL官方文件列有ALTER TABLE等DDL語句；許多這類語句在執行前提交目前交易，並在執行後形成自己的提交。讀腳本時要查看整個語句序列，不能只找開頭與結尾。 這篇聚焦ALTER TABLE新增一般欄位的實測。不是所有SQL、所有DDL或所有資料庫引擎都用同一條規則；例如暫存表相關語句有文件列出的不同界線。碰到具體語句時，核對MySQL對應版本的隱式提交清單，不要只用「DDL都一樣」一句話跳過。 在自己的小表重現提交邊界 案例使用自有隔離MySQL 8.4.9，只有一張明確指定ENGINE=InnoDB的小表，沒有對外開放連接埠，也沒有讀寫正式網站資料。先在交易外建立原始表，再開始交易；這樣觀察點就是交易內的INSERT與ALTER，而不是把建立資料庫的影響混在一起。 CREATE TABLE records ( id INT PRIMARY KEY, label VARCHAR(30) ) ENGINE=InnoDB; START TRANSACTION; INSERT INTO records VALUES (1,'before-ddl'); ALTER TABLE records ADD COLUMN note VARCHAR(30) NULL; ROLLBACK; 接著查看資料與欄位。本次ROLLBACK之後，id 1的before-ddl仍存在，note欄位也存在且值為NULL。這不是只用介面快取推測：測試直接執行SELECT和SHOW COLUMNS，保存伺服器回傳的結果。 SELECT * FROM records ORDER BY id; SHOW COLUMNS FROM records; -- 仍有：1 / before-ddl / NULL -- 欄位仍有：id、label、note 在INSERT與ALTER之間沒有手動COMMIT。這正是案例要核對的地方：ALTER觸發提交邊界，讓先前那筆INSERT不再屬於最後ROLLBACK能撤回的未提交工作。若只說「新欄位沒被撤回」，還不足以指出資料操作也被提交；所以這裡同時檢查列與結構。 atomic DDL不等於你可手動回滾整段腳本 MySQL 8.4支援特定範圍的atomic DDL，官方用來描述DDL操作中資料字典、儲存引擎與二進位紀錄等更新的原子性。它讓受支援的DDL在完成或失敗時有一致的結果，但不把DDL變成能與先前DML放在同一使用者交易裡、最後一起ROLLBACK的語句。 兩個「原子」的對象不同：一個是在討論DDL這項操作如何完成，另一個是你希望整份腳本的多個步驟都一起撤回。這個小表沒有模擬當機或DDL執行中斷，也沒有驗證故障恢復；它只證明一般ALTER成功之後，最後ROLLBACK不會把這次結構與先前插入一起還原。 不要把這份結果寫成「InnoDB不支援交易」。表仍是InnoDB，問題是交易中插入了會提交的語句。也不要把SET autocommit=0當成通用解法；自動提交設定與特定語句的隱式提交規則是不同層次，關掉前者不會抹掉後者。 把資料修改與結構遷移分開規劃 如果工作只需修改既有資料，先使用明確交易包住需要一起成功的DML，再確認中間沒有隱式提交語句。需要加欄位、改索引或調整結構時，另立遷移步驟、驗收與恢復方式。不要把DDL藏在「若欄位不存在就加一下」的資料匯入程式裡，還對外保證整次匯入可以回滾。 對正式表的結構修改還牽涉資料量、鎖、執行算法與應用程式相容性。這篇一列表的ALTER很快，不代表正式大表不會阻塞，也沒有證明可以無停機部署。這些需要依實際ALTER、表與環境另外評估；本篇只處理交易邊界，不順手給出正式DDL命令。 遷移的回復方式也不一定是執行反向ALTER。新增欄位後如果已有程式寫入資料，直接刪除欄位可能丟失內容；修改型態後也未必能無損轉回。先保存必要備份、定義可接受的恢復點與相容期間，再決定回復設計，不能把「再改回去」等同交易回滾。 排查時重建真正的語句順序 先把測試的起始狀態也保存：原表只有id與label，沒有資料；結束時有一列與新增note。這樣能辨認變更究竟出自本次腳本，還是前一輪測試留下的內容。重跑時使用新測試表或新隔離資料庫，不要在已變更的表上再加同名欄位，然後把重複欄位錯誤混成原案例。 備份能協助恢復已提交變更，但它不是ROLLBACK的另一個名稱。恢復備份可能影響備份之後的其他合法資料，所以必須選定範圍與時間點。交易邊界寫清楚，才知道恢復方案需要處理哪些已經超出當前交易的工作。 先整理BEGIN或START TRANSACTION之後到COMMIT或ROLLBACK之前的每一條SQL，包含框架或工具自動送出的語句。應用程式裡有transaction函式，不代表函式內每個呼叫都遵守同一交易邊界；若中間執行ALTER，仍要按資料庫實際規則解讀。 保留相同連線中的版本、儲存引擎與最小重現結果。不同連線有各自的交易，不能在一個終端ROLLBACK後，到另一個應用程式畫面看到資料，就直接推論第一個交易沒有工作。這篇在同一個客戶端連線完成序列，再讀取結果，避免這種混淆。...
2026-10-05 49 0
文尼先生 2026-10-05
MySQL查整天少了晚間資料：DATETIME用半開區間
精品教程
MySQLSQL

網站報表選了某一天，結果只出現零點資料；把結束時間改到23:59:59，又少了最後一秒裡的小數時間。查詢先別怪資料沒寫入：DATETIME欄位包含時間，而日期輸入並不代表「整天的所有時刻」。用當日開始到次日開始的半開區間，可以把這個邊界寫清楚。 BETWEEN兩端都包含，但日期不是一整天 BETWEEN包含下限與上限。在本篇DATETIME案例中，兩端都寫同一個日期，得到的是同一天午夜到同一天午夜，不是從早到晚。日期與日期時間在比較時會涉及型態轉換，因此最好先寫出你實際要比較的兩個時刻，而不是靠「選了一天」這句介面文案猜測SQL意思。 SELECT id FROM events WHERE occurred_at BETWEEN '2026-09-20' AND '2026-09-20'; 這個查詢在本次資料只找到id 1，也就是00:00:00那筆。若表裡沒有午夜資料，可能一筆都找不到。它不代表BETWEEN不能用，而是兩個界線相同；即使使用者輸入同一天，應用程式仍要把需求轉成正確的時間區間。 用三筆邊界資料實測 案例使用自有隔離MySQL 8.4.9，欄位明確設定DATETIME(6)，讓微秒能保留下來。三筆分別是當日午夜、當日最後一個微秒，以及次日午夜。所有字面值沿用同一個時間約定，沒有在案例裡做時區換算，也沒有操作正式報表資料。 CREATE TABLE events ( id INT PRIMARY KEY, occurred_at DATETIME(6) NOT NULL ); INSERT INTO events VALUES (1,'2026-09-20 00:00:00'), (2,'2026-09-20 23:59:59.999999'), (3,'2026-09-21 00:00:00'); 如果欄位只是DATETIME而沒有指定小數精度，不能直接宣稱同樣保存六位微秒。先用SHOW CREATE TABLE核對真實欄位，再選符合其精度的測試資料。本例刻意用DATETIME(6)，就是為了讓「只寫到整秒的結束時間」與「該秒內稍後的資料」出現實際差異。 結束寫23:59:59，仍會漏掉小數秒 SELECT id FROM events WHERE occurred_at BETWEEN '2026-09-20 00:00:00' AND '2026-09-20 23:59:59' ORDER BY id; 這次仍只得到id 1。id 2的時間是23:59:59.999999，比23:59:59更晚，所以不在區間內。把上限寫成23:59:59.999999可以配合目前六位精度，但往後換欄位或組合不同時間來源時，仍得重新考慮精度。用次日開始作排他上限通常更容易表達整天的需求。 也不要直接把上限改成次日00:00:00後繼續用BETWEEN，因為上限仍會被包含，id 3就可能落入前一天的報表。如果隔天的報表又包含自己的午夜，同一筆資料可能被兩天重複計算。問題的關鍵是上限是否包含，不是換一個看起來更晚的日期就完成了。 改成大於等於開始，小於次日開始 SELECT id FROM events WHERE occurred_at >= '2026-09-20' AND occurred_at < '2026-09-21' ORDER BY...
2026-10-05 89 0
文尼先生 2026-10-05
MySQL UNIQUE仍能插入多筆NULL：缺值與重複值怎麼分
精品教程
MySQLSQL

優惠碼欄位加了UNIQUE，資料表卻還能存入兩筆NULL。這不是索引沒生效：在MySQL裡，可空欄位的唯一索引允許多個NULL。先確認你想防止的是「重複已填寫的代碼」，還是「每筆都一定要有唯一代碼」，兩種需求需要不同限制。 UNIQUE不等於每列必填 UNIQUE檢查的是唯一性；NULL代表缺少值，它與一般已填寫的字串不同。若欄位允許NULL，就不能期待UNIQUE同時要求每列都有代碼。MySQL的CREATE INDEX文件明確列出，允許NULL的UNIQUE索引可以包含多個NULL。 不要把這條規則延伸成所有資料庫都完全一樣，也不要把它說成「NULL等於NULL所以算一次」。NULL的一般比較有另外的語意，唯一索引的可空行為則是這裡實際要核對的規則。這篇用MySQL 8.4.9的單一字串欄位做直接插入，不混入其他引擎或複合鍵的例外。 兩個NULL成功，第二個A失敗 在自己的測試資料庫建立下面這張小表。id作為每筆資料的主鍵，code允許NULL且有UNIQUE。先一次放入兩筆沒有代碼的資料與一筆A，再嘗試新增第二筆A，才能同時看到可空行為與唯一限制是否生效。 CREATE TABLE codes ( id INT PRIMARY KEY, code VARCHAR(30) NULL UNIQUE ); INSERT INTO codes VALUES (1,NULL), (2,NULL), (3,'A'); INSERT INTO codes VALUES (4,'A'); 本次前三筆插入成功；第二個A被拒絕，錯誤碼1062。最後查詢id由小到大，結果仍是1=NULL、2=NULL、3=A，沒有id 4。這個對照說明唯一限制有工作，只是它不會把兩個NULL當成第二個A那樣的重複值。 SELECT id, code FROM codes ORDER BY id; -- 實測結果 -- 1 NULL -- 2 NULL -- 3 A 負測的錯誤訊息是案例的一部分。這次命令行讓後續查詢繼續執行，以便查看失敗後的資料，因此不能只看整個程序最後的退出碼就宣稱四筆都插入了。自己重現時，把每個INSERT的成功或1062和最後列數一起保存。 查沒有代碼的資料，要用IS NULL SELECT id, code FROM codes WHERE code IS NULL; 這個條件會找到兩筆沒有代碼的資料。不要改成code = NULL；一般等號比較遇到NULL，不會得到你要的真值。也不要寫code = 'NULL'，那是四個字母構成的字串，與資料庫的空值完全不同。 管理工具常把NULL顯示成灰字或特殊標記，匯出工具又可能寫成空白。看到畫面空白時，先查IS NULL，再查等於空字串的情況；兩者不能只靠視覺判定。回到網站表單，也要確認未填欄位最後送入資料庫的是NULL、空字串，還是程式預設值。 MySQL也提供NULL安全的比較運算子，但那是在查詢中定義比較方式，不會把現有UNIQUE索引自動改成「只允許一個NULL」。查詢條件與資料限制分開處理，才不會因為某個SELECT能比對空值，就誤認為INSERT應有相同規則。 空字串不是NULL，必填也不是唯一 回傳JSON時也應保留這個差別。NULL可以對應JSON的null，空字串仍應是字串；如果程式為了方便顯示把兩者都轉成同一句「沒有資料」，只能把它當作顯示文字，不能再拿那句文字寫回代碼欄位。資料層的原始型態應留著，才能讓後面的檢查與更新作出正確選擇。 空字串是已存在的字串值；在一般單欄唯一限制下，重複的相同空字串仍會遇到唯一性檢查。這篇真插入案例只測了NULL與A，沒有另外插入兩筆空字串，所以不要把它的輸出冒充所有輸入型態都已實測。文件區分NULL與空字串的規則，足以提醒你先核對實際資料。 如果業務要求每筆都有代碼，欄位可考慮NOT NULL加UNIQUE，再由表單與後端處理是否允許空字串、只含空白或特定格式。NOT NULL不會自行禁止空字串，也不會完成格式驗證；欄位限制與輸入規則各有責任。...
2026-10-05 57 0
文尼先生 2026-10-05
MySQL GROUP BY選名字報錯：別讓非分組欄位隨機取值
精品教程
MySQLSQL

分類列表想同時顯示每類筆數與最新一筆名稱，SQL卻回傳1055錯誤。別先關掉ONLY_FULL_GROUP_BY。這個錯誤通常是在問你：同一組裡有多個名稱，結果只留一列時，到底要顯示哪一個？先回答這個問題，比讓查詢勉強執行更有用。 分組後，一般欄位可能沒有唯一答案 先在出錯的同一條連線查SELECT @@SESSION.sql_mode;，確認目前是否包含ONLY_FULL_GROUP_BY。開發工具、應用程式連線與另一個終端可能使用不同連線設定；只讀了全域設定，未必解釋應用程式正在使用的模式。診斷時保留版本與當前連線值，不必先改伺服器設定。 GROUP BY category把同類資料集合成一組，COUNT(*)可以計算組內列數。但name沒有經過聚合，同一分類若有Alpha、Beta與Aardvark，就沒有一個自然且唯一的name可放到結果中。下列查詢在本案例MySQL 8.4.9啟用ONLY_FULL_GROUP_BY時被拒絕，錯誤碼是1055。 SELECT category, name, COUNT(*) FROM items GROUP BY category; 這不是所有未列在GROUP BY中的欄位都永遠禁止。MySQL也會判斷功能依賴，例如分組鍵能唯一識別一筆資料時，其他欄位可能有唯一答案；文件也列有WHERE限制為單一值的情況。本例category既不是唯一鍵，同類又有不同name，因此不能靠這些例外取得所需結果。 把name也加入GROUP BY，雖然可能讓查詢合法，卻把「每個分類一組」改成「每個分類與名稱的組合一組」。如果你要的是分類總數，這不是原來的需求。修正SQL前先列出結果應有幾列，以及每列代表什麼，避免只修掉錯誤訊息。 建立可分辨最大名稱與最新資料的案例 下面在自有隔離測試資料庫使用四筆資料。A分類有三個名稱，最新日期刻意配Aardvark；按目前測試排序規則比較字串時，最大名稱則是Beta。這樣兩種需求會得到不同答案，不會因為測試資料巧合而誤以為MAX等於最新。 CREATE TABLE items ( id INT PRIMARY KEY, category VARCHAR(10), name VARCHAR(30), created_at DATETIME ); INSERT INTO items VALUES (1,'A','Alpha','2026-09-01'), (2,'A','Beta','2026-09-02'), (3,'B','Gamma','2026-09-01'), (4,'A','Aardvark','2026-09-03'); 本次案例只在當前連線設定測試用sql_mode，再執行負測與兩種正確查詢；沒有修改正式伺服器的全域模式。負測輸出的1055保留在測試紀錄，命令行允許後續語句繼續執行，所以整段程序最後返回成功也不代表所有SQL都成功。 MAX(name)回答的是最大字串 SELECT category, MAX(name) AS greatest_name, COUNT(*) AS total FROM items GROUP BY category; 本次A組得到greatest_name=Beta、total=3；B組得到Gamma、1。查詢清楚地要求字串最大值，所以是合理的分組聚合。但它沒有查詢日期，不能回答「最新建立的名稱」。字串比較還受欄位排序規則影響，不要把MAX理解成插入順序或肉眼覺得較新的名稱。 如果需求確實只是統計每類筆數，直接選category與COUNT(*)就好，不必額外加一個沒有用途的名稱。若要每類最大金額，MAX(amount)也有明確意義；但最大金額與其他欄位分別聚合後，可能來自不同原始列。需要整列資料時，應另寫選列規則。 COUNT(*)計算列數，COUNT(name)則不計入名稱為NULL的列。本例每列都有名稱，所以沒有測出兩者差異；套用到實際報表時，別只因結果暫時相同就互換統計式。 同樣地，ANY_VALUE(name)只是讓你接受組內某個值，不是最新列的別名。在本題裡使用它會跳過「選哪一列」的責任。把ONLY_FULL_GROUP_BY關掉也無法替你補上日期規則，還可能讓讀者以為任意結果是業務要求。 在分組查詢最後加ORDER BY created_at DESC，也不能把組內的name變成最新資料。結果列的排序與組內取值是不同工作；先選出什麼結果，再排列結果，不能倒過來解讀。若錯誤查詢沒有得到合法結果，就更不能用後面的ORDER BY來證明某個名稱會被選中。 要最新整列，用視窗排序選第一列 SELECT category, name FROM ( SELECT category, name, ROW_NUMBER()...
2026-10-05 47 0
文尼先生 2026-10-05
顯示驗證碼
沒有帳號？註冊  忘記密碼？