必须用反引号的情况包括：字段或表名是MySQL保留字（如order）、含空格或连字符（如user-name）、含中文、或以数字开头（如2nd_name）；否则可能报错或解析异常。
MySQL 中字段名和表名加不加反引号 `，取决于名字是否符合「标识符命名规则」——不是必须，但加了更安全；不加时一旦撞上保留字或含特殊字符，就会报错。
哪些情况必须用反引号
当名字是 MySQL 保留字、含空格、连字符、中文、或以数字开头时，不加反引号会直接报错或行为异常：
-
SELECT * FROM order→ 报错，order是保留字 -
SELECT name-age FROM user→ 语法错误，name-age被解析为减法 -
SELECT 2nd_name FROM user→ 报错，以数字开头的标识符不被接受（除非加反引号） -
SELECT `order`, `user-name`, `2nd_name` FROM `user`→ 全部合法
不加反引号也能用的常见场景
纯字母、下划线、数字（不开头）、长度在 64 字符内、且非保留字的名字，可以省略反引号：
Django Unfold
下载
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
-
user_id、created_at、is_active→ 安全，可不加 -
users、orders、product_detail→ 合法表名，不加也行 - 但注意：
group、desc、interval看似普通，实为保留字，不加就报错
反引号对性能和兼容性没影响，但有隐性成本
加反引号本身不拖慢查询，也不影响执行计划，但它带来两个实际问题：
- 写 SQL 时多敲两下，尤其嵌套子查询或 JOIN 多表时，容易漏掉某个
` - 部分 ORM（如 Django 的 raw SQL）或迁移工具（如 Flyway）对反引号支持不一致，可能引发解析失败
- 团队协作中若风格不统一，有人加有人不加，代码 Review 成本上升，比如
`user`.`name`和user.name混用
SELECT `user`.`id`, `user`.`name`, COUNT(`order`.`id`) AS `order_count` FROM `user` LEFT JOIN `order` ON `user`.`id` = `order`.`user_id` WHERE `user`.`status` = 'active' GROUP BY `user`.`id`, `user`.`name`;
真正麻烦的不是语法本身，而是「你以为它安全，结果上线后某天因为 MySQL 升级新增了保留字，或者 DBA 建了个叫 range 的表，查询突然崩了」——这种问题不会在本地测出来，只在生产环境冒头。
