MySQL默认是否区分大小写完全取决于字段COLLATION：_ci结尾（如utf8mb4_unicode_ci）则不区分，_bin或_cs结尾则区分；查SHOW FULL COLUMNS FROM users LIKE 'name'可确认当前规则。
MySQL 默认对数据内容是否区分大小写，完全取决于字段的 COLLATION，不是数据库本身“默认区分”，也不是 SQL 语句写法决定的。只要字段用的是 _ci（case-insensitive）结尾的校对规则（如 utf8mb4_unicode_ci），查询天然就不区分大小写；反之，若用了 utf8mb4_bin 或 utf8mb4_0900_as_cs，哪怕查 'admin' 也匹配不到 'ADMIN'。
怎么确认字段当前用的是什么 collation？
别猜，直接查：
SHOW FULL COLUMNS FROM users LIKE 'name';
看输出里的 Collation 列。如果是 utf8mb4_bin 或带 _cs 的，就一定是区分大小写的；_ci 结尾的才不区分。
常见错误现象：SELECT * FROM users WHERE name = 'Alice'; 查不到表里明明存在的 'alice' —— 八成就是这个字段用了 _bin 校对规则。
临时让一次查询不区分大小写（推荐新手先用）
不用改表结构，不锁表，不影响索引，最安全的补救方式。在 WHERE 条件中显式加 COLLATE：
SELECT * FROM users WHERE name COLLATE utf8mb4_unicode_ci = 'ALICE';- 多字段拼接时也适用：
WHERE CONCAT(first_name, ' ', last_name) COLLATE utf8mb4_unicode_ci LIKE '%john%'; - 注意：
UPPER(name) COLLATE utf8mb4_unicode_ci会报错，必须写成(UPPER(name)) COLLATE utf8mb4_unicode_ci，但更稳妥的做法是把COLLATE放在原始字段上，避免函数干扰排序逻辑
建表或改字段时设对 collation（一劳永逸但有风险）
如果字段长期需要不区分大小写，应该从源头固定校对规则：
- 新建表时明确指定：
name VARCHAR(50) COLLATE utf8mb4_unicode_ci，不要依赖默认值 - 修改现有字段：
ALTER TABLE users MODIFY name VARCHAR(50) COLLATE utf8mb4_unicode_ci; - ⚠️ 风险点：大表执行该语句可能触发全表重建（尤其 MySQL 5.7 及以前），锁表时间长；若字段已有索引，虽然索引仍可用，但排序行为变化可能导致范围查询结果微调
- 确认可用的
_ci规则：SHOW COLLATION WHERE Charset = 'utf8mb4' AND Collation LIKE '%ci%';
为什么不能只靠 lower_case_table_names？
lower_case_table_names 只控制**表名、库名**是否区分大小写，和**字段值的比较行为完全无关**。它在 Linux 上默认是 0，设成 1 后能让 SELECT * FROM Users; 和 SELECT * FROM users; 都生效，但对 WHERE name = 'Tom' 是否匹配 'tom' 没有任何影响。
这个参数还极难热修改：MySQL 8.0+ 要求它必须在初始化时设定，运行中改会导致启动失败；Linux 下改完还得删数据目录重初始化——代价远超单纯调字段 COLLATION。
