SQL不自动处理全角/半角差异，需显式转换：可用嵌套REPLACE逐个替换高频字符（限短字段）、利用支持WI的collation实现部分等价匹配（仅标点/空格），或在应用层预归一化（推荐）。
SQL 本身不自动处理全角/半角字符差异，必须显式转换或归一化后再比较。
用 REPLACE 手动替换常见全角字符
多数数据库（如 MySQL、PostgreSQL、SQL Server）不内置“全角转半角”函数，最直接的方式是逐个 REPLACE 替换高频全角字符。适用于字段值较短、全角字符种类有限的场景（比如用户输入的姓名、手机号、邮箱前缀）。
常见需替换的全角字符包括： （全角空格）、，、。、！、？、；、：、“、”、‘、’，以及全角数字 ０-９ 和字母 Ａ-Ｚａ-ｚ。
示例（MySQL）：
SELECT * FROM users WHERE REPLACE(REPLACE(REPLACE(name, ' ', ' '), '，', ','), '。', '.') = '张三';
注意：REPLACE 是嵌套执行的，顺序无关，但每层只替换一种字符；嵌套过深会影响可读性和性能，建议控制在 5–7 层以内。
- 别忘了全角 ASCII 标点和空格——它们看起来像空格或逗号，但
LENGTH()返回值不同 - 全角数字/字母需单独替换，例如
REPLACE(name, '０', '0')，不能靠 collation 解决 - 如果字段有索引，这种写法必然导致索引失效，大数据量时慎用
用 collation 实现半角/全角等价匹配（仅限部分字符）
某些数据库的 collation（排序规则）支持“宽度不敏感”（width-insensitive），例如 SQL Server 的 _CI_AI_WI 后缀，或 MySQL 8.0+ 的 utf8mb4_0900_as_cs（含宽度感知）。但实际支持范围有限：通常只对 ASCII 标点和空格有效，对全角数字/字母仍不识别为等价。
以 SQL Server 为例：
SELECT * FROM products WHERE product_name COLLATE Japanese_CI_AS_WI = N'abc ';
这里 WI（width-insensitive）会让全角空格 和半角空格 被视为相同。
- 不是所有 collation 都带
WI，需查文档确认当前数据库支持的选项 - MySQL 的
utf8mb4_unicode_ci不处理宽度差异；utf8mb4_0900_as_cs也不等价全角/半角数字 - 即使启用 WI，
WHERE子句中显式指定 collation 可能阻止索引使用，除非列本身定义了该 collation
在应用层预处理比在 SQL 中硬扛更可控
把全角转半角逻辑交给应用代码（Python、Java、Go 等），查询时传入已归一化的值，是最稳定、可测试、易维护的做法。
例如 Python 中用 unicodedata + 映射表做轻量转换：
# 简化版全角转半角（仅覆盖常用字符）
def full2half(s):
s = s.replace(' ', ' ')
for i in range(0xFF01, 0xFF5F): # 全角！-～
s = s.replace(chr(i), chr(i - 0xFEE0))
return s
<p>name_normalized = full2half(user_input)
cursor.execute("SELECT * FROM users WHERE name = ?", name_normalized)- 避免 SQL 层复杂字符串操作，降低数据库 CPU 压力
- 可统一处理边界情况（如混合全半角、不可见字符、emoji 干扰）
- 若业务要求“模糊搜索”，后续还可扩展为拼音转换、简繁转换等，SQL 很难支撑这类组合逻辑
真正麻烦的不是空格或逗号，而是用户随手打出的全角数字 １２３ 和半角 123——它们 Unicode 编码差 0xFEE0，但 collation 几乎都不认为二者相等。这时候，要么在入库时就归一化存储，要么在查询前强制转换，没有银弹。
