SQL Language Structure

 

Overview

This chapter discusses the rules for writing the following elements of SQL statements:

Strings

A string is a sequence of bytes or characters, enclosed within either single quote (') or double quote (") characters. Examples:

A binary string is a string of bytes that has no character set or collation. A non-binary string is a string of characters that has a character set and collation. For both types of strings, comparisons are based on the numeric values of the string unit. For binary strings, the unit is the byte. For non-binary strings the unit is the character and some character sets allow multi-byte characters. Character value ordering is a function of the string collation.

String literals may have an optional character set introducer and COLLATE clause: [_charset_name]'string' [COLLATE collation_name]. Examples:

You can use N'literal' (or n'literal') to create a string in the national character set. These statements are equivalent:

Within a string, certain sequences have special meaning. Each of these sequences begins with a backslash (?\?), known as the escape character. SQL recognizes the following escape sequences:

For all other escape sequences, backslash is ignored. That is, the escaped character is interpreted as if it was not escaped. For example, ?\x? is just ?x?. These sequences are case sensitive. For example, ?\b? is interpreted as a backspace, but ?\B? is interpreted as ?B?. The ASCII 26 character can be encoded as ?\Z? to enable you to work around the problem that ASCII 26 stands for END-OF-FILE on Windows. A ASCII 26 within a file causes problems if you try to use mysql db_name < file_name. Escape processing is done according to the character set indicated by the character_set_connection system variable. This is true even for strings that are preceded by an introducer that indicates a different character set. The ?\%? and ?\_? sequences are used to search for literal instances of ?%? and ?_? in pattern-matching contexts where they would otherwise be interpreted as wildcard characters. See See the description of the LIKE operator. If you use ?\%? or ?\_? in non-pattern-matching contexts, they evaluate to the strings ?\%? and ?\_?, not to ?%? and ?_?. There are several ways to include quote characters within a string:

The following SELECT statements demonstrate how quoting and escaping work:

hello"hello"""hello""hel'lo'hello
hello'hello'''hello''hel"lo"hello

If you want to insert binary data into a string column (such as a BLOB column), the following characters must be represented by escape sequences:

When writing application programs, any string that might contain any of these special characters must be properly escaped before the string is used as a data value in an SQL statement that is sent to the MySQL server. You can do this in two ways: Process the string with a function that escapes the special characters. In a C program, you can use the mysql_real_escape_string() C API function to escape characters. The Perl DBI interface provides a quote method to convert special characters to the proper escape sequences. Other language interfaces may provide a similar capability. As an alternative to explicitly escaping special characters, many SQL APIs provide a placeholder capability that enables you to insert special markers into a statement string, and then bind data values to them when you issue the statement. In this case, the API takes care of escaping special characters in the values for you.

Numbers

Integers are represented as a sequence of digits. Floats use "." as a decimal separator. Either type of number may be preceded by "-" or "+" to indicate a negative or positive value, respectively.

Examples of valid integers:

Examples of valid floating-point numbers:

An integer may be used in a floating-point context; it is interpreted as the equivalent floating-point number.

Hexadecimal Values

SQL supports hexadecimal values, written using X'val', x'val', or 0xval format, where val contains hexadecimal digits (0..9, A..F). Lettercase of the digits does not matter. For values written using X'val' or x'val' format, val must contain an even number of digits. For values written using 0xval syntax, values that contain an odd number of digits are treated as having an extra leading 0. For example, 0x0a and 0xaaa are interpreted as 0x0a and 0x0aaa. In numeric contexts, hexadecimal values act like integers (64-bit precision). In string contexts, they act like binary strings, where each pair of hex digits is converted to a character:

The default type of a hexadecimal value is a string. If you want to ensure that the value is treated as a number, you can use CAST(... AS UNSIGNED):

The X'hexstring' syntax is based on standard SQL. The 0x syntax is based on ODBC. Hexadecimal strings are often used by ODBC to supply values for BLOB columns. You can convert a string or a number to a string in hexadecimal format with the HEX() function:

Boolean Values

The constants TRUE and FALSE evaluate to 1 and 0, respectively. The constant names can be written in any lettercase.

Bit-Field Values

Bit-field values can be written using b'value' or 0bvalue notation. Value is a binary value written using zeros and ones. Bit-field notation is convenient for specifying values to be assigned to BIT columns:

Bit values are returned as binary values. To display them in printable form, add 0 or use a conversion function such as BIN(). High-order 0 bits are not displayed in the converted value.

b+0BIN(b+0)OCT(b+0)HEX(b+0)
2511111111377FF
10101012A
510155

Bit values assigned to user variables are treated as binary strings. To assign a bit value as a number to a user variable, use CAST() or +0:

@v1@v2@v3
A6565

NULL Values

The NULL value means "no data.", and is the SQL equivalent of #void in Lisp. NULL can be written in any lettercase. A synonym is \N (case sensitive). For text file import or export operations performed with LOAD DATA INFILE or SELECT ... INTO OUTFILE, NULL is represented by the \N sequence. Be aware that the NULL value is different from values such as 0 for numeric types or the empty string for string types.

Schema Object Names

Certain objects within SQL, including database, table, index, column, alias, view, stored procedure, partition, tablespace, and other object names are known as identifiers. This section describes the allowable syntax for identifiers in SQL. An identifier may be quoted or unquoted. If an identifier contains special characters or is a reserved word, you must quote it whenever you refer to it. The set of alphanumeric characters from the current character set, "_", and "$" are not special. The identifier quote character is the backtick ("`"):

Identifier quote characters can be included within an identifier if you quote the identifier. If the character to be included within the identifier is the same as that used to quote the identifier itself, then you need to double the character. The following statement creates a table named a`b that contains a column named c"d:

Aliases may be quoted either as identifiers or as strings:

onetwo
12

Identifiers may begin with a digit but unless quoted may not consist solely of digits. It is recommended that you do not use names of the form Me or MeN, where M and N are integers. For example, avoid using 1e or 2e2 as identifiers, because an expression such as 1e+3 is ambiguous. Depending on context, it might be interpreted as the expression 1e + 3 or as the number 1e+3. Be careful when using MD5() to produce table names because it can produce names in illegal or ambiguous formats such as those just described. A user variable cannot be used directly in an SQL statement as an identifier or as part of an identifier. There are some restrictions on the characters that may appear in identifiers:

The following table describes the maximum length for each type of identifier.

IdentifierMaximum Length (characters)
Database64
table64
column64
index64
Stored Function or Procedure64
Trigger64
View64
Event64
Tablespace64
Log File Group64
Alias255

Identifier Qualifiers

SQL allows names that consist of a single identifier or multiple identifiers. The components of a multiple-part name must be separated by period (".") characters. The initial parts of a multiple-part name act as qualifiers that affect the context within which the final identifier is interpreted.

In SQL, you can refer to a table column using any of the following forms:

Column ReferenceMeaning
col_nameThe column col_name from whichever table used in the statement contains a column of that name.
tbl_name.col_nameThe column col_name from table tbl_name of the default database.
db_name.tbl_name.col_nameThe column col_name from table tbl_name of the database db_name.

If any components of a multiple-part name require quoting, quote them individually rather than quoting the name as a whole. For example, write `my-table`.`my-column`, not `my-table.my-column`. A reserved word that follows a period in a qualified name must be an identifier, so in that context it need not be quoted. You need not specify a tbl_name or db_name.tbl_name prefix for a column reference in a statement unless the reference would be ambiguous. Suppose that tables t1 and t2 each contain a column c, and you retrieve c in a SELECT statement that uses both t1 and t2. In this case, c is ambiguous because it is not unique among the tables used in the statement. You must qualify it with a table name as t1.c or t2.c to indicate which table you mean. Similarly, to retrieve from a table t in database db1 and from a table t in database db2 in the same statement, you must refer to columns in those tables as db1.t.col_name and db2.t.col_name. The syntax .tbl_name means the table tbl_name in the default database. This syntax is accepted for ODBC compatibility because some ODBC programs prefix table names with a "." character.

Identifier Case Sensitivity

In SQL, databases correspond to directories within the data directory. Each table within a database corresponds to at least one file within the database directory (and possibly more, depending on the storage engine). Triggers also correspond to files. Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database and table names. This means database, table, and trigger names are not case sensitive in Windows, but are case sensitive in most varieties of Unix. One notable exception is Mac OS X, which is Unix-based but uses a default filesystem type (HFS+) that is not case sensitive. However, Mac OS X also supports UFS volumes, which are case sensitive just as on any Unix. The lower_case_table_names system variable also affects how the server handles identifier case sensitivity.

Although database, table, and trigger names are not case sensitive on some platforms, you should not refer to one of these using different cases within the same statement. The following statement would not work because it refers to a table both as my_table and as MY_TABLE:

Column, index, stored routine, and event names are not case sensitive on any platform, nor are column aliases.

However, names of triggers and logfile groups are case sensitive. This differs from standard SQL.

By default, table aliases are case sensitive on Unix, but not so on Windows or Mac OS X. The following statement would not work on Unix, because it refers to the alias both as a and as A:

However, this same statement is permitted on Windows. To avoid problems caused by such differences, it is best to adopt a consistent convention, such as always creating and referring to databases and tables using lowercase names. This convention is recommended for maximum portability and ease of use.

How table and database names are stored on disk and used in SQL is affected by the lower_case_table_names system variable, which you can set when starting mysqld. lower_case_table_names can take the values shown in the following table. This variable does not affect case sensitivity of trigger identifiers. On Unix, the default value of lower_case_table_names is 0. On Windows the default value is 1. On Mac OS X, the default value is 2.

Value Meaning
0 Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or CREATE DATABASE statement. Name comparisons are case sensitive. Note that if you force this variable to 0 with --lower-case-table-names=0 on a case-insensitive filesystem and access MyISAM tablenames using different lettercases, index corruption may result.
1 Table names are stored in lowercase on disk and name comparisons are not case sensitive. SQL converts all table names to lowercase on storage and lookup. This behavior also applies to database names and table aliases.
2 Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or CREATE DATABASE statement, but MySQL converts them to lowercase on lookup. Name comparisons are not case sensitive. This works only on filesystems that are not case sensitive! InnoDB table names are stored in lowercase, as for lower_case_table_names=1.

If you are using SQL on only one platform, you do not normally have to change the lower_case_table_names variable from its default value. However, you may encounter difficulties if you want to transfer tables between platforms that differ in filesystem case sensitivity. For example, on Unix, you can have two different tables named my_table and MY_TABLE, but on Windows these two names are considered identical. To avoid data transfer problems arising from lettercase of database or table names, you have two options:

Exception: If you are using InnoDB tables and you are trying to avoid these data transfer problems, you should set lower_case_table_names to 1 on all platforms to force names to be converted to lowercase.

If you plan to set the lower_case_table_names system variable to 1 on Unix, you must first convert your old database and table names to lowercase before stopping mysqld and restarting it with the new variable setting.

Object names may be considered duplicates if their uppercase forms are equal according to a binary collation. That is true for names of cursors, conditions, functions, procedures, savepoints, and routine local variables. It is not true for names of columns, constraints, databases, partitions, statements prepared with PREPARE, tables, triggers, users, and user-defined variables.

Mapping of Identifiers to Filenames

There is a correspondence between database and table identifiers and names in the filesystem. For the basic structure, SQL represents each database as a directory in the data directory, and each table by one or more files in the appropriate database directory. For the table format files (.FRM), the data is always stored in this structure and location.

For the data and index files, the exact representation on disk is storage engine specific. These files may be stored in the same location as the FRM files, or the information may be stored separate file. InnoDB data is stored in the InnoDB data files. If you are using tablespaces with InnoDB, then the specific tablespace files you create are used instead.

Any character is legal in database or table identifiers except ASCII NUL (0x00). SQL encodes any characters that are problematic in the corresponding filesystem objects when it creates database directories or table files:

On Windows, some names such as nul, prn, and aux cannot be used as filenames because they are reserved as device names. These are allowable names in SQL. They are encoded by appending @@@ to the name when the server creates the corresponding file or directory. This occurs on all platforms for portability of the corresponding database object between platforms.

Function Name Parsing and Resolution

SQL supports built-in (native) functions, user-defined functions (UDFs), and stored functions. This section describes how the server recognizes whether the name of a built-in function is used as a function call or as an identifier, and how the server determines which function to use in cases when functions of different types exist with a given name.

Built-In Function Name Parsing

The parser uses default rules for parsing names of built-in functions. These rules can be changed by enabling the IGNORE_SPACE SQL mode.

When the parser encounters a word that is the name of a built-in function, it must determine whether the name signifies a function call or is instead a non-expression reference to an identifier such as a table or column name. For example, in the following statements, the first reference to count is a function call, whereas the second reference is a table name:

(sql sqlHandle {SELECT COUNT(*) FROM mytable})
(sql sqlHandle {CREATE TABLE count (i INT)})

The parser should recognize the name of a built-in function as indicating a function call only when parsing what is expected to be an expression. That is, in non-expression context, function names are permitted as identifiers.

However, some built-in functions have special parsing or implementation considerations, so the parser uses the following rules by default to distinguish whether their names are being used as function calls or as identifiers in non-expression context:

The requirement that function calls be written with no whitespace between the name and the parenthesis applies only to the built-in functions that have special considerations. COUNT is one such name. The exact list of function names for which following whitespace determines their interpretation are those listed in the sql_functions[] array of the sql/lex.h source file.

For functions not listed in the sql_functions[]) array, whitespace does not matter. They are interpreted as function calls only when used in expression context and may be used freely as identifiers otherwise. ASCII is one such name. However, for these non-affected function names, interpretation may vary in expression context: func_name () is interpreted as a built-in function if there is one with the given name; if not, func_name () is interpreted as a user-defined function or stored function if one exists with that name.

The IGNORE_SPACE SQL mode can be used to modify how the parser treats function names that are whitespace-sensitive:

To enable the IGNORE_SPACE SQL mode, use this statement:

(sql sqlHandle {SET sql_mode = 'IGNORE_SPACE'})

IGNORE_SPACE is also enabled by certain other composite modes such as ANSI that include it in their value:

(sqp sqlHandle {SET sql_mode = 'ANSI'})

To minimize the dependency of SQL code on the IGNORE_SPACE setting, use these guidelines:

Function Name Resolution

The following rules describe how the server resolves references to function names for function creation and invocation:

Reserved Words

Certain words such as SELECT, DELETE, or BIGINT are reserved and require special treatment for use as identifiers such as table and column names. This may also be true for the names of built-in functions.

Reserved words are permitted as identifiers if you quote them.

(sql sqlHandle {CREATE TABLE interval (begin INT, end INT)}) ReturnsYou have an error in your SQL syntax ... near 'interval (begin INT, end INT)'
(sql sqlHandle {CREATE TABLE `interval` (begin INT, end INT)})

Exception: A word that follows a period in a qualified name must be an identifier, so it need not be quoted even if it is reserved:

(sql sqlHandle {CREATE TABLE mydb.interval (begin INT, end INT)})

Names of built-in functions are permitted as identifiers but may require care to be used as such. For example, COUNT is acceptable as a column name. However, by default, no whitespace is allowed in function invocations between the function name and the following "(" character. This requirement enables the parser to distinguish whether the name is used in a function call or in non-function context.

The words in the following table are explicitly reserved in SQL. Most of the words in the table are forbidden by standard SQL as column or table names (for example, GROUP). A few are reserved because MySQL needs them and uses a yacc parser. A reserved word can be used as an identifier if you quote it.

ACCESSIBLEADDALL
ALTERANALYZEAND
ASASCASENSITIVE
BEFOREBETWEENBIGINT
BINARYBLOBBOTH
BYCALLCASCADE
CASECHANGECHAR
CHARACTERCHECKCOLLATE
COLUMNCONDITIONCONSTRAINT
CONTINUECONVERTCREATE
CROSSCURRENT_DATECURRENT_TIME
CURRENT_TIMESTAMPCURRENT_USERCURSOR
DATABASEDATABASESDAY_HOUR
DAY_MICROSECONDDAY_MINUTEDAY_SECOND
DECDECIMALDECLARE
DEFAULTDELAYEDDELETE
DESCDESCRIBEDETERMINISTIC
DISTINCTDISTINCTROWDIV
DOUBLEDROPDUAL
EACHELSEELSEIF
ENCLOSEDESCAPEDEXISTS
EXITEXPLAINFALSE
FETCHFLOATFLOAT4
FLOAT8FORFORCE
FOREIGNFROMFULLTEXT
GRANTGROUPHAVING
HIGH_PRIORITYHOUR_MICROSECONDHOUR_MINUTE
HOUR_SECONDIFIGNORE
ININDEXINFILE
INNERINOUTINSENSITIVE
INSERTINTINT1
INT2INT3INT4
INT8INTEGERINTERVAL
INTOISITERATE
JOINKEYKEYS
KILLLEADINGLEAVE
LEFTLIKELIMIT
LINEARLINESLOAD
LOCALTIMELOCALTIMESTAMPLOCK
LONGLONGBLOBLONGTEXT
LOOPLOW_PRIORITYMASTER_SSL_VERIFY_SERVER_CERT
MATCHMEDIUMBLOBMEDIUMINT
MEDIUMTEXTMIDDLEINTMINUTE_MICROSECOND
MINUTE_SECONDMODMODIFIES
NATURALNOTNO_WRITE_TO_BINLOG
NULLNUMERICON
OPTIMIZEOPTIONOPTIONALLY
ORORDEROUT
OUTEROUTFILEPRECISION
PRIMARYPROCEDUREPURGE
RANGEREADREADS
READ_WRITEREALREFERENCES
REGEXPRELEASERENAME
REPEATREPLACEREQUIRE
RESTRICTRETURNREVOKE
RIGHTRLIKESCHEMA
SCHEMASSECOND_MICROSECONDSELECT
SENSITIVESEPARATORSET
SHOWSMALLINTSPATIAL
SPECIFICSQLSQLEXCEPTION
SQLSTATESQLWARNINGSQL_BIG_RESULT
SQL_CALC_FOUND_ROWSSQL_SMALL_RESULTSSL
STARTINGSTRAIGHT_JOINTABLE
TERMINATEDTHENTINYBLOB
TINYINTTINYTEXTTO
TRAILINGTRIGGERTRUE
UNDOUNIONUNIQUE
UNLOCKUNSIGNEDUPDATE
USAGEUSEUSING
UTC_DATEUTC_TIMEUTC_TIMESTAMP
VALUESVARBINARYVARCHAR
VARCHARACTERVARYINGWHEN
WHEREWHILEWITH
WRITEXORYEAR_MONTH
ZEROFILL

The following are new reserved words in SQL

ACCESSIBLELINEARMASTER_SSL_VERIFY_SERVER_CERT
RANGEREAD_ONLYREAD_WRITE

SQL allows some keywords to be used as unquoted identifiers because many people previously used them. Examples are those in the following list:

User-Defined Variables

You can store a value in a user-defined variable and then refer to it later. This enables you to pass values from one statement to another. User-defined variables are connection-specific. That is, a user variable defined by one client cannot be seen or used by other clients. All variables for a given client connection are automatically freed when that client exits.

User variables are written as @var_name, where the variable name var_name may consist of alphanumeric characters from the current character set, ".", "_", and "$". The default character set is latin1 (cp1252 West European). This may be changed with the --character-set-server option to mysqld. A user variable name can contain other characters if you quote it as a string or identifier (for example, @'my-var', @"my-var", or @`my-var`).

Note: User variable names not case sensitive.

One way to set a user-defined variable is by issuing a SET statement:

SET @var_name = expr [, @var_name = expr] ...

For SET, either = or := can be used as the assignment operator. The expr assigned to each variable can evaluate to an integer, decimal, floating-point, string, or NULL value. However, if the value of the variable is selected in a result set, it is returned to the client as a string. Assignment of decimal and real values does not preserve the precision or scale of the value.

You can also assign a value to a user variable in statements other than SET. In this case, the assignment operator must be := and not = because = is treated as a comparison operator in non-SET statements:

(sql sqlHandle {SET @t1=0, @t2=0, @t3=0})
(sql sqlHandle {SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3})
+----------------------+------+------+------+
| @t1:=(@t2:=1)+@t3:=4 | @t1  | @t2  | @t3  |
+----------------------+------+------+------+
|                    5 |    5 |    1 |    4 |
+----------------------+------+------+------+

User variables may be used in contexts where expressions are allowed. This does not currently include contexts that explicitly require a literal value, such as in the LIMIT clause of a SELECT statement, or the IGNORE N LINES clause of a LOAD DATA statement.

User variables are intended to provide data values. They cannot be used to supply identifiers, such as in contexts where a table or database name is expected, or reserved words such as SELECT. An exception to this principle is that if you are constructing a string for use as a prepared statement to be executed later, user variables can be referenced to provide any part of the statement.

If a user variable is assigned a string value, it has the same character set and collation as the string. The coercibility of user variables is implicit. (This is the same coercibility as for table column values.)

If you refer to a variable that has not been initialized, it has a value of NULL and a type of string.

Bit values assigned to user variables are treated as binary strings. To assign a bit value as a number to a user variable, use CAST() or +0:

(sql sqlHandle {SET @v1 = b'1000001'})
(sql sqlHandle {SET @v2 = CAST(b'1000001' AS UNSIGNED), @v3 = b'1000001'+0})
(sql sqlHandle {SELECT @v1, @v2, @v3})
+------+------+------+
| @v1  | @v2  | @v3  |
+------+------+------+
| A    |   65 |   65 | 
+------+------+------+

Note: In a SELECT statement, each expression is evaluated only when sent to the client. This means that in a HAVING, GROUP BY, or ORDER BY clause, you cannot refer to an expression that involves variables that are set in the SELECT list. For example, the following statement does not work as expected:

(sql sqlHandle {SELECT (@aa:=id) AS a, (@aa+3) AS b FROM tbl_name HAVING b=5})

The reference to b in the HAVING clause refers to an alias for an expression in the SELECT list that uses @aa. This does not work as expected: @aa contains the value of id from the previous selected row, not from the current row.

The order of evaluation for user variables is undefined and may change based on the elements contained within a given query. In SELECT @a, @a := @a+1 ..., you might think that SQL will evaluate @a first and then do an assignment second, but changing the query (for example, by adding a GROUP BY, HAVING, or ORDER BY clause) may change the order of evaluation.

The general rule is never to assign a value to a user variable in one part of a statement and use the same variable in some other part of the same statement. You might get the results you expect, but this is not guaranteed.

Another issue with setting a variable and using it in the same statement is that the default result type of a variable is based on the type of the variable at the start of the statement. The following example illustrates this:

(sql sqlHandle {SET @a='test'})
(sql sqlHandle {SELECT @a,(@a:=20) FROM tbl_name})

For this SELECT statement, SQL reports to the client that column one is a string and converts all accesses of @a to strings, even though @a is set to a number for the second row. After the SELECT statement executes, @a is regarded as a number for the next statement.

To avoid problems with this behavior, either do not set and use the same variable within a single statement, or else set the variable to 0, 0.0, or '' to define its type before you use it.

A user variable cannot be used directly in an SQL statement as an identifier or as part of an identifier, even if it is set off with backticks. This is shown in the following example:

(sql sqlHandle {SELECT c1 FROM t})
+----+
| c1 |
+----+
|  0 |
+----+
|  1 |
+----+
(sql sqlHandle {SET @col = "c1"})
(sql sqlHandle {SELECT @col FROM t})
+------+
| @col |
+------+
| c1   |
+------+
(sql sqlHandle {SELECT `@col` FROM t}) Returns Unknown column '@col' in 'field list'
(sql sqlHandle {SET @col = "`c1`"})
(sql sqlHandle {SELECT @col FROM t})
+------+
| @col |
+------+
| `c1` |
+------+

One way to work around this problem is to assemble a string for the query in application code.

It is also possible to perform such operations using prepared statements, without the need to concatenate strings of SQL in client code. This example illustrates how this can be done:

(sql sqlHandle {SET @c = "c1"})
(sql sqlHandle {SET @s = CONCAT("SELECT ", @c, " FROM t")})
(sql sqlHandle {PREPARE stmt FROM @s})
(sql sqlHandle {EXECUTE stmt})
+----+
| c1 |
+----+
|  0 |
+----+
|  1 |
+----+
(sql sqlHandle {DEALLOCATE PREPARE stmt})

You cannot use a placeholder for an identifier (such as the name of a database, table, or column) in an SQL prepared statement.

Comment Syntax

SQL supports three comment styles:

The following example demonstrates all three comment styles:

(sql sqlHandle {SELECT 1+1;     # This comment continues to the end of line})
(sql sqlHandle {SELECT 1+1;     -- This comment continues to the end of line})
(sql sqlHandle {SELECT 1 /* this is an in-line comment */ + 1;})

Nested comments are not supported.

SQL Server supports some variants of C-style comments. These enable you to write code that includes SQL extensions, but is still portable, by using comments of the following form:

/*! MySQL-specific code */

In this case, SQL parses and executes the code within the comment as it would any other SQL statement, but other SQL servers will ignore the extensions. For example, SQL Server recognizes the STRAIGHT_JOIN keyword in the following statement, but other servers will not:

SELECT /*! STRAIGHT_JOIN */ col1 FROM table1,table2 WHERE ...