：SUM、GROUP BY、HAVING與EXISTS詳解)
1. SQL聚合與條件查詢的核心操作解析在日常數(shù)據(jù)庫操作中我們經(jīng)常需要對數(shù)據(jù)進行匯總統(tǒng)計和條件篩選。SQL提供了多種強大的函數(shù)和子句來完成這些任務(wù)其中SUM()、GROUP BY、HAVING、EXISTS、UCASE()和LCASE()是最常用的幾類操作。這些功能看似基礎(chǔ)但在實際業(yè)務(wù)場景中組合使用時往往能解決復(fù)雜的數(shù)據(jù)處理需求。我曾在電商平臺的訂單分析系統(tǒng)中通過合理組合這些操作將原本需要多段代碼實現(xiàn)的月度銷售報表功能簡化為了單條SQL查詢。這種高效的數(shù)據(jù)處理方式正是SQL語言的魅力所在。下面我將結(jié)合具體案例詳細(xì)講解每個操作的原理和使用技巧。2. 數(shù)據(jù)聚合SUM()與GROUP BY的黃金組合2.1 SUM()函數(shù)的基本用法SUM()是SQL中最基礎(chǔ)的聚合函數(shù)之一用于計算指定列的總和。它的標(biāo)準(zhǔn)語法是SELECT SUM(column_name) FROM table_name WHERE condition;例如計算某電商平臺所有訂單的總金額SELECT SUM(order_amount) AS total_revenue FROM orders;注意SUM()只能用于數(shù)值類型的列對非數(shù)值類型使用會導(dǎo)致錯誤。在實際項目中我建議先用CAST或CONVERT函數(shù)確保數(shù)據(jù)類型正確。2.2 GROUP BY的分組魔法單獨使用SUM()只能得到全局總和而結(jié)合GROUP BY可以實現(xiàn)分組統(tǒng)計。GROUP BY將數(shù)據(jù)按照指定列的值分組然后對每個組分別應(yīng)用聚合函數(shù)。典型應(yīng)用場景是按部門統(tǒng)計員工薪資SELECT department_id, SUM(salary) AS department_payroll FROM employees GROUP BY department_id;我曾遇到一個常見錯誤在SELECT子句中包含了非聚合列卻未在GROUP BY中指定。例如-- 錯誤示例 SELECT department_id, employee_name, SUM(salary) FROM employees GROUP BY department_id;這個查詢會報錯因為employee_name既不是聚合函數(shù)也不是GROUP BY子句的一部分。修正方法是要么將employee_name加入GROUP BY要么從SELECT中移除。2.3 多列分組與ROLLUPGROUP BY支持多列分組這在多維分析中特別有用。例如按產(chǎn)品和年份統(tǒng)計銷售總額SELECT product_id, YEAR(order_date) AS order_year, SUM(amount) AS total_sales FROM sales GROUP BY product_id, YEAR(order_date);對于需要小計的場景可以使用WITH ROLLUPSELECT product_id, YEAR(order_date), SUM(amount) FROM sales GROUP BY product_id, YEAR(order_date) WITH ROLLUP;ROLLUP會生成分層的小計行product_id和order_year都為NULL的行表示總計。在我的項目中這個功能極大簡化了財務(wù)報表的生成過程。3. HAVING聚合后的條件篩選3.1 HAVING與WHERE的區(qū)別WHERE在聚合前過濾行而HAVING在聚合后過濾組。這是兩者最本質(zhì)的區(qū)別。例如找出總銷售額超過10000元的部門SELECT department_id, SUM(sales) AS total_sales FROM sales_records GROUP BY department_id HAVING SUM(sales) 10000;常見誤區(qū)是試圖在WHERE中使用聚合函數(shù)-- 錯誤示例 SELECT department_id, SUM(sales) FROM sales_records WHERE SUM(sales) 10000 -- 這里會報錯 GROUP BY department_id;3.2 HAVING的進階用法HAVING不僅可以用于聚合函數(shù)還可以用于分組列。例如找出以A開頭的部門且銷售額超過5000元的記錄SELECT department_name, SUM(sales) FROM sales_data GROUP BY department_name HAVING department_name LIKE A% AND SUM(sales) 5000;在實際項目中我發(fā)現(xiàn)HAVING經(jīng)常與CASE表達(dá)式結(jié)合使用實現(xiàn)復(fù)雜的業(yè)務(wù)邏輯。例如識別銷售波動較大的產(chǎn)品SELECT product_id, AVG(monthly_sales) AS avg_sales, STDDEV(monthly_sales) AS sales_stddev FROM product_sales GROUP BY product_id HAVING STDDEV(monthly_sales) 0.3 * AVG(monthly_sales);4. EXISTS高效的存在性檢查4.1 EXISTS的基本工作原理EXISTS用于檢查子查詢是否返回任何行它返回布爾值TRUE或FALSE。與IN不同EXISTS通常在子查詢找到第一個匹配項后就停止處理因此在某些情況下性能更優(yōu)。典型應(yīng)用是找出有訂單的客戶SELECT customer_id, customer_name FROM customers c WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.customer_id c.customer_id );提示EXISTS子查詢中的SELECT 1是常見寫法因為EXISTS只關(guān)心是否有行返回不關(guān)心具體內(nèi)容。4.2 EXISTS與NOT EXISTS的實際應(yīng)用NOT EXISTS是EXISTS的否定形式常用于查找不滿足條件的記錄。例如找出從未下過訂單的客戶SELECT customer_id, customer_name FROM customers c WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.customer_id c.customer_id );我在用戶畫像系統(tǒng)中發(fā)現(xiàn)EXISTS特別適合處理多層嵌套的復(fù)雜條件。例如找出購買過特定品類商品的高價值客戶SELECT c.customer_id, c.customer_name FROM customers c WHERE c.total_spend 10000 AND EXISTS ( SELECT 1 FROM orders o JOIN order_items oi ON o.order_id oi.order_id JOIN products p ON oi.product_id p.product_id WHERE o.customer_id c.customer_id AND p.category Electronics );4.3 EXISTS與JOIN的性能對比雖然很多EXISTS查詢可以用JOIN重寫但兩者的執(zhí)行計劃可能不同。一般來說當(dāng)只需要檢查存在性而不需要關(guān)聯(lián)表的數(shù)據(jù)時EXISTS通常更高效當(dāng)需要關(guān)聯(lián)表的數(shù)據(jù)時JOIN可能更合適我曾通過EXISTS優(yōu)化過一個執(zhí)行緩慢的查詢將響應(yīng)時間從15秒降到了0.2秒。關(guān)鍵是將LEFT JOIN IS NOT NULL的模式改為了EXISTS。5. 字符串處理UCASE()與LCASE()5.1 大小寫轉(zhuǎn)換函數(shù)基礎(chǔ)UCASE()或UPPER()將字符串轉(zhuǎn)換為大寫LCASE()或LOWER()將字符串轉(zhuǎn)換為小寫。它們在數(shù)據(jù)清洗和比較時非常有用?；菊Z法SELECT UCASE(column_name) FROM table_name; SELECT LCASE(column_name) FROM table_name;5.2 實際應(yīng)用場景不區(qū)分大小寫的查詢SELECT user_name, email FROM users WHERE LCASE(user_name) LCASE(JohnDoe);數(shù)據(jù)標(biāo)準(zhǔn)化UPDATE customers SET customer_name UCASE(LEFT(customer_name,1)) LCASE(SUBSTRING(customer_name,2,LEN(customer_name))) WHERE customer_name LIKE [a-z]%;創(chuàng)建一致的比較基準(zhǔn)SELECT product_id, product_name FROM products WHERE LCASE(product_name) LIKE %laptop%;我在數(shù)據(jù)遷移項目中經(jīng)常使用這些函數(shù)處理來自不同系統(tǒng)的數(shù)據(jù)確保數(shù)據(jù)的一致性。一個常見問題是不同數(shù)據(jù)庫系統(tǒng)對大小寫的處理方式不同如MySQL默認(rèn)不區(qū)分SQL Server區(qū)分使用UCASE/LCASE可以避免這種不一致性。5.3 性能考慮雖然大小寫轉(zhuǎn)換函數(shù)很方便但在大表上對列使用函數(shù)會阻止索引使用。例如-- 可能導(dǎo)致全表掃描 SELECT * FROM users WHERE LCASE(username) admin; -- 更好的寫法如果數(shù)據(jù)庫默認(rèn)不區(qū)分大小寫 SELECT * FROM users WHERE username admin;對于需要頻繁查詢的列我建議在ETL過程中預(yù)先處理好大小寫或者使用函數(shù)索引如果數(shù)據(jù)庫支持。6. 綜合應(yīng)用案例6.1 銷售分析報表假設(shè)我們需要生成一份銷售報表要求按產(chǎn)品和月份分組統(tǒng)計銷售額只顯示月銷售額超過1萬元的產(chǎn)品標(biāo)識出有特殊促銷活動的月份SELECT p.product_name, UCASE(FORMAT(o.order_date, yyyy-MM)) AS month, SUM(oi.quantity * oi.unit_price) AS monthly_sales, CASE WHEN EXISTS ( SELECT 1 FROM promotions pr WHERE pr.product_id p.product_id AND pr.promotion_month MONTH(o.order_date) ) THEN YES ELSE NO END AS had_promotion FROM orders o JOIN order_items oi ON o.order_id oi.order_id JOIN products p ON oi.product_id p.product_id GROUP BY p.product_name, FORMAT(o.order_date, yyyy-MM), MONTH(o.order_date), p.product_id HAVING SUM(oi.quantity * oi.unit_price) 10000 ORDER BY month, monthly_sales DESC;6.2 用戶活躍度分析識別高價值活躍用戶過去一年訂單總額超過5000元最近3個月有訂單姓名以大寫字母顯示SELECT UCASE(c.customer_name) AS customer_name, SUM(o.order_amount) AS yearly_spend, COUNT(DISTINCT MONTH(o.order_date)) AS active_months FROM customers c JOIN orders o ON c.customer_id o.customer_id WHERE o.order_date DATEADD(year, -1, GETDATE()) GROUP BY c.customer_id, c.customer_name HAVING SUM(o.order_amount) 5000 AND COUNT(DISTINCT CASE WHEN o.order_date DATEADD(month, -3, GETDATE()) THEN o.order_id END) 0 ORDER BY yearly_spend DESC;7. 性能優(yōu)化與常見問題7.1 GROUP BY的性能陷阱過多的分組列GROUP BY列越多性能開銷越大。只選擇必要的列。大數(shù)據(jù)集分組對大表使用GROUP BY可能導(dǎo)致臨時表創(chuàng)建?？梢酝ㄟ^以下方式優(yōu)化在分組前用WHERE縮小數(shù)據(jù)范圍考慮使用預(yù)聚合表適當(dāng)增加數(shù)據(jù)庫的排序緩沖區(qū)大小索引利用確保GROUP BY使用的列有適當(dāng)?shù)乃饕?。對于?fù)合分組條件考慮創(chuàng)建復(fù)合索引。7.2 EXISTS的優(yōu)化技巧相關(guān)子查詢EXISTS通常使用相關(guān)子查詢確保外部表的連接列有索引。子查詢簡化保持子查詢盡可能簡單只包含必要的條件和列。與JOIN的取舍對于復(fù)雜的多表關(guān)聯(lián)測試EXISTS和JOIN兩種寫法的性能差異。7.3 HAVING的使用建議避免在HAVING中重復(fù)計算可以先在SELECT中計算表達(dá)式然后在HAVING中引用別名。-- 不推薦 SELECT product_id, SUM(quantity*price) FROM sales GROUP BY product_id HAVING SUM(quantity*price) 1000; -- 推薦 SELECT product_id, SUM(quantity*price) AS total_sales FROM sales GROUP BY product_id HAVING total_sales 1000;HAVING與WHERE的合理分工能在WHERE中過濾的條件不要放到HAVING中減少需要聚合的數(shù)據(jù)量。7.4 字符串函數(shù)的注意事項排序規(guī)則影響數(shù)據(jù)庫的排序規(guī)則(collation)會影響大小寫比較的行為了解你的數(shù)據(jù)庫設(shè)置。國際化考慮對于非英語文本大小寫轉(zhuǎn)換可能有特殊規(guī)則如土耳其的i/I。存儲與顯示分離考慮在存儲時統(tǒng)一大小寫而不是每次查詢時轉(zhuǎn)換。8. 不同數(shù)據(jù)庫的實現(xiàn)差異雖然這些SQL功能在大多數(shù)數(shù)據(jù)庫中都有實現(xiàn)但存在一些語法差異8.1 MySQL/MariaDBGROUP BY默認(rèn)允許SELECT非聚合列可通過ONLY_FULL_GROUP_BY模式禁用支持GROUP BY...WITH ROLLUPUCASE()/LCASE()與UPPER()/LOWER()完全等效8.2 SQL Server嚴(yán)格強制GROUP BY規(guī)則使用UPPER()/LOWER()而非UCASE()/LCASE()支持GROUPING SETS、CUBE和ROLLUP8.3 PostgreSQL同樣嚴(yán)格強制GROUP BY規(guī)則支持豐富的窗口函數(shù)可以替代部分GROUP BY用法支持ILIKE進行不區(qū)分大小寫的模式匹配8.4 Oracle使用UPPER()/LOWER()有豐富的分析函數(shù)擴展對GROUP BY的處理非常嚴(yán)格在我的跨數(shù)據(jù)庫項目中我通常會創(chuàng)建一個SQL方言適配層或者使用ORM工具來處理這些差異。對于性能關(guān)鍵的查詢則需要針對特定數(shù)據(jù)庫優(yōu)化。 SQL聚合與條件查詢實戰(zhàn)：SUM、GROUP BY、HAVING與EXISTS詳解
1. SQL聚合與條件查詢的核心操作解析在日常數(shù)據(jù)庫操作中我們經(jīng)常需要對數(shù)據(jù)進行匯總統(tǒng)計和條件篩選。SQL提供了多種強大的函數(shù)和子句來完成這些任務(wù)其中SUM()、GROUP BY、HAVING、EXISTS、UCASE()和LCASE()是最常用的幾類操作。這些功能看似基礎(chǔ)但在實際業(yè)務(wù)場景中組合使用時往往能解決復(fù)雜的數(shù)據(jù)處理需求。我曾在電商平臺的訂單分析系統(tǒng)中通過合理組合這些操作將原本需要多段代碼實現(xiàn)的月度銷售報表功能簡化為了單條SQL查詢。這種高效的數(shù)據(jù)處理方式正是SQL語言的魅力所在。下面我將結(jié)合具體案例詳細(xì)講解每個操作的原理和使用技巧。2. 數(shù)據(jù)聚合SUM()與GROUP BY的黃金組合2.1 SUM()函數(shù)的基本用法SUM()是SQL中最基礎(chǔ)的聚合函數(shù)之一用于計算指定列的總和。它的標(biāo)準(zhǔn)語法是SELECT SUM(column_name) FROM table_name WHERE condition;例如計算某電商平臺所有訂單的總金額SELECT SUM(order_amount) AS total_revenue FROM orders;注意SUM()只能用于數(shù)值類型的列對非數(shù)值類型使用會導(dǎo)致錯誤。在實際項目中我建議先用CAST或CONVERT函數(shù)確保數(shù)據(jù)類型正確。2.2 GROUP BY的分組魔法單獨使用SUM()只能得到全局總和而結(jié)合GROUP BY可以實現(xiàn)分組統(tǒng)計。GROUP BY將數(shù)據(jù)按照指定列的值分組然后對每個組分別應(yīng)用聚合函數(shù)。典型應(yīng)用場景是按部門統(tǒng)計員工薪資SELECT department_id, SUM(salary) AS department_payroll FROM employees GROUP BY department_id;我曾遇到一個常見錯誤在SELECT子句中包含了非聚合列卻未在GROUP BY中指定。例如-- 錯誤示例 SELECT department_id, employee_name, SUM(salary) FROM employees GROUP BY department_id;這個查詢會報錯因為employee_name既不是聚合函數(shù)也不是GROUP BY子句的一部分。修正方法是要么將employee_name加入GROUP BY要么從SELECT中移除。2.3 多列分組與ROLLUPGROUP BY支持多列分組這在多維分析中特別有用。例如按產(chǎn)品和年份統(tǒng)計銷售總額SELECT product_id, YEAR(order_date) AS order_year, SUM(amount) AS total_sales FROM sales GROUP BY product_id, YEAR(order_date);對于需要小計的場景可以使用WITH ROLLUPSELECT product_id, YEAR(order_date), SUM(amount) FROM sales GROUP BY product_id, YEAR(order_date) WITH ROLLUP;ROLLUP會生成分層的小計行product_id和order_year都為NULL的行表示總計。在我的項目中這個功能極大簡化了財務(wù)報表的生成過程。3. HAVING聚合后的條件篩選3.1 HAVING與WHERE的區(qū)別WHERE在聚合前過濾行而HAVING在聚合后過濾組。這是兩者最本質(zhì)的區(qū)別。例如找出總銷售額超過10000元的部門SELECT department_id, SUM(sales) AS total_sales FROM sales_records GROUP BY department_id HAVING SUM(sales) 10000;常見誤區(qū)是試圖在WHERE中使用聚合函數(shù)-- 錯誤示例 SELECT department_id, SUM(sales) FROM sales_records WHERE SUM(sales) 10000 -- 這里會報錯 GROUP BY department_id;3.2 HAVING的進階用法HAVING不僅可以用于聚合函數(shù)還可以用于分組列。例如找出以A開頭的部門且銷售額超過5000元的記錄SELECT department_name, SUM(sales) FROM sales_data GROUP BY department_name HAVING department_name LIKE A% AND SUM(sales) 5000;在實際項目中我發(fā)現(xiàn)HAVING經(jīng)常與CASE表達(dá)式結(jié)合使用實現(xiàn)復(fù)雜的業(yè)務(wù)邏輯。例如識別銷售波動較大的產(chǎn)品SELECT product_id, AVG(monthly_sales) AS avg_sales, STDDEV(monthly_sales) AS sales_stddev FROM product_sales GROUP BY product_id HAVING STDDEV(monthly_sales) 0.3 * AVG(monthly_sales);4. EXISTS高效的存在性檢查4.1 EXISTS的基本工作原理EXISTS用于檢查子查詢是否返回任何行它返回布爾值TRUE或FALSE。與IN不同EXISTS通常在子查詢找到第一個匹配項后就停止處理因此在某些情況下性能更優(yōu)。典型應(yīng)用是找出有訂單的客戶SELECT customer_id, customer_name FROM customers c WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.customer_id c.customer_id );提示EXISTS子查詢中的SELECT 1是常見寫法因為EXISTS只關(guān)心是否有行返回不關(guān)心具體內(nèi)容。4.2 EXISTS與NOT EXISTS的實際應(yīng)用NOT EXISTS是EXISTS的否定形式常用于查找不滿足條件的記錄。例如找出從未下過訂單的客戶SELECT customer_id, customer_name FROM customers c WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.customer_id c.customer_id );我在用戶畫像系統(tǒng)中發(fā)現(xiàn)EXISTS特別適合處理多層嵌套的復(fù)雜條件。例如找出購買過特定品類商品的高價值客戶SELECT c.customer_id, c.customer_name FROM customers c WHERE c.total_spend 10000 AND EXISTS ( SELECT 1 FROM orders o JOIN order_items oi ON o.order_id oi.order_id JOIN products p ON oi.product_id p.product_id WHERE o.customer_id c.customer_id AND p.category Electronics );4.3 EXISTS與JOIN的性能對比雖然很多EXISTS查詢可以用JOIN重寫但兩者的執(zhí)行計劃可能不同。一般來說當(dāng)只需要檢查存在性而不需要關(guān)聯(lián)表的數(shù)據(jù)時EXISTS通常更高效當(dāng)需要關(guān)聯(lián)表的數(shù)據(jù)時JOIN可能更合適我曾通過EXISTS優(yōu)化過一個執(zhí)行緩慢的查詢將響應(yīng)時間從15秒降到了0.2秒。關(guān)鍵是將LEFT JOIN IS NOT NULL的模式改為了EXISTS。5. 字符串處理UCASE()與LCASE()5.1 大小寫轉(zhuǎn)換函數(shù)基礎(chǔ)UCASE()或UPPER()將字符串轉(zhuǎn)換為大寫LCASE()或LOWER()將字符串轉(zhuǎn)換為小寫。它們在數(shù)據(jù)清洗和比較時非常有用?；菊Z法SELECT UCASE(column_name) FROM table_name; SELECT LCASE(column_name) FROM table_name;5.2 實際應(yīng)用場景不區(qū)分大小寫的查詢SELECT user_name, email FROM users WHERE LCASE(user_name) LCASE(JohnDoe);數(shù)據(jù)標(biāo)準(zhǔn)化UPDATE customers SET customer_name UCASE(LEFT(customer_name,1)) LCASE(SUBSTRING(customer_name,2,LEN(customer_name))) WHERE customer_name LIKE [a-z]%;創(chuàng)建一致的比較基準(zhǔn)SELECT product_id, product_name FROM products WHERE LCASE(product_name) LIKE %laptop%;我在數(shù)據(jù)遷移項目中經(jīng)常使用這些函數(shù)處理來自不同系統(tǒng)的數(shù)據(jù)確保數(shù)據(jù)的一致性。一個常見問題是不同數(shù)據(jù)庫系統(tǒng)對大小寫的處理方式不同如MySQL默認(rèn)不區(qū)分SQL Server區(qū)分使用UCASE/LCASE可以避免這種不一致性。5.3 性能考慮雖然大小寫轉(zhuǎn)換函數(shù)很方便但在大表上對列使用函數(shù)會阻止索引使用。例如-- 可能導(dǎo)致全表掃描 SELECT * FROM users WHERE LCASE(username) admin; -- 更好的寫法如果數(shù)據(jù)庫默認(rèn)不區(qū)分大小寫 SELECT * FROM users WHERE username admin;對于需要頻繁查詢的列我建議在ETL過程中預(yù)先處理好大小寫或者使用函數(shù)索引如果數(shù)據(jù)庫支持。6. 綜合應(yīng)用案例6.1 銷售分析報表假設(shè)我們需要生成一份銷售報表要求按產(chǎn)品和月份分組統(tǒng)計銷售額只顯示月銷售額超過1萬元的產(chǎn)品標(biāo)識出有特殊促銷活動的月份SELECT p.product_name, UCASE(FORMAT(o.order_date, yyyy-MM)) AS month, SUM(oi.quantity * oi.unit_price) AS monthly_sales, CASE WHEN EXISTS ( SELECT 1 FROM promotions pr WHERE pr.product_id p.product_id AND pr.promotion_month MONTH(o.order_date) ) THEN YES ELSE NO END AS had_promotion FROM orders o JOIN order_items oi ON o.order_id oi.order_id JOIN products p ON oi.product_id p.product_id GROUP BY p.product_name, FORMAT(o.order_date, yyyy-MM), MONTH(o.order_date), p.product_id HAVING SUM(oi.quantity * oi.unit_price) 10000 ORDER BY month, monthly_sales DESC;6.2 用戶活躍度分析識別高價值活躍用戶過去一年訂單總額超過5000元最近3個月有訂單姓名以大寫字母顯示SELECT UCASE(c.customer_name) AS customer_name, SUM(o.order_amount) AS yearly_spend, COUNT(DISTINCT MONTH(o.order_date)) AS active_months FROM customers c JOIN orders o ON c.customer_id o.customer_id WHERE o.order_date DATEADD(year, -1, GETDATE()) GROUP BY c.customer_id, c.customer_name HAVING SUM(o.order_amount) 5000 AND COUNT(DISTINCT CASE WHEN o.order_date DATEADD(month, -3, GETDATE()) THEN o.order_id END) 0 ORDER BY yearly_spend DESC;7. 性能優(yōu)化與常見問題7.1 GROUP BY的性能陷阱過多的分組列GROUP BY列越多性能開銷越大。只選擇必要的列。大數(shù)據(jù)集分組對大表使用GROUP BY可能導(dǎo)致臨時表創(chuàng)建?？梢酝ㄟ^以下方式優(yōu)化在分組前用WHERE縮小數(shù)據(jù)范圍考慮使用預(yù)聚合表適當(dāng)增加數(shù)據(jù)庫的排序緩沖區(qū)大小索引利用確保GROUP BY使用的列有適當(dāng)?shù)乃饕?。對于?fù)合分組條件考慮創(chuàng)建復(fù)合索引。7.2 EXISTS的優(yōu)化技巧相關(guān)子查詢EXISTS通常使用相關(guān)子查詢確保外部表的連接列有索引。子查詢簡化保持子查詢盡可能簡單只包含必要的條件和列。與JOIN的取舍對于復(fù)雜的多表關(guān)聯(lián)測試EXISTS和JOIN兩種寫法的性能差異。7.3 HAVING的使用建議避免在HAVING中重復(fù)計算可以先在SELECT中計算表達(dá)式然后在HAVING中引用別名。-- 不推薦 SELECT product_id, SUM(quantity*price) FROM sales GROUP BY product_id HAVING SUM(quantity*price) 1000; -- 推薦 SELECT product_id, SUM(quantity*price) AS total_sales FROM sales GROUP BY product_id HAVING total_sales 1000;HAVING與WHERE的合理分工能在WHERE中過濾的條件不要放到HAVING中減少需要聚合的數(shù)據(jù)量。7.4 字符串函數(shù)的注意事項排序規(guī)則影響數(shù)據(jù)庫的排序規(guī)則(collation)會影響大小寫比較的行為了解你的數(shù)據(jù)庫設(shè)置。國際化考慮對于非英語文本大小寫轉(zhuǎn)換可能有特殊規(guī)則如土耳其的i/I。存儲與顯示分離考慮在存儲時統(tǒng)一大小寫而不是每次查詢時轉(zhuǎn)換。8. 不同數(shù)據(jù)庫的實現(xiàn)差異雖然這些SQL功能在大多數(shù)數(shù)據(jù)庫中都有實現(xiàn)但存在一些語法差異8.1 MySQL/MariaDBGROUP BY默認(rèn)允許SELECT非聚合列可通過ONLY_FULL_GROUP_BY模式禁用支持GROUP BY...WITH ROLLUPUCASE()/LCASE()與UPPER()/LOWER()完全等效8.2 SQL Server嚴(yán)格強制GROUP BY規(guī)則使用UPPER()/LOWER()而非UCASE()/LCASE()支持GROUPING SETS、CUBE和ROLLUP8.3 PostgreSQL同樣嚴(yán)格強制GROUP BY規(guī)則支持豐富的窗口函數(shù)可以替代部分GROUP BY用法支持ILIKE進行不區(qū)分大小寫的模式匹配8.4 Oracle使用UPPER()/LOWER()有豐富的分析函數(shù)擴展對GROUP BY的處理非常嚴(yán)格在我的跨數(shù)據(jù)庫項目中我通常會創(chuàng)建一個SQL方言適配層或者使用ORM工具來處理這些差異。對于性能關(guān)鍵的查詢則需要針對特定數(shù)據(jù)庫優(yōu)化。