单引号必须用于字符串和日期值，双引号仅在必要时用于对象名（如列名、表名）；混用会直接报错而非风格问题。where子句中字符串值必须用单引号，如where name = 'alice'；数值类型不加引号，如where id = 123；日期字符串须用单引号，如where created_at = '2025-06-01'；双引号仅用于含空格、特殊字符或保留关键字的对象名，如select "user name" from employees。
单引号必须用于字符串和日期值，双引号仅在必要时用于对象名（如列名、表名）——混用会直接报错，不是风格问题，而是语法错误。
WHERE子句中字符串值必须用单引号
任何字符串类型的条件值，比如姓名、状态码、分类标签，都得包在单引号里。数据库不会自动帮你补，漏了或用了双引号，轻则查不到数据，重则抛 ORA-00904 或 Unknown column 错误。
-
WHERE name = 'Alice'✅ 正确 -
WHERE name = "Alice"❌ Oracle/SQL Server 报错；MySQL 在默认模式下可能“容忍”，但属非标准行为 -
WHERE id = 123✅ 数值类型不加引号（加了反而可能触发隐式转换，影响索引使用） -
WHERE created_at = '2025-06-01'✅ 日期字符串必须单引号 -
WHERE created_at = 2025-06-01❌ 被解析成减法表达式，结果是2018，类型完全错乱
双引号只用于标识符，且仅当无法避免时才用
双引号不是“另一种引号选项”，它是 SQL 标准里专门留给对象名的逃生通道。日常写 SELECT name FROM users 完全不需要它；一旦你写了 SELECT "Name" FROM "Users"，就等于主动开启大小写敏感和精确匹配模式——后续所有引用都得严格一致。
-
SELECT "user name" FROM employees✅ 列名含空格，必须双引号 -
SELECT "order" FROM sales✅order是保留字，不加双引号会语法报错 -
SELECT "NAME" FROM EMP✅ Oracle 中若建表时用了"NAME"，这里就必须大写+双引号 -
SELECT name FROM "EMP"⚠️ 表名用双引号后，emp或Emp全部失效，大小写锁死 -
WHERE "id" = 'abc'❌ 滥用：id 是普通列名，无特殊字符也非关键字，加双引号纯属增加维护负担
拼接SQL时引号嵌套极易出错
像 "SELECT * FROM t WHERE id = '" + id + "'" 这类字符串拼接，单引号位置一错就整个语句崩。更危险的是，如果 id 变量内容含单引号（如 O'Brian），不转义直接拼进去，SQL 就提前截断，还可能被注入。
- 手动转义需把
'替换为''（两个单引号），例如O'Brian → O''Brian - 但别自己写转义逻辑——
PreparedStatement/parameterized query才是正解，WHERE id = ?后绑定值，彻底绕过引号管理 - 若真要拼（如动态生成DDL），优先用双引号包裹整个SQL字符串（编程语言层），内部SQL用单引号，避免三层嵌套：
"SELECT * FROM t WHERE name = '" + name.replace("'", "''") + "'"
不同数据库对双引号的支持差异很大
MySQL 默认用反引号 ` 包对象名，双引号行为取决于 ANSI_QUOTES SQL 模式；PostgreSQL 和 Oracle 严格按标准用双引号；SQL Server 更习惯方括号 [name]。跨库迁移时，双引号是最容易翻车的兼容性雷区。
- Oracle 中
"my_col"和my_col是两个不同的列名（后者等价于"MY_COL"） - MySQL 开启
ANSI_QUOTES后，"col"才是标识符，'col'才是字符串；关闭时两者都算字符串 - 写通用 SQL 时，避开大小写、空格、关键字命名，就能基本不用双引号
最常被忽略的一点：引号错误往往不报“引号错”，而报“列不存在”“无效标识符”“缺少右括号”——因为解析器在错位处已彻底迷失。调试时先盯紧单引号是否成对、是否包住了该包的内容，再查双引号是否多余或大小写不匹配。
