Table of Contents
We try to make MySQL Server follow the ANSI SQL standard and the ODBC SQL standard, but MySQL Server performs operations differently in some cases:
There are several differences between the MySQL and standard
SQL privilege systems. For example, in MySQL, privileges for
a table are not automatically revoked when you delete a
table. You must explicitly issue a
REVOKE statement to revoke
privileges for a table. For more information, see
REVOKE Syntax.
The CAST() function does not
support cast to REAL or
BIGINT. See
Cast Functions and Operators.
MySQL Server doesn't support the SELECT ... INTO
TABLE Sybase SQL extension. Instead, MySQL Server
supports the
INSERT INTO ...
SELECT standard SQL syntax, which is basically the
same thing. See INSERT ... SELECT Syntax. For example:
INSERT INTO tbl_temp2 (fld_id)
SELECT tbl_temp1.fld_order_id
FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;
Alternatively, you can use
SELECT ... INTO
OUTFILE or
CREATE TABLE ...
SELECT.
You can use SELECT ...
INTO with user-defined variables. The same syntax
can also be used inside stored routines using cursors and
local variables. See SELECT ... INTO Syntax.
If you access a column from the table to be updated in an
expression, UPDATE uses the
current value of the column. The second assignment in the
following statement sets col2 to the
current (updated) col1 value, not the
original col1 value. The result is that
col1 and col2 have the
same value. This behavior differs from standard SQL.
UPDATE t1 SET col1 = col1 + 1, col2 = col1;
MySQL's implementation of foreign keys differs from the SQL standard in the following key respects:
If there are several rows in the parent table that have
the same referenced key value,
InnoDB acts in foreign key
checks as if the other parent rows with the same key value
do not exist. For example, if you have defined a
RESTRICT type constraint, and there is
a child row with several parent rows,
InnoDB does not permit the deletion of
any of those parent rows.
InnoDB performs cascading operations
through a depth-first algorithm, based on records in the
indexes corresponding to the foreign key constraints.
A FOREIGN KEY constraint that
references a non-UNIQUE key is not
standard SQL but rather an
InnoDB extension.
If ON UPDATE CASCADE or ON
UPDATE SET NULL recurses to update the
same table it has previously updated
during the same cascade, it acts like
RESTRICT. This means that you cannot
use self-referential ON UPDATE CASCADE
or ON UPDATE SET NULL operations. This
is to prevent infinite loops resulting from cascaded
updates. A self-referential ON DELETE SET
NULL, on the other hand, is possible, as is a
self-referential ON DELETE CASCADE.
Cascading operations may not be nested more than 15 levels
deep.
In an SQL statement that inserts, deletes, or updates many
rows, foreign key constraints (like unique constraints)
are checked row-by-row. When performing foreign key
checks, InnoDB sets shared
row-level locks on child or parent records that it must
examine. MySQL checks foreign key constraints immediately;
the check is not deferred to transaction commit. According
to the SQL standard, the default behavior should be
deferred checking. That is, constraints are only checked
after the entire SQL statement has
been processed. This means that it is not possible to
delete a row that refers to itself using a foreign key.
For information about how the
InnoDB storage engine handles
foreign keys, see
InnoDB and FOREIGN KEY Constraints.
Standard SQL uses the C syntax /* this is a comment
*/ for comments, and MySQL Server supports this
syntax as well. MySQL also support extensions to this syntax
that enable MySQL-specific SQL to be embedded in the comment,
as described in Comment Syntax.
Standard SQL uses “--” as a
start-comment sequence. MySQL Server uses
“#” as the start comment
character. MySQL Server 3.23.3 and up also supports a variant
of the “--” comment style.
That is, the “--”
start-comment sequence must be followed by a space (or by a
control character such as a newline). The space is required to
prevent problems with automatically generated SQL queries that
use constructs such as the following, where we automatically
insert the value of the payment for
payment:
UPDATE account SET credit=credit-payment
Consider about what happens if payment has
a negative value such as -1:
UPDATE account SET credit=credit--1
credit--1 is a valid expression in SQL, but
“--” is interpreted as the
start of a comment, part of the expression is discarded. The
result is a statement that has a completely different meaning
than intended:
UPDATE account SET credit=credit
The statement produces no change in value at all. This
illustrates that permitting comments to start with
“--” can have serious
consequences.
Using our implementation requires a space following the
“--” for it to be recognized
as a start-comment sequence in MySQL Server 3.23.3 and higher.
Therefore, credit--1 is safe to use.
Another safe feature is that the mysql
command-line client ignores lines that start with
“--”.
The following information is relevant only if you are running a MySQL version earlier than 3.23.3:
If you have an SQL script in a text file that contains
“--” comments, you should use
the replace utility as follows to convert
the comments to use “#”
characters before executing the script:
shell>replace " --" " #" < text-file-with-funny-comments.sql \| mysqldb_name
That is safer than executing the script in the usual way:
shell> mysql db_name < text-file-with-funny-comments.sql
You can also edit the script file “in place” to
change the “--” comments to
“#” comments:
shell> replace " --" " #" -- text-file-with-funny-comments.sql
Change them back with this command:
shell> replace " #" " --" -- text-file-with-funny-comments.sql