← Все курсы · Курс SQL · Все руководства

Синтаксис комментариев SQL по базам данных

Символ комментария в MySQL, PostgreSQL, SQL Server, SQLite и Оракул и четыре различия, которые нарушают запрос при его перемещении · Часть Analyst Prep Kit

К Майкл Носито, аналитик данных · Опубликовано 11 августа 2026 г.

Две формы комментариев являются частью самого языка SQL и работают в каждой базе данных, которую вы, вероятно, откроете. Все остальное — местный диалект. На этой странице представлена ​​таблица того, что и где работает, а также несколько различий, о которых стоит знать.

Стол

Если вы напишете только -- с пробелом после него и /* */ что вы всегда закрываете, ваши комментарии сохранятся при каждом перемещении между этими пятью. Вот и все правило переносимости.

Почему кто-то спрашивает об одном персонаже

В викторинах и практических экзаменах по MySQL возникает вопрос, сформулированный примерно так: какой одиночный символ можно использовать для закомментирования остальной части строки в MySQL?

Ответ: #.

SELECT 1+1;   # this runs to the end of the line
SELECT 1+1;   -- so does this, but that is two characters

Вопрос в тестировании одного. MySQL имеет три формы комментариев, и только одна из них представляет собой один символ. -- это два. /* равен двум и нуждается в закрывающей паре. # один, поэтому # это ответ.

Стоит знать для викторины и стоит игнорировать впоследствии. # является маркером комментария в MySQL и МарияДБ и нигде больше, поэтому полный их запрос перестает быть комментарием в тот момент, когда он попадает в PostgreSQL. Использовать -- во всем, что вы можете использовать повторно.

MySQL более строг в отношении -- чем все остальные

Это стоит людям реального времени, потому что ошибка не имеет смысла, пока вы не знаете правило.

MySQL требует пробелов после второго тире. В его документации четко указано, что стиль двойного тире требует второго тире, за которым следует хотя бы один пробел или управляющий символ, например пробел или табуляция. Так:

-- this is a comment in MySQL
--this is a syntax error in MySQL

Почти каждая другая база данных принимает оба варианта. Вот почему сценарий, написанный на SQL Server или SQLite, может завершиться неудачей при первом запуске в MySQL в строке, которая явно выглядит как комментарий.

Исправление — это привычка, а не поиск. Всегда ставьте пробел после двух тире. В любом случае это читается лучше, и этот вопрос больше никогда не возникает.

PostgreSQL — единственный, где блоки вложены друг в друга.

Почти в каждом руководстве вам будет сказано, что блочные комментарии не являются вложенными, и почти для каждой базы данных это верно. Первый */ закрывает блок, что бы ни было до него, поэтому остается ненужный код:

/* outer /* inner */ this part is now code */

PostgreSQL ведет себя иначе. В его документации указано, что блочные комментарии вложены, как указано в стандарте SQL, но в отличие от C, так что вы можете комментировать большие блоки кода, которые могут уже содержать блочные комментарии. В Постгрес строка выше полностью скрыта, поскольку внешняя /* ждет своего соответствия */.

Это действительно полезно, когда вы хотите отключить часть запроса, в которой уже есть блочные комментарии. Это также ловушка, потому что SQL, зависящий от него, ломается в тот день, когда кто-то запускает его где-нибудь еще. Если запрос может переместиться, прокомментируйте это растяжение с помощью -- вместо этого в каждой строке, что составляет одно нажатие клавиши в каждом редакторе.

SQLite не сообщит вам, что блок открыт

Забудьте */ в большинстве баз данных, и вы получаете ошибку. SQLite ничего вам не дает.

В его документации говорится, что комментарий в стиле C распространяется на следующий */ пары или до конца ввода, в зависимости от того, что наступит раньше. Незавершенный блок является законным. Комментарий просто перемещается в конец файла.

Симптомом является сценарий, который работает чисто и делает примерно треть того, что вы ожидали, без ошибок, объясняющих все остальное. Если сценарий SQLite незаметно перестает выполнять какие-либо действия на полпути, найдите в нем /* без партнера.

SQL Server, и люди, использующие ярлыки, отказываются от

Транзакт-SQL делает это простым. Два дефиса на строку, /* */ за блок, нет #.

Стоит иметь ярлык, который Майкрософт документирует на самой справочной странице комментариев. Выделите строки, затем:

Это два нажатия подряд, а не один аккорд. Держать Ctrl, кран K, кран C. Ничего заметного не происходит после K, и именно здесь большинство людей приходят к выводу, что ярлык не работает, и возвращаются к вводу тире вручную.

Каждый второй редактор в этом списке использует Ctrl+/ вместо. Полный список ярлыков редактора находится в Как комментировать в SQL.

Комментарий, который не является комментарием

Есть второе значение слова, которое цепляет людей, ищущих это, и это совершенно другая особенность.

COMMENT ON TABLE не скрывает код. Он хранит описание внутри базы данных, прикрепленное к таблице, где любой, кто запрашивает эту базу данных, может его прочитать. Он сохраняется после того, как ваш файл запроса исчезнет. Это описано отдельно в как комментировать таблицу в SQL.

Короткий способ определить, какой из них вам нужен: если вы пытаетесь остановить работу строки, вам нужно --. Если вы пытаетесь объяснить коллеге, что означает столбец, вам нужно COMMENT ON.

Шпаргалка

Правило, которое охватывает все это

Писать -- через пробел напишите /* */ и закрой его, и не гнездись. Эти три привычки действуют сразу во всех пяти базах данных, поэтому вам никогда не придется запоминать, в какой из них вы находитесь.

В какой базе данных вы на самом деле пишете сегодня, и нужно ли запускать написанный вами SQL где-нибудь еще?

Хотите более широкий навык, а не одну привычку? SQL для аналитиков читает запросы построчно простыми словами, и это та же привычка, по которой написаны эти комментарии. SQL для аналитиков, 19 $ →