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 字符内、且非保留字的名字，可以省略反引号：
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的表，查询突然崩了」——这种问题不会在本地测出来，只在生产环境冒头。
