How MySQL Deals with Constraints
28
shell>
replace " --" " #" < text-file-with-funny-comments.sql \
| mysql db_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
See
Section 4.8.2, “
replace
— A String-Replacement Utility”
.
1.8.6. How MySQL Deals with Constraints
MySQL enables you to work both with transactional tables that permit rollback and with
nontransactional tables that do not. Because of this, constraint handling is a bit different in MySQL
than in other DBMSs. We must handle the case when you have inserted or updated a lot of rows in a
nontransactional table for which changes cannot be rolled back when an error occurs.
The basic philosophy is that MySQL Server tries to produce an error for anything that it can detect
while parsing a statement to be executed, and tries to recover from any errors that occur while
executing the statement. We do this in most cases, but not yet for all.
The options MySQL has when an error occurs are to stop the statement in the middle or to recover as
well as possible from the problem and continue. By default, the server follows the latter course. This
means, for example, that the server may coerce illegal values to the closest legal values.
Beginning with MySQL 5.0.2, several SQL mode options are available to provide greater control over
handling of bad data values and whether to continue statement execution or abort when errors occur.
Using these options, you can configure MySQL Server to act in a more traditional fashion that is like
other DBMSs that reject improper input. The SQL mode can be set globally at server startup to affect
all clients. Individual clients can set the SQL mode at runtime, which enables each client to select the
behavior most appropriate for its requirements. See
Section 5.1.7, “Server SQL Modes”
.
The following sections describe how MySQL Server handles different types of constraints.
1.8.6.1.
PRIMARY KEY
and
UNIQUE
Index Constraints
Normally, errors occurs for data-change statements (such as
INSERT
or
UPDATE
) that would violate
primary-key, unique-key, or foreign-key constraints. If you are using a transactional storage engine
such as
InnoDB
, MySQL automatically rolls back the statement. If you are using a nontransactional
storage engine, MySQL stops processing the statement at the row for which the error occurred and
leaves any remaining rows unprocessed.
MySQL supports an
IGNORE
keyword for
INSERT
,
UPDATE
, and so forth. If you use it, MySQL ignores
primary-key or unique-key violations and continues processing with the next row. See the section for
the statement that you are using (
Section 13.2.5, “
INSERT
Syntax”
,
Section 13.2.10, “
UPDATE
Syntax”
,
and so forth).
You can get information about the number of rows actually inserted or updated with the
mysql_info()
C API function. You can also use the
SHOW WARNINGS
statement. See
Section 20.6.6.35, “
mysql_info()
”
, and
Section 13.7.5.37, “
SHOW WARNINGS
Syntax”
.
Currently, only
InnoDB
tables support foreign keys. See
Section 14.2.3.4, “
InnoDB
and
FOREIGN KEY
Constraints”
.
Summary of Contents for 5.0
Page 1: ...MySQL 5 0 Reference Manual ...
Page 18: ...xviii ...
Page 60: ...40 ...
Page 396: ...376 ...
Page 578: ...558 ...
Page 636: ...616 ...
Page 844: ...824 ...
Page 1234: ...1214 ...
Page 1427: ...MySQL Proxy Scripting 1407 ...
Page 1734: ...1714 ...
Page 1752: ...1732 ...
Page 1783: ...Configuring Connector ODBC 1763 ...
Page 1793: ...Connector ODBC Examples 1773 ...
Page 1839: ...Connector Net Installation 1819 2 You must choose the type of installation to perform ...
Page 2850: ...2830 ...
Page 2854: ...2834 ...
Page 2928: ...2908 ...
Page 3000: ...2980 ...
Page 3122: ...3102 ...
Page 3126: ...3106 ...
Page 3174: ...3154 ...
Page 3232: ...3212 ...