前言

在MySQL從5.7版本升級(jí)到8.0版本的過程中，ONLY_FULL_GROUP_BY模式的嚴(yán)格化成為開發(fā)者關(guān)注的焦點(diǎn)。這一變更不僅改變了SQL語句的編寫規(guī)范，更深刻影響了數(shù)據(jù)查詢的準(zhǔn)確性和一致性。本文將深入探討MySQL引入ONLY_FULL_GROUP_BY嚴(yán)格化的原因，并通過具體案例說明不嚴(yán)格化可能帶來的問題。

一、嚴(yán)格化的背景與目的

MySQL 5.7.5版本開始默認(rèn)啟用ONLY_FULL_GROUP_BY模式，這是對(duì)SQL標(biāo)準(zhǔn)的嚴(yán)格遵循。該模式的核心要求是：在使用GROUP BY子句時(shí)，SELECT列表、HAVING條件或ORDER BY列表中的每個(gè)列，要么是聚合函數(shù)的一部分（如COUNT()、SUM()、AVG()等），要么必須在GROUP BY子句中明確指定。

這一變更的初衷在于：

1. 增強(qiáng)數(shù)據(jù)準(zhǔn)確性：確保聚合查詢的結(jié)果符合預(yù)期，防止因非聚合列的不確定行為而導(dǎo)致的數(shù)據(jù)誤導(dǎo)。
2. 保持一致性：在不同的數(shù)據(jù)庫系統(tǒng)或配置間保持查詢行為的一致性，減少遷移或升級(jí)時(shí)的兼容性問題。
3. 避免歧義：清晰定義查詢的意圖，減少因查詢理解錯(cuò)誤而導(dǎo)致的錯(cuò)誤。

二、不嚴(yán)格化可能帶來的問題

1. 數(shù)據(jù)結(jié)果不可預(yù)測(cè)

在不啟用ONLY_FULL_GROUP_BY模式的情況下，MySQL允許SELECT列表中包含未在GROUP BY子句中出現(xiàn)的非聚合列。這種靈活性雖然方便了開發(fā)者，但也可能導(dǎo)致查詢結(jié)果的不確定性。

案例說明：
假設(shè)有一個(gè)員工打卡記錄表employee_checkin，包含員工姓名employee_name、部門department和打卡時(shí)間checkin_time?，F(xiàn)在需要統(tǒng)計(jì)每個(gè)部門的打卡次數(shù)，并嘗試顯示每個(gè)部門任意一個(gè)員工的姓名：

-- 不嚴(yán)格模式下的查詢（可能返回不確定結(jié)果）
SELECT department, employee_name, COUNT(*) AS checkin_count 
FROM employee_checkin 
GROUP BY department;

在上述查詢中，employee_name未出現(xiàn)在GROUP BY子句中，也未被聚合函數(shù)包裹。在關(guān)閉ONLY_FULL_GROUP_BY模式的情況下，MySQL可能隨機(jī)選擇一個(gè)員工姓名返回，導(dǎo)致每次查詢結(jié)果可能不同。這種不確定性在業(yè)務(wù)邏輯中是災(zāi)難性的，例如根據(jù)這個(gè)“任意”的員工名去發(fā)通知，可能就發(fā)錯(cuò)人了。

2. 違反SQL標(biāo)準(zhǔn)

不啟用ONLY_FULL_GROUP_BY模式意味著MySQL在處理GROUP BY查詢時(shí)采用了非標(biāo)準(zhǔn)的寬松模式。這種模式雖然提高了靈活性，但也降低了與SQL標(biāo)準(zhǔn)的兼容性。在需要與其他數(shù)據(jù)庫系統(tǒng)（如Oracle、PostgreSQL等）進(jìn)行數(shù)據(jù)交互或遷移時(shí)，這種差異可能導(dǎo)致查詢失敗或結(jié)果不一致。

3. 性能問題

雖然不嚴(yán)格化模式在表面上提供了更多的靈活性，但在某些情況下，它也可能導(dǎo)致性能問題。由于MySQL需要為每個(gè)分組選擇一個(gè)非聚合列的值，而這個(gè)選擇過程可能是隨機(jī)的或基于內(nèi)部存儲(chǔ)順序的，因此可能增加額外的計(jì)算開銷。特別是在處理大數(shù)據(jù)集時(shí)，這種性能差異可能更加明顯。

三、嚴(yán)格化的優(yōu)勢(shì)

1. 確保數(shù)據(jù)準(zhǔn)確性

啟用ONLY_FULL_GROUP_BY模式后，MySQL強(qiáng)制要求開發(fā)者明確指定每個(gè)非聚合列的來源或處理方式。這種明確性確保了查詢結(jié)果的準(zhǔn)確性和一致性，避免了因列的不明確引用而導(dǎo)致的數(shù)據(jù)錯(cuò)誤或不一致。

2. 提高代碼可維護(hù)性

嚴(yán)格模式下的SQL語句更加規(guī)范和清晰，易于理解和維護(hù)。開發(fā)者可以更容易地識(shí)別查詢的意圖和邏輯，從而減少錯(cuò)誤和調(diào)試時(shí)間。

3. 促進(jìn)最佳實(shí)踐

啟用ONLY_FULL_GROUP_BY模式鼓勵(lì)開發(fā)者遵循SQL標(biāo)準(zhǔn)和最佳實(shí)踐，編寫更加嚴(yán)謹(jǐn)和高效的SQL語句。這種習(xí)慣不僅有助于提升個(gè)人技能水平，也有助于提高整個(gè)開發(fā)團(tuán)隊(duì)的代碼質(zhì)量。

四、ONLY_FULL_GROUP_BY的核心規(guī)則

開啟此模式后，MySQL會(huì)強(qiáng)制要求SELECT列表、HAVING條件或ORDER BY列表中引用的列，必須滿足以下條件之一，否則查詢將被拒絕執(zhí)行：

• 被聚合：該列被聚合函數(shù)（如SUM, COUNT, MAX, MIN, AVG等）包裹。

• 在GROUP BY中：該列明確出現(xiàn)在GROUP BY子句中。

• 功能依賴于GROUP BY列：這是MySQL 5.7.5引入的更智能的特性。簡(jiǎn)單來說，如果GROUP BY的列（例如主鍵id）可以唯一地決定另一個(gè)列（例如name），那么即使在GROUP BY中沒有列出name，查詢也是合法的。例如，GROUP BY id時(shí)，查詢SELECT id, name ...是被允許的，因?yàn)?code>id是主鍵，能唯一確定name。

• 在WHERE中被限定為單一值：如果查詢中的WHERE條件將該列限制為單一確定的值，那么即使它不在GROUP BY中，也是允許的。

五、版本差異與總結(jié)

六、結(jié)論

MySQL引入ONLY_FULL_GROUP_BY嚴(yán)格化模式是出于對(duì)數(shù)據(jù)準(zhǔn)確性、一致性和可維護(hù)性的考慮。雖然這一變更可能給開發(fā)者帶來一定的適應(yīng)成本，但從長(zhǎng)遠(yuǎn)來看，它有助于提升代碼質(zhì)量、減少錯(cuò)誤和調(diào)試時(shí)間，并促進(jìn)最佳實(shí)踐的普及。因此，建議開發(fā)者在編寫SQL語句時(shí)遵循ONLY_FULL_GROUP_BY模式的要求，以確保查詢結(jié)果的準(zhǔn)確性和一致性。

到此這篇關(guān)于MySQL為什么要ONLY_FULL_GROUP_BY嚴(yán)格化的文章就介紹到這了,更多相關(guān)MySQL ONLY_FULL_GROUP_BY嚴(yán)格化內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論