mysql关键字不区分大小写，但推荐全大写以提升可读性；表名等标识符是否区分大小写由lower_case_table_names参数决定；字段内容大小写敏感性取决于collation；别名在linux下区分大小写。
SQL 关键字（如 select、WHERE、JOIN、GROUP BY）在 MySQL 中不区分大小写——无论你写成 select 还是 SELECT，执行效果完全一样。
但这只是表象。真正影响你日常开发的，不是“能不能用小写”，而是“要不要统一”以及“在哪种场景下大小写会突然咬你一口”。
为什么关键字不敏感，但你还得大写？
MySQL 解析器确实对关键字大小写无感，但人不是解析器。团队协作、代码审查、日志排查时，混着写 select、From、whEre 会显著拉低可读性。更关键的是：大小写风格一旦和操作系统/配置耦合，就容易翻车。
- Linux 下默认
lower_case_table_names=0，表名User和user是两个不同对象 - 但如果你写
SELECT <em> FROM User</em>，却在代码里拼成select from user（小写），查不到数据还报Table 'db.user' doesn't exist - 此时问题看似是“关键字大小写”，实际是“表名大小写 + 你的 SQL 拼写不一致”共同导致
所以推荐：关键字全大写，数据库/表/字段名全小写加下划线（如 user_profile）。这是跨平台最稳的约定。
哪些名字真·区分大小写？看 lower_case_table_names
这个参数决定 MySQL 怎么对待数据库名、表名、别名——它不控制关键字，只控制「标识符」（identifier）。
SHOW varIABLES LIKE 'lower_case_table_names';-
0（Linux 默认）：严格区分大小写。CREATE TABLE MyTable和mytable是两个表 -
1（windows 默认）：全部转小写存储+查找，MyTable自动变成mytable -
2（macos 默认）：按原样存，但查找时转小写比对
⚠️ 注意：MySQL 8.0 起禁止在初始化后修改该值。想从 0 改成 1？必须清空 /var/lib/mysql 并重装实例——生产环境基本不可行。
字段内容大小写敏感？靠 COLLATE，不是关键字
很多人以为 WHERE name = 'Alice' 查不到是因为关键字写了小写，其实根本不是。真正起作用的是字段的校对规则（collation）：
-
utf8mb4_general_ci：默认，'alice'和'Alice'视为相等 -
utf8mb4_bin或utf8mb4_0900_as_cs：区分大小写，'A'≠'a'
ALTER TABLE users MODIFY COLUMN name VARCHAR(50) COLLATE utf8mb4_bin;- ✅ 建表时指定更稳妥：
name VARCHAR(50) COLLATE utf8mb4_bin - ❌ 查询时临时加
BINARY name = 'Alice'会让索引失效，慎用 - ⚠️ 修改 collation 可能触发全表重建，大数据量表要评估停机时间
最容易被忽略的坑：字段名不敏感，但别名敏感
字段名（如 user_id）在所有平台都不区分大小写，但表别名、列别名、变量名，在 Linux 下是严格区分大小写的：
SELECT u.id FROM users AS u; -- OK SELECT U.id FROM users AS u; -- 报错：Unknown column 'U.id'- 同样，
@counter和@Counter在 Linux 下是两个不同用户变量 - Windows 下这些也都不敏感，所以本地开发没问题，一上生产（Linux）就炸
解决方案很简单：别名一律小写，且避免仅靠大小写区分不同别名（比如不用 t1 和 T1 表示两个表）。
MySQL 的大小写问题从来不是语法题，而是部署环境、配置参数、命名习惯三者叠加的结果。最省心的做法：开发阶段就用 Linux 环境 + lower_case_table_names=0 + 全小写标识符 + 全大写关键字 —— 这样上线前基本不会踩到“怎么本地好好的，服务器就找不到表”的坑。