字符串比较默认是否区分大小写取决于数据库排序规则；char类型比较前补空格，VARCHAR多数忽略尾部空格；NULL参与比较结果为UNKNOWN；Unicode隐式转换易致索引失效或结果偏差。
字符串比较默认区分大小写吗
不一定，取决于数据库的排序规则（collation）。mysql 默认 utf8mb4_general_ci 是不区分大小写的，而 utf8mb4_bin 或 utf8mb4_0900_as_cs 就区分；postgresql 默认按字节比较（bytea 行为），但文本类型实际使用 LC_COLLATE 设置，通常不区分大小写；SQL Server 则看实例或列的 collation，常见如 SQL_Latin1_General_CP1_CI_AS（CI = Case Insensitive）。
实操建议：
- 用
SHOW COLLATION（MySQL）或pg_collation（PostgreSQL）查当前环境默认行为 - 临时强制区分大小写：MySQL 用
BINARY 'a' = 'A'，PostgreSQL 用'a' = 'A' COLLATE "C"，SQL Server 用COLLATE Latin1_General_BIN - 建表时显式指定 collation，比后期改更可靠
空格和尾部空格怎么处理
SQL 标准规定：在比较前，CHAR 类型会用空格补齐到定义长度，再进行比较；VARCHAR 不补齐，但多数数据库（如 MySQL、SQL Server）在比较时仍会忽略尾部空格 —— 这是陷阱高发区。
常见错误现象：select * FROM users WHERE name = 'alice ' 可能命中 'alice'，即使你没输空格。
实操建议：
- 用
Length()或DATALENGTH()检查实际字节数，确认是否有隐藏空格 - 比较前统一用
RTRIM(LTRIM(col))处理（但注意性能影响） - 避免用 CHAR 存用户输入，优先选 VARCHAR；若必须用 CHAR，插入前手动
RTRIM - MySQL 8.0+ 可开启
pad_char_to_full_length=OFF改变 CHAR 行为
NULL 参与字符串比较的结果总是 UNKNOWN
col = 'abc' 在 col 为 NULL 时不会返回 true，也不会返回 false，而是 SQL 的三值逻辑中的 UNKNOWN —— 所以该行不会出现在 WHERE 结果中，哪怕你预期它“应该匹配”。
容易踩的坑：
-
WHERE col != 'abc'不会包含NULL行（因为NULL != 'abc'是 UNKNOWN，不是 TRUE） -
ORDER BY col DESC中NULL可能排最前或最后，取决于数据库和设置（如 PostgreSQL 默认NULLS LAST，MySQL 默认NULL最小） - 用
COALESCE(col, '') = 'abc'或col 'abc'（MySQL 特有空安全等于）绕过
Unicode 和多字节字符的隐式转换风险
当比较不同编码或不同 Unicode 版本的字符串（比如 MySQL 5.7 的 utf8 实际只支持 BMP，而 utf8mb4 支持 emoji），或跨列比较（如 VARCHAR(10) vs TEXT），数据库可能触发隐式转换，导致索引失效或结果偏差。
典型表现：EXPLaiN 显示 type: ALL（全表扫描），或 emoji 字符被截断成 ? 后参与比较。
实操建议：
- 确保关联字段字符集和 collation 完全一致，用
SHOW FULL COLUMNS FROM tbl核对 - 避免在 WHERE 中对列用函数，如
UPPER(col) = 'ABC'—— 改用带对应 collation 的列或函数索引 - MySQL 中
utf8mb4_unicode_ci对某些德语、法语变音处理不如utf8mb4_0900_as_cs精确，需按业务选
最易被忽略的一点：collation 不仅影响 =，还决定 ORDER BY、GROUP BY、DISTINCT 的行为，且同一查询中多个字段 collation 冲突时，数据库会尝试隐式转换 —— 这类问题往往只在数据量变大或字符变复杂后才暴露。