1. 介紹
在使用 MySQL 時，你可能會遇到諸如「我想忽略大小寫來搜尋」或相反的「我想區分大小寫，但它的表現並不像預期」這類問題。例如，你可能在處理使用者名稱、電子郵件地址或產品代碼等情境時，有時想將大小寫視為不同，有時則不想。
實際上，許多搜尋「mysql 不區分大小寫」的使用者都在疑問：
- 如何進行忽略大小寫的搜尋？
- 為什麼我的環境在大小寫敏感或不敏感的比較中不符合預期？
- 如何修改設定或 SQL 語句以避免此類問題？
本文將從基礎概念到實務操作，教你如何在 MySQL 中處理大小寫敏感性。我們將介紹常見技術與注意事項，例如排序規則、LOWER()/UPPER() 函式以及 BINARY 屬性。內容不僅對新手有幫助，同時對系統管理員與實務工程師亦很實用。
閱讀完本文後，你將能自信地在 MySQL 中使用「不區分大小寫的搜尋」，並避免資料庫操作或開發設定中的問題。接下來的章節，我們將先從基本層面說明 MySQL 如何處理大小寫敏感性。
2. MySQL 中大小寫敏感性的基礎處理
在 MySQL 中，進行字串比較或搜尋時，大小寫是否被區分並非自動決定。這一行為由排序規則（collation）所控制。排序規則定義了資料庫中字串比較與排序的規則。
2.1 資料庫、資料表與欄位層級的排序規則
在 MySQL 中，你可以分層設定排序規則：資料庫層級、資料表層級以及欄位層級。例如，在建立資料庫時你可以指定預設排序規則，同時也可以為單獨的資料表或欄位覆寫此設定。
如果沒有明確指定，系統將使用全域預設（在許多環境中為 utf8mb4_general_ci 或 latin1_swedish_ci）。這些預設通常導致不區分大小寫的比較（後綴「_ci」代表不區分大小寫）。
2.2 「_ci」與「_cs」的差異
_ci（不區分大小寫）：不區分大寫/小寫_cs（區分大小寫）：區分大寫/小寫
例如，utf8mb4_general_ci 在比較時不區分大小寫，而 utf8mb4_bin（二進位比較）則嚴格區分。
2.3 字串資料型別的注意事項
字串儲存型別（CHAR、VARCHAR、TEXT 等）通常受排序規則設定所支配。相對地，BINARY、VARBINARY 型別以及 BLOB 型別永遠使用二進位比較（即永遠區分大小寫），因此需謹慎處理。
2.4 依作業系統與版本而異的情況
實際上，MySQL 對表名、欄位名等識別子大小寫的處理方式可能因 MySQL 版本及底層作業系統的檔案系統而異。然而，在本文中我們主要聚焦於字串值的比較，而非識別子。
因此，MySQL 的大小寫敏感性處理受排序規則控制，並能在資料庫、資料表及欄位層級靈活設定。
3. 如何實作不區分大小寫的搜尋
為了在 MySQL 中執行「不區分大小寫的搜尋」，你可以靈活運用排序規則或 SQL 語句的修改。本文將說明三種常見且實際可用的方法，並說明其功能與注意事項。
3.1 檢查或更改預設排序規則
在 MySQL 中，許多環境的預設排序規則都是不區分大小寫（_ci）。例如，utf8mb4_general_ci 或 latin1_swedish_ci。
SQL 範例：檢查排序規則
SHOW VARIABLES LIKE 'collation%';
檢查資料表或欄位排序規則的範例
SHOW FULL COLUMNS FROM users;
SQL 範例：更改排序規則
-- Entire database
ALTER DATABASE dbname CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
-- Table level
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
-- Column level
ALTER TABLE users MODIFY username VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
使用這些設定時，正常的 = 與 LIKE 查詢預設會以不區分大小寫的方式進行比較。
3.2 在查詢中使用 COLLATE 子句
若預設校對順序設為區分大小寫（_cs 或 _bin），而你只想在某個特定查詢中臨時執行不區分大小寫的搜尋，可以在 SQL 中指定 COLLATE 子句。
範例：
SELECT * FROM users WHERE username COLLATE utf8mb4_general_ci = 'Sato';
這樣你就能僅為該特定查詢進行「不區分大小寫」的搜尋。當你想避免影響現有資料或專案中的其他功能時，這種方式很有用。
3.3 使用 LOWER() / UPPER() 函式進行比較
另一種做法是利用 LOWER() 或 UPPER() 函式進行比較。將儲存值與搜尋值皆轉成小寫（或大寫），即可達到不區分大小寫的效果。
範例：
SELECT * FROM users WHERE LOWER(username) = LOWER('Sato');
然而，這種方法存在 注意事項。
- 使用此類函式可能阻止索引使用，並降低搜尋速度。
- 當資料表資料量很大時，基於校對順序的解決方案通常在效能上更優。
妥善運用上述方法，即可輕鬆完成 MySQL 的不區分大小寫搜尋。
4. 當需要區分大小寫搜尋時
在許多系統中，若你想在使用者名稱、密碼、產品編號等欄位上嚴格區分大小寫，由於 MySQL 的預設設定通常不區分大小寫，你必須了解幾種方式，才能讓比較或搜尋如預期般運作。
4.1 使用 BINARY 運算子
最簡單的方式是使用 BINARY 運算子。當你套用 BINARY 時，它會將被比較的值視為二進位（即嚴格的位元序列），因此大小寫差異會被明確區分。
範例：
SELECT * FROM users WHERE BINARY username = 'Sato';
此查詢僅會返回使用者名稱欄位精確等於「Sato」的列。像「sato」或「SATO」將不會匹配。
4.2 將欄位的校對順序設定為 _bin 或 _cs
將欄位定義本身改為區分大小寫的校對順序（例如 utf8mb4_bin 或 utf8mb4_cs）即可確保對該欄位的比較始終區分大小寫。
範例：
ALTER TABLE users MODIFY username VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
以這種方式定義的欄位，使用 = 或 LIKE 進行比較時都會嚴格區分大小寫。
4.3 需要區分大小寫搜尋與注意事項
- 密碼、敏感資訊、識別碼 通常需要區分大小寫的搜尋。
- 電子郵件地址或使用者 ID 也可能根據作業規則需要區分大小寫政策（儘管國際標準常將電子郵件本地部分視為區分大小寫，許多系統實際上仍以不區分大小寫為主）。
- 如果你在現有資料庫中更改校對順序，必須備份並徹底測試行為。
4.4 常見問題範例
- 你期望進行區分大小寫比較，但預設校對順序為不區分大小寫，導致意外匹配。
- 應用程式邏輯預期區分大小寫，但資料庫卻以不區分大小寫運作，造成 bug。
- 在遷移或升級過程中校對順序變更，舊資料產生意外行為。
當需要區分大小寫搜尋時，建議使用 BINARY 運算子或正確設定校對順序，並確保資料操作安全且準確。
5. 實務範例與實際應用的注意事項
在 MySQL 執行區分大小寫或不區分大小寫的搜尋與比較時，您需要了解在開發或運維中常見的模式與陷阱。以下從實務角度彙整實際查詢範例、效能考量，以及與多位元字串（如日語）相關的主題。
5.1 LIKE 與 IN 子句的行為
- 對 LIKE 子句 在許多 _ci 校對序列中，透過
LIKE的部分比對同樣是忽略大小寫。
SELECT * FROM users WHERE username LIKE 'S%';
在此情況下，使用者名稱可能是「Sato」、「sato」或「SATO」，都會匹配。
- 對 IN 子句
IN亦根據校對序列進行比較。
SELECT * FROM users WHERE username IN ('Sato', 'sato');
在 _ci 欄位中，「Sato」、「sato」、「SATO」等皆會匹配；而在 _bin 欄位中，則僅對精確相符的值有效。
5.2 索引與效能影響
使用 LOWER()/UPPER() 函式時，在比較上使用
LOWER()或UPPER()常會阻止索引使用，並可能觸發全表掃描。在大量資料的情況下，可能會嚴重降低效能。校對序列與索引使用 具備合適校對序列（_ci 或 _bin）的欄位通常可以正常使用索引。對於需要高效能的環境，請評估欄位定義與查詢設計。
5.3 在現有資料或系統更改校對序列時的注意事項
- 若在資料庫或欄位中途更改校對序列，可能會觸發 索引重建與意外的查詢結果。因此，請務必進行全面驗證與備份。
- 在預備環境中始終進行測試。}
5.4 多位元字串（例如日語）的考量
MySQL 的
utf8mb4_general_ci或utf8mb4_unicode_ci可涵蓋包括日語在內的多語言字元。拉丁字母的大小寫區別將被視為相同。不過，特殊符號或舊版字型可能因校對序列不同而產生不同的比較結果。如果您存儲大量日語資料，建議使用
utf8mb4_unicode_ci並檢討校對序列差異。
5.5 系統遷移或版本升級中的常見問題
升級 MySQL 版本時，預設校對序列或比較演算法可能會發生變化。
在遷移過程中，您可能會遇到類似「行為與先前不同」的問題。請始終參考官方文件，並評估系統各部件的影響。
如此一來，在實務運維中，您不僅要「設定」它，還需考慮 校對序列、查詢設計、效能以及資料遷移問題。尤其在變更現有系統或啟用多語言支援時，請更加謹慎操作。
6. Column】為什麼有些比較是區分大小寫/不區分大小寫？
在 MySQL 中是什麼機制導致「區分大小寫」或「不區分大小寫」的行為？本章說明技術背景及與其他資料庫的差異。
6.1 校對序列如何運作
MySQL 中的字串比較受校對序列規則控制。校對序列定義了字串的比較與排序方式。主要有以下類型：
- _ci (不區分大小寫) : 不區分大寫/小寫。範例：
utf8mb4_general_ci - _cs (區分大小寫) : 區分大寫/小寫。範例：
utf8mb4_0900_as_cs - _bin (二進位) : 二進位比較，嚴格區分。範例：
utf8mb4_bin
在 MySQL 中，由於您可以在欄位、資料表或資料庫層級指定校對序列，相同字串可能因校對序列設定而被區分或不被區分。
6.2 由作業系統或檔案系統（識別符）造成的差異
另有一點需要注意：表格名稱或欄位名稱（識別符）的大小寫敏感性。在 MySQL 中，根據儲存引擎或伺服器作業系統，表格名稱的大小寫敏感性可能不同：
- Linux（多個檔案系統）：區分大小寫（大寫與小寫視為不同名稱）
- Windows（NTFS）：不區分大小寫（大寫與小寫視為相同名稱）
雖然這與識別符相關，而非資料內容，但在系統遷移或開發期間可能成為意外行為的因素。
6.3 MySQL 版本帶來的規格變更
當 MySQL 版本變更時，預設的校對（collation）或比較演算法可能會改變。例如，自 MySQL 8.0 起，Unicode 支援與預設校對比舊版本更嚴格。
6.4 與其他資料庫（PostgreSQL 或 SQL Server）的差異
- PostgreSQL：預設區分大小寫（case-sensitive）。
ILIKE運算子可啟用不區分大小寫搜尋。 - SQL Server：在安裝或建立資料庫時可以詳細指定校對。日文環境中，通常使用不區分大小寫。
因為 每個資料庫處理大小寫的方式不同，在進行系統遷移或與其他資料庫互操作時必須小心。
在 MySQL 中，“區分 / 不區分大小寫”的行為受到多種因素（如校對、作業系統、版本等）決定。透過了解並控制設定與系統配置，可避免意外行為或遷移錯誤。
7. 常見問題（FAQ）
Q1：改變校對會對現有資料產生什麼影響？
A：
若改變校對，該欄位或資料表的「未來字串比較與排序」將會受到影響。資料值本身不會改變，但搜尋結果或排序順序可能與以前不同。此外，索引可能需要重建，進而暫時影響效能。在大型資料庫中，您必須先備份並在測試環境中徹底測試，才可應用至正式環境。
Q2：使用 LOWER() 或 UPPER() 函式時，索引還能使用嗎？
A：
一般而言，當使用 LOWER() 或 UPPER() 時會先轉換欄位值再做比較，導致索引無法被使用。因此，資料量較大時搜尋速度可能會顯著下降。若優先考慮效能，建議改用校對設定或 COLLATE 子句。
Q3：LIKE 子句是不區分大小寫嗎？
A：
對於許多以 _ci 為結尾的校對，使用 LIKE 進行部分比對時亦不區分大小寫。然而，若欄位使用 _bin 或 _cs 校對，則嚴格區分大小寫。請相應確認校對或查詢語境。
Q4：我可以僅為某個欄位設定「不區分大小寫」嗎？
A：
可以。透過在欄位定義中指定 COLLATE 屬性，即可為該欄位套用不同的校對。
範例：
ALTER TABLE users MODIFY username VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
這樣可以讓該欄位使用與其他欄位不同的比較規則。
Q5：不區分大小寫設定適用於日文及多語言資料嗎？
A：
基本上可以。對於日文和其他多語言資料，您可以使用如 utf8mb4_general_ci 或 utf8mb4_unicode_ci 等校對來進行不區分大小寫的比較。然而，請注意，對於某些符號或舊式字元，根據所選校對不同，比較結果可能會有所變化。
Q6：MySQL 5.x 與 8.x 之間在「不區分大小寫」行為上有差異嗎？
A：
有。根據版本，預設校對與 Unicode 支援範圍會不同。在 MySQL 8.0 中，建議使用如 utf8mb4_0900_ai_ci 等校對，且比較行為可能與舊版本不同。升級時，您必須參考官方文件並進行行為測試。
Q7：BINARY 運算子與校對設定之間的差異為何？
A:
BINARY 運算子會暫時強制對該次比較使用二進位（嚴格）比較。相對地，將排序規則設定在欄位或資料表上，則會在該欄位或資料表上始終一致地套用此規則。大體原則是：用 BINARY 做「一次性嚴格比較」，用排序規則設定做「統一的比較規則」。
這份 FAQ 涵蓋了在實際環境中可能遇到的常見問題與疑慮。如有其他疑問，歡迎在文章的評論區提問或直接聯繫我們。
8. 結論
在 MySQL 中，上下寫法的區分是由排序規則彈性控制的。是否「忽略大小寫」或「區分大小寫」取決於作業系統、資料庫設計與資料處理需求。
本文涵蓋：
- MySQL 中大小寫敏感性的基礎知識
- 大小寫不敏感與大小寫敏感的比較方法與設定
- 具體實際範例與注意事項
- 技術背景與其他資料庫的差異
- 常見問題及對應解決方案
由於可以在資料庫、資料表與欄位層級靈活配置排序規則，選擇最適合的方式以符合需求與使用情境是相當重要的。
同時，合理使用 LOWER()/UPPER() 函式、BINARY 運算子及 COLLATE 子句，可避免問題並在實務上更加安全、精確地操作。
最後，在大型系統或版本升級時變更設定，務必先進行測試與備份，並充分驗證後再進行改動。
透過了解並善用排序規則，您可以更安全、更順暢地管理 MySQL。
9. 參考連結與官方文件
若想深入了解 MySQL 的大小寫敏感性或排序規則，或想確認官方規格，以下為可靠資源。
9.1 MySQL 官方文件
9.2 與其他主流資料庫的比較資訊
9.4 註解
- 排序規則或比較行為可能會因 MySQL 版本而異，請務必以您使用的版本為準確認。
- 在大型系統中，可能還有自訂操作規則或例外，建議同時查看內部文件或舊系統規格。
利用官方手冊與可信賴的技術文章深入學習，掌握具體配置方法。
若遇到疑問或問題，希望您能利用上述連結尋找最佳方案。
