在MySQL中添加注释有三种方式：使用/*…*/进行多行或单行注释，–（后跟空格）用于单行注释，#也支持单行注释；其中/*…*/最灵活，可用于语句中间或禁用代码块，–符合SQL标准且通用，#则常见于Shell风格；注释能提升代码可读性与维护性，解释“为什么”而非“是什么”，避免冗余并保持更新；尽管注释会轻微增加解析负担，但对执行性能无实质影响，因其在解析阶段即被忽略，不影响执行计划。
在MySQL的SQL语句中添加注释，主要有三种方式：使用C风格的
/* ... */
进行多行或单行注释，以及使用
--
（注意后面有一个空格）或
#
进行单行注释。这几种方式各有特点，能有效提升代码的可读性和维护性。
解决方案
在MySQL的SQL语句中，你可以根据需要选择不同的注释风格。
最常见且灵活的是C风格的多行注释
/* comment */
。这种方式不仅可以跨越多行，也能用于单行，甚至在语句的中间部分插入注释，比如：
SELECT /* 这是一条查询语句 */ user_name, email FROM users /* 从用户表获取数据 */ WHERE status = 'active';
对于单行注释，我个人更偏爱使用
--
（两个连字符后跟一个空格）。这种方式符合SQL标准，并且在很多数据库系统中都通用：
SELECT user_name, email -- 获取用户的姓名和邮箱 FROM users WHERE status = 'active'; -- 只查询活跃用户
还有一种单行注释方式是使用
#
符号，这在Shell脚本中也很常见，MySQL也支持：
SELECT user_name, email # 获取用户的姓名和邮箱 FROM users WHERE status = 'active'; # 只查询活跃用户
实际使用时，我通常会根据注释的长度和位置来选择。如果是一段解释性文字，或者需要暂时禁用一段SQL，
/* ... */
就显得非常方便。而对于行末的简单说明，
--
或
#
则是简洁明了的选择。
为什么在SQL中添加注释如此重要？
说实话，我见过太多没有注释的SQL代码，那简直是一场灾难。你可能会觉得写SQL很简单，逻辑一眼就能看明白，但相信我，三个月后，甚至仅仅是下周，当你重新审视自己写的复杂查询时，如果没有注释，你可能就会陷入沉思：“这部分是干嘛的？那个条件为什么这么写？”
在我看来，注释不仅仅是为了“解释代码”，它更是为了沟通。沟通什么？沟通你的意图。一个好的注释，能清楚地说明这段SQL的业务逻辑、它解决了什么问题、为什么选择这种实现方式，甚至是可能存在的潜在风险或优化方向。这对于团队协作至关重要。新来的同事接手项目，看到清晰的注释，能更快地理解业务逻辑，减少犯错的几率。即使是你自己，当需要调试或修改旧代码时，注释也能迅速帮你找回当时的思路。
更深层次一点，注释还是代码文档的一部分。它避免了你需要去翻阅外部文档才能理解SQL的窘境。当SQL语句变得复杂，比如涉及多个JOIN、子查询、或者使用了窗口函数时，注释就如同黑暗中的灯塔，指引着你理解其内部的“蜿蜒曲折”。没有注释的SQL，就像一本没有目录、没有页码的书，你得从头到尾仔细读，才能找到你想要的信息，效率低下且容易出错。
不同注释风格的选择与最佳实践是什么？
选择哪种注释风格，其实有点像选择写字的笔，各有各的顺手之处。我个人在日常工作中，会根据不同的场景和团队约定来决定。
对于多行注释或禁用代码块，
/* ... */
是不二之选。比如，我需要暂时移除一段
WHERE
条件，或者想详细解释一个复杂子查询的逻辑，它就能派上用场：
SELECT product_name, price FROM products WHERE category_id = 101 /* AND is_active = TRUE -- 暂时不启用这个条件，为了测试数据完整性 */ ORDER BY price DESC;
这种方式的优势在于它非常显眼，而且可以轻松地注释掉一大段SQL，进行调试。
而对于单行注释，我更偏向于使用
--
（注意，后面那个空格是关键，没有空格可能会导致语法错误或被误解为SQL的一部分）。这种风格是SQL标准的一部分，跨数据库兼容性好，而且看起来比较“干净”：
SELECT user_id, -- 用户唯一标识 user_name, -- 用户名 registration_date -- 注册日期 FROM users WHERE status = 'active'; -- 仅查询状态为活跃的用户
至于
#
符号，虽然MySQL支持，但我用得相对较少，因为它在其他SQL方言中可能不被支持，或者容易与Shell脚本的注释混淆。不过，如果团队有约定或者个人习惯，用它也无妨。
最佳实践方面，我总结了几点：
- 保持一致性：无论选择哪种风格，在一个项目或一个团队内部，最好保持注释风格的一致性。这能让代码看起来更整洁，也更容易阅读。
- 解释“为什么”，而非“是什么”：注释不应该重复SQL语句本身已经表达的“是什么”（比如
SELECT user_name
不需要注释“选择用户名”），而是应该解释“为什么”要这么做，背后的业务逻辑或设计考量。
- 避免冗余：过于简单的SQL语句，如果注释比语句本身还长，那可能就有点冗余了。注释应该精炼，切中要害。
- 及时更新：最糟糕的注释是过时的注释。当SQL逻辑发生变化时，务必同步更新相关的注释，否则误导性注释的危害比没有注释更大。
- 为复杂逻辑添加注释：特别是在涉及多表联接、复杂聚合、子查询或存储过程时，详细的注释能极大地提升可读性。
注释会影响SQL语句的性能吗？
这是一个非常常见的问题，尤其是在追求极致性能的数据库环境中。我的经验和理解是：通常情况下，SQL注释对语句的运行时性能影响微乎其微，几乎可以忽略不计。
这是因为数据库管理系统（DBMS）在执行SQL语句之前，会有一个解析（parsing）阶段。在这个阶段，SQL解析器会读取并理解你的SQL代码。注释在解析阶段就会被识别出来并移除，它们不会被编译成任何可执行的代码，也不会被发送到数据库引擎的执行计划中。
想象一下，你写了一篇论文，其中有很多批注和修改痕迹。当这篇论文最终提交并印刷时，所有的批注都会被清除，只留下最终的文本。SQL注释也是类似，它们是给人类读者看的“批注”，而不是给数据库机器执行的指令。
所以，无论你的SQL注释有多长，有多少行，它们都不会增加SQL语句的执行时间。它们只会在SQL语句被解析时稍微增加一点点解析器的工作量。但是，现代数据库的解析器效率非常高，这点额外的开销与实际的查询执行时间（比如磁盘I/O、CPU计算、网络传输等）相比，几乎可以忽略不计。
因此，我总是建议大家大胆地、充分地使用注释，不要担心它会拖慢你的数据库。可读性和可维护性带来的长期效益，远远超过那点理论上微不足道的解析开销。当然，这并不是说你可以写无限长的废话注释，简洁明了依旧是原则。