iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use -- for a line comment and /* ... */ for a block comment. The first hides text through the end of the line; the second hides text through its closing marker and can span lines. The details vary by database: notably, MySQL requires whitespace or a control character after --, and block comments do not nest consistently.
How to write line and block comments
These examples use forms documented by PostgreSQL, MySQL, SQLite, SQL Server, and Oracle. A comment can explain code, or temporarily exclude it while you investigate a query.
-- A line comment: the rest of this line is ignored
SELECT customer_id, total
FROM orders;
/* A block comment can span lines.
Keep its closing marker visible. */
SELECT customer_id, total
FROM orders;A line comment continues to the line ending or end of input. A block comment starts at /* and ends at the first applicable */; it can cover multiple lines. Comments can also appear between SQL tokens where whitespace is allowed:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
SELECT customer_id, /* explain this column */ total
FROM orders;PostgreSQL documents that comments are removed before syntax analysis and effectively replaced by whitespace. That is a useful general model, but it is not universal: MySQL executable comments and Oracle optimizer hints are meaningful exceptions.
#1 Best Overall
Why -- can behave differently
Do not assume every database recognizes two adjacent dashes identically. MySQL 8.4 requires a whitespace or control character after the second dash for -- to begin a comment. A clear habit is to put a space after the dashes: -- comment. PostgreSQL, SQLite, SQL Server, and Oracle document line comments through the line ending without that specific MySQL qualification.
The negative-number trap in MySQL
The MySQL 8.0 Reference Manual illustrates a subtle failure: an expression such as balance=balance-charge can become balance=balance--1 when charge is negative one. Under MySQL’s comment rule, the second dash followed by 1 can start a comment, causing the text after the dashes to be discarded rather than subtracting a negative value. The intended arithmetic can therefore disappear from the statement.
Make arithmetic explicit, for example balance = balance - (-1), and keep spacing clear. This MySQL-specific parsing example should not be generalized to all database engines.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsHow a line comment can break an otherwise valid query
Everything after -- on that line is comment text—including punctuation that the statement may still need. A comma, closing parenthesis, join condition, or statement terminator placed after the marker is swallowed too. The next line can then contain an incomplete expression or produce a different statement.
For example, commenting out a selected column while leaving a comma immediately before the line comment may leave an invalid or unintended select list. Put explanatory comments on their own lines where practical. When disabling one expression, inspect the commas and parentheses around it, as well as the rest of the line after --.
Can SQL block comments be nested?
Not portably. PostgreSQL and Transact-SQL support nested block comments; SQLite says comments do not nest, and MySQL says nested comments are unsupported and should be avoided. If code already contains /* ... */, wrapping it in another block comment can make the first closing */ end the outer comment earlier than expected.
For code you need to disable across different engines, avoid relying on nested block comments. Comment out smaller sections, or use line comments when the surrounding syntax permits them.
Comment rules by database
This comparison is limited to comment behavior documented in the linked references; it does not imply that the engines share other SQL syntax.
Quick Recap
| Database and documentation | -- line comment |
/* ... */ block comment |
Nesting or notable exception |
|---|---|---|---|
| PostgreSQL 18 | Continues to end of line. | Supported. | Block comments nest. Comments are replaced by whitespace before syntax analysis. PostgreSQL 18 documentation. |
| MySQL 8.4 | Requires whitespace or a control character after the second dash. | Supported. | Nested comments are unsupported and deprecated. /*! ... */ can execute MySQL code; /*+ ... */ is used for optimizer hints. MySQL 8.4 Reference Manual. |
| SQLite | Continues to newline or end of input. | Supported through the first closing */. |
Comments do not nest and behave like whitespace. SQLite documentation. |
| SQL Server / Transact-SQL | Continues to newline. | Supported. | Nested block comments are supported; an unmatched nested opener produces an error. Line comment documentation and block comment documentation. |
| Oracle Database 18c | Ends at a line break. | Multiline form is documented. | Optimizer hints are comments that instruct the optimizer. SQL*Plus can impose interface-specific blank-line restrictions. Oracle Database 18c SQL Language Reference. |
What to check when a query breaks after adding a comment
- Identify the database and execution tool. Confirm which engine parses the SQL and, where relevant, whether it is being run through a client or script runner.
- Make the line-comment marker unambiguous. Write
-- comment; in MySQL, whitespace or a control character after the second dash is required. - Inspect the rest of the commented line. Look for commas, parentheses, predicates, and statement terminators that the comment may have hidden.
- Check block-comment boundaries. Count the
/*and*/markers, and do not assume nested blocks work in the target engine. - Read the remaining SQL without the comments. In a copy of the query, remove the comments mentally or literally and check that the syntax is complete. If ordinary-looking comments change behavior, check for executable comments or optimizer hints supported by that dialect.
- Isolate the failing statement. Re-run the smallest relevant query in the target engine to identify which edit introduced the problem.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
