技術選型：從排序效率談 SQL UNION 與應用層合併的取捨

上午正沉浸在 SVG 研究中，主管突然走過來：「你的數據生產工具出問題了，很多地點查不到。」

打開代碼調試，比對數據庫查詢結果與寫入文件的結果，最終鎖定問題根源：數據庫返回結果的排序順序不符合預期。

原始需求與實現邏輯

我需要從數據庫查詢出按地點拼音（py）排好序的結果，以便第一步按字母順序拆分文件。由於 DiBiao 實現了 Comparable 接口，原本計劃用 Collections.sort() 對 ArrayList<DiBiao> 排序，再按首字母拆分。

問題癥結

實際查詢涉及兩張表，分別得到兩個 ArrayList，再合併為一個列表。這導致最終順序打亂，不再符合拼音排序。

方案對比：誰更高效？

• 應用層手動合併排序：將兩個列表在 Java 中合併並排序（如歸併排序），再拆分文件。優點是邏輯集中在應用層，缺點是大數據量時記憶體壓力大，且多一次數據傳輸。
• MySQL 臨時表：將兩表結果插入臨時表，再從臨時表按 py 排序查詢。減少應用層負擔，但涉及臨時表創建、寫入、查詢、銷毀的開銷。
• 直接使用 UNION 查詢（推薦）：SELECT * FROM table1 UNION SELECT * FROM table2 ORDER BY py。數據庫引擎內部優化合併與排序，單次網絡往返，SQL 語義清晰，效率通常最高。

核心啟示

「技術的取捨」不在於花哨，而在於讓專業的工具做專業的事。關係型數據庫擅長集合運算與排序，將邏輯下推到存儲層，往往比應用層折騰更簡潔、高效、穩健。