mysql字符串比较是否区分大小写取决于字段排序规则，utf8mb4_general_ci不区分，utf8mb4_bin或utf8mb4_0900_as_cs区分；可用binary前缀或collate指定临时改变行为，但binary可能跳过索引。

MySQL 中用 BINARY 或 COLLATE 强制大小写敏感匹配

默认情况下，MySQL 的字符串比较是否区分大小写，取决于字段的排序规则（COLLATION）。比如 utf8mb4_general_ci 是不区分大小写的，而 utf8mb4_bin 或 utf8mb4_0900_as_cs 才是区分的。直接在查询里改行为更灵活，不用动表结构。

常见做法是临时加 BINARY 前缀或用 COLLATE 指定：

• WHERE BINARY username = 'Admin' —— 简单粗暴，但会跳过索引（除非该列本身是 BINARY 类型）
• WHERE username COLLATE utf8mb4_0900_as_cs = 'Admin' —— 更规范，且在支持的 collation 下可能走索引
• 如果字段已有 utf8mb4_bin collation，= 本身就区分大小写，无需额外修饰

PostgreSQL 默认区分大小写，但 ILIKE 和 LOWER() 容易误用

PostgreSQL 的 = 操作符天生区分大小写，这点和 MySQL 相反。很多人习惯性加 LOWER() 来“统一处理”，但要注意性能陷阱：

• WHERE LOWER(name) = 'alice' —— 无法使用 name 上的普通 B-tree 索引，除非建函数索引：CREATE INDEX idx_name_lower ON users (LOWER(name));
• WHERE name ILIKE 'alice' —— 语义等价于上面的 LOWER()，但底层实现不同；同样不走普通索引，且 ILIKE 不支持前缀匹配优化（如 ILIKE 'ali%' 不能高效利用索引）
• 真要模糊+大小写不敏感，优先考虑 pg_trgm 扩展 + GIN 索引，而不是硬套 LOWER()

SQL Server 的 COLLATE 语法最显式，但也最容易漏掉隐式转换

SQL Server 允许在任意表达式后追加 COLLATE，例如：

WHERE username COLLATE SQL_Latin1_General_CP1_CS_AS = 'Admin'

注意两点：

• CS_AS 表示 Case-Sensitive + Accent-Sensitive；若只要大小写敏感、允许重音一致，用 CS_AI
• 如果比较的两边 collation 冲突（比如一列是 CI，另一侧硬写 CS），SQL Server 会尝试隐式转换，可能报错 Cannot resolve collation conflict；此时必须显式给两边都加 COLLATE，或用 CONVERT(VARCHAR, ...) 绕过
• 临时表或变量的 collation 默认继承数据库级设置，容易和主表不一致，查不出数据时先检查这个

跨数据库可移植写法几乎不存在，别指望 UPPER() 能解决所有问题

有人想“统一用 UPPER(col) = UPPER('input')”，看似安全，实则埋雷：

• 某些字符在不同语言下大写规则不同（比如土耳其语的 i → İ），UPPER() 结果不可靠
• 索引失效是通病：几乎所有主流数据库都无法对带函数的左值高效索引，除非你主动建函数索引（且各库语法不同）
• JSON 字段、XML 内容、全文检索场景下，大小写逻辑由解析器控制，SQL 层的 UPPER() 可能根本没机会介入

真正关键的是：明确你的字段原始 collation / encoding，再决定是在建表时固化（推荐长期项目），还是在查询时动态干预（适合临时适配）。混用方式最容易在迁移或升级后突然失效。