← All Kits · SQL Kit

Commenting Out Several Lines of SQL, and Uncommenting Them Again

Michael Nocito · Updated August 2026 · Every example on this page was run before it was published

You are testing a long query and want to run it without the last three joins. Or you have written a note that runs over five lines. Both need several lines switched off at once, and SQL gives you two ways to do it that behave differently the moment they overlap.

What you do: use the editor shortcut to toggle -- on every selected line. It is faster than typing a block comment and it cannot be broken by a comment already inside the selection.

The short version. Block comments do not nest, so a /* inside your block does nothing and the first */ ends everything.

The two syntaxes

-- a line comment. Everything after the two dashes, to the end of the line.

/* a block comment.
   It can run over
   as many lines as you like. */

Both are standard SQL and both work in PostgreSQL, MySQL, SQL Server, Oracle, SQLite, Snowflake and BigQuery. MySQL has one extra rule worth knowing: -- must be followed by a space or a control character, so --this is not a comment there while -- this is. Writing the space always is the habit that avoids the whole question.

The shortcut, by editor

Select the lines, press the shortcut, and each line gets -- at the front. Press it again and they come off. That toggle is the single most useful shortcut in a SQL editor and most people never find it.

The nesting trap

/* switching this section off for now
SELECT customer_id,
       SUM(amount) AS total   /* only shipped orders */
FROM orders
WHERE status = 'shipped'
GROUP BY customer_id
*/

This does not do what it looks like. The block ends at the first */, which is the one after "only shipped orders". Everything from FROM orders onwards is live SQL again, and the trailing */ at the bottom is now a syntax error.

The database is not being awkward. Standard SQL block comments do not nest, and the scanner simply takes the first closing marker it meets. PostgreSQL is the one common exception: it does support nested block comments, which means a query that works there can fail everywhere else.

The defence is to use line comments for the outer switch-off, which is exactly what the editor shortcut produces:

-- switching this section off for now
-- SELECT customer_id,
--        SUM(amount) AS total   /* only shipped orders */
-- FROM orders
-- WHERE status = 'shipped'
-- GROUP BY customer_id

Line comments cannot be closed early by anything, because their scope is the line.

Testing a query by switching parts off

The technique that makes long queries manageable: comment out everything after the first join, run it, count the rows, then add one join back at a time and watch the count.

SELECT COUNT(*)
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
-- JOIN payments  p ON p.order_id    = o.order_id
-- JOIN regions   r ON r.region_id   = c.region_id
;

Uncomment one line, re-run, compare. Any join that changes the count is either filtering rows or multiplying them, and both are worth knowing about before you sum anything. That is the detection method in why a join duplicates rows.

Put the semicolon on its own line while you are doing this. Then commenting out the last join does not also comment out the terminator.

Leaving the good comments in

The comments worth keeping are not the ones that repeat the SQL. They are the ones a reader cannot deduce:

-- Excludes status 'test' because the ZZ accounts are load-test data.
-- Confirmed with the ops team, 12 Aug 2026.
WHERE status <> 'test'

-- Amount is in pence in this table, unlike orders_v2.
SELECT SUM(amount) / 100.0 AS pounds

Why a row is excluded, which unit a column is in, who agreed a rule and when. A fuller method for writing these is in teaching comments.

How to apply this to your own work

1. Learn the toggle shortcut for the editor you use every day. It repays itself the first afternoon.
2. Use line comments for anything you intend to keep, and block comments only for temporary switching off.
3. Write conditions with AND at the start of the line so any single line can be commented out cleanly.
4. Add one join at a time and check the row count after each. It is the cheapest correctness check in SQL.
5. Before saving a query, delete the commented-out experiments. A file full of dead SQL is a file nobody can tell is current.

The one habit to keep

Comment out to test, then delete rather than leaving it. Commented code has no way to say whether it is a note, an experiment or a rule that was turned off in a hurry, and six months later nobody can tell which.

How many commented-out lines are in the query you run most often?