MySQL单行注释用--加空格，多行注释用/*...*/；--后必须有空格或换行，否则报错；/*...*/支持嵌套但慎用；注释在解析阶段被丢弃，一般不影响性能，但超长注释或含敏感信息可能引发问题。
MySQL单行注释用-- （注意空格）
MySQL里最常用的单行注释是-- ，不是--——末尾那个空格不能少，否则会被当成语法错误或直接忽略。比如写成--SELECT * FROM users;，MySQL会报错ERROR 1064，因为解析器认不出这是注释。
常见错误现象：复制别人代码时漏掉空格，或者用 IDE 自动补全的//（那是 JavaScript/Java 的），结果语句执行失败。
-
--必须紧贴前面的SQL语句，中间可有空格，但后面必须跟空格或换行 - 推荐写法：
SELECT id FROM users; -- 获取用户ID - 不推荐写法：
SELECT id FROM users;--获取用户ID（没空格，可能被忽略） - 在命令行客户端（mysql CLI）中，
#也能单行注释，但不推荐——它在某些配置下不可用，且不兼容标准 SQL
MySQL多行注释用/* ... */，支持嵌套但慎用
/* ... */是标准 SQL 多行注释，MySQL 完全支持，还能嵌套（比如/* outer /* inner */ outer end */），但实际开发中几乎没人靠它做逻辑控制——容易误删、难调试，还可能干扰预处理语句。
使用场景主要是临时屏蔽大段 SQL，比如调试时把INSERT换成SELECT前先注释掉原语句；或者在存储过程里加说明性文字。
- 支持跨行：
/* 这是<br>多行<br>注释 */
（
只是示意，实际换行即可） - 不能出现在字符串内：
SELECT '/* 这不是注释 */' FROM dual;→ 字符串内容原样输出 - 如果嵌套使用，确保配对，否则会报
ERROR 1064（解析到文件末尾都没找到结束符） - ORM 或连接池（如 mysql2、PyMySQL）一般不处理注释，但某些审计中间件会提取
/*+ ... */这类 hint 注释，别乱加星号
注释影响性能吗？基本不影响，但别塞进高频查询
MySQL 在解析阶段就丢弃注释，不会进执行计划，所以EXPLAIN看不出来区别，也不占 buffer pool 内存。但有两个边界情况得留意：
- 超长注释（几 MB）会让网络传输变慢，尤其用 PHP
mysqli或 JDBC 时，整条语句要先发到服务端再解析 - 存储过程/函数定义里的注释会存进
mysql.proc表，虽不执行，但备份恢复时体积略增 - 某些代理（如 ProxySQL）或审计工具会扫描注释内容，含敏感信息（如
/* password=xxx */）可能泄露
不同客户端对注释的处理差异
CLI、DBeaver、Navicat 等工具都支持标准注释，但行为略有不同。比如 MySQL Workbench 默认启用“执行当前语句”，光标在/*块里时可能选中整段而非单条语句；而 VS Code 的 SQL 插件有时会把--后紧跟字母识别为变量名（如--id被高亮成id变量）。
- CLI 中，
--注释必须独占一行或放语句末尾，不能出现在语句中间（如SELECT -- comment id FROM users会报错） - PHP
mysqli::multi_query()要求每条语句以分号结尾，--注释不能断开分号位置，否则只执行前半部分 - Python 的
mysql-connector-python对/* */内换行较敏感，若注释里有未转义的\r\n，可能被误判为语句分隔
注释本身很简单，但混在真实业务 SQL 里时，空格、换行、客户端适配这些细节，往往比语法本身更容易卡住人。
