结论：单行用--（后必须跟空格），多行用/ /（必须成对、不可嵌套、不能跨独立语句）；--优先级高于/ /，混用时--吞整行剩余，/ /吞至最近/；漏空格或漏/将导致语法错误或逻辑失效。
直接说结论：单行用 --（后面必须跟空格），多行用 /* */（必须成对、不可嵌套、不能跨独立语句），二者混用时注意优先级——-- 会吞掉它所在行的剩余部分，/* */ 会吞掉从 /* 到最近的 */ 之间的所有内容，包括换行。
单行注释 -- 的写法和常见失效原因
-- 看似简单，但实际执行失败往往是因为格式不对。它不是“两个短横线”就完事，而是要求后面**紧跟一个空格或制表符**（部分新版 MySQL 允许紧贴，但 PostgreSQL、SQL Server、Azure Databricks 严格校验）。一旦漏空格，数据库可能把它解析成操作符或标识符的一部分。
-
--WHERE active = 1→ 注释不生效，条件仍执行 -
SELECT id--no space hereFROM users;→ 报错：syntax error at or near "--" -
-- 这是合法注释✅（空格在--后） -
SELECT 1; -- 获取常量✅（空格在--后，且只影响本行） - 换行后注释自动结束，
--不延续到下一行
多行注释 /* */ 的安全写法与致命陷阱
/* */ 能跨行、能插在语句中间，但规则更硬：必须成对出现；不能嵌套；*/ 一旦出现，不管前面有没有引号或转义，都会立刻终止注释。
- 漏写结尾
*/→ 后续所有 SQL 都被注释掉，执行返回空结果或报语法错误 -
'abc */ def'出现在注释里 →*/仍会提前关闭注释，导致后续 SQL 解析错乱 -
/* SELECT * FROM t1; */ SELECT * FROM t2;✅（/* */是一个完整块，不影响后面语句） -
SELECT /* col1, col2 */ name FROM users;✅（可插在语句中间） - SQLite 默认不支持
/* */，除非编译时启用了ENABLE_COMMENT
-- 和 /* */ 混用时谁管谁？
它们不是并列关系，而是有明确优先级：-- 优先于 /* */。也就是说，只要某行以 -- 开头（且满足空格要求），整行剩余部分就归它管，/* 在这行里完全无效；反过来，在 /* */ 块内写 --，它只是普通字符，不会触发单行注释逻辑。
-
-- /* 这个 /* 不开启块注释 */→ 整行被--吃掉，/*不起作用 -
/* SELECT 1; -- 这个 -- 只是字符串 */ SELECT 2;→--不生效，整个/* */块被忽略 -
/* comment -- 这里写 -- 没问题 */✅（--在块内，纯文本） -
/* comment */ -- 这才是真正的单行注释✅（块结束后，--生效）
不同数据库对注释的支持差异
别默认“写了就能跑”。同一个注释写法，在不同系统里可能直接报错或静默忽略。
- MySQL：支持
--、/* */、#；--空格要求已放宽，但老版本（如 5.6）仍建议加 - PostgreSQL / SQL Server：只认
--（必须空格）和/* */；不支持# - SQLite：默认禁用
/* */，需编译选项启用；--可用 - Azure Databricks：
--和/* */都支持，但注释若含 EOL 字符（比如换行没写在/* */内），会报错
最易被忽略的点：注释不是写给人看就完了，它直接影响 SQL 解析器的行为边界。漏一个 /、多一个 *、在引号里误写 */，都可能导致整段查询逻辑崩掉——而且错误位置可能离你写的注释差十几行。写完务必检查配对、空格、数据库兼容性，而不是等执行报错才回头找。
