sql中带下划线的列名报错主因并非下划线本身，而是列名含保留字、空格、大小写混用或数字开头却未用标识符包裹；mysql用反引号（user_name），postgresql/sql server等用双引号（"user_name"）或方括号（[user_name]），单引号或反斜杠均无效。
SQL中带下划线的列名为什么报错
不是列名本身含_导致报错，而是你用了保留字、含空格、大小写混用或以数字开头的列名，却没加标识符包裹。比如order、user_name（某些方言里user是保留字）、2nd_id，直接写SELECT user_name FROM t在 PostgreSQL 或 SQL Server 会失败。
不同数据库对列名转义的语法差异
没有统一的“转义符”，各数据库用不同符号包裹标识符：
- MySQL：用反引号
`user_name`（注意不是单引号） - PostgreSQL / SQL Server / Oracle：用双引号
"user_name"（区分大小写） - SQL Server 还支持方括号：
[user_name] - SQLite：双引号或方括号都行，但推荐双引号
"user_name"
错误示例：SELECT 'user_name' FROM t —— 单引号是字符串字面量，不是标识符；SELECT \_user_name FROM t —— 反斜杠不是标准 SQL 转义方式，多数引擎直接报错。
关联查询中别名和ON条件里的下划线列名怎么写
只要列名需要被识别为标识符（而非字符串或关键字），就得统一加包裹符号，且必须前后一致：
- 表别名本身不含特殊字符时无需包裹，如
FROM users u - 但如果别名是
order，就得写FROM users "order"（PostgreSQL） - ON 条件中涉及的列，如
ON u."user_id" = o."order_id"，两边都要包裹 - 使用函数或表达式时，别名若含
_也要包裹：SELECT COUNT(*) AS "total_count" FROM t
常见坑：SELECT u.user_name FROM users u 在 MySQL 中可能成功（如果user_name不是保留字），但换到 PostgreSQL 就失败——因为默认不加引号时，PostgreSQL 把它转成小写user_name，而你建表时用"User_Name"创建的列就查不到。
建表时就规避问题最省事
与其每次查询都加引号，不如建表时遵守简单命名规范：
- 全小写 + 下划线分隔：
user_id、created_at（PostgreSQL/MySQL 默认行为友好） - 避开保留字：用
usr_name代替user_name，或查对应数据库的保留字列表 - 不要用数字开头：
id_2024可以，2024_id必须包裹
一旦用了双引号建表（如CREATE TABLE t ("User_ID" INT)），后续所有引用都得严格匹配大小写和引号，漏一个就column "user_id" does not exist。
