Author: paul
Date: 2006-01-10 05:12:27 +0100 (Tue, 10 Jan 2006)
New Revision: 750
Log:
r6019@frost: paul | 2006-01-09 22:10:39 -0600
General revisions.
Modified:
trunk/
trunk/internals/fixedchars.ent
trunk/refman-4.1/innodb.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.1/innodb.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6018
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6019
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
Modified: trunk/internals/fixedchars.ent
===================================================================
--- trunk/internals/fixedchars.ent 2006-01-10 04:12:02 UTC (rev 749)
+++ trunk/internals/fixedchars.ent 2006-01-10 04:12:27 UTC (rev 750)
@@ -241,3 +241,6 @@
<!ENTITY urcrop "⌎">
<!ENTITY pi "ϖ">
<!ENTITY euro "€">
+ <!ENTITY le "≤">
+ <!ENTITY ge "≥">
+ <!ENTITY ddash "--">
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2006-01-10 04:12:02 UTC (rev 749)
+++ trunk/refman-4.1/innodb.xml 2006-01-10 04:12:27 UTC (rev 750)
@@ -1267,8 +1267,7 @@
</para>
<para>
- This option is relevant only on Unix systems. If set to
- <literal>fdatasync</literal> (the default),
+ If set to <literal>fdatasync</literal> (the default),
<literal>InnoDB</literal> uses <literal>fsync()</literal> to
flush both the data and log files. If set to
<literal>O_DSYNC</literal>, <literal>InnoDB</literal> uses
@@ -4198,9 +4197,9 @@
</para>
<para>
- If the locks to be set are exclusive, then
- <literal>InnoDB</literal> always retrieves also the clustered
- index record and sets a lock on it.
+ If the locks to be set are exclusive, <literal>InnoDB</literal>
+ always retrieves also the clustered index record and sets a lock
+ on it.
</para>
<para>
@@ -4212,6 +4211,11 @@
rows.
</para>
+ <para>
+ <literal>InnoDB</literal> sets specific types of locks as
+ follows:
+ </para>
+
<itemizedlist>
<listitem>
@@ -4262,7 +4266,7 @@
auto-increment counter, <literal>InnoDB</literal> uses a
specific table lock mode <literal>AUTO-INC</literal> where
the lock lasts only to the end of the current SQL statement,
- instead of to the end of the whole transaction. See
+ not to the end of the entire transaction. See
<xref linkend="innodb-and-autocommit"/>.
</para>
@@ -4328,9 +4332,9 @@
<listitem>
<para>
If a <literal>FOREIGN KEY</literal> constraint is defined on
- a table, any insert, update, or delete that requires
- checking of the constraint condition sets shared
- record-level locks on the records it looks at to check the
+ a table, any insert, update, or delete that requires the
+ constraint condition to be checked sets shared record-level
+ locks on the records that it looks at to check the
constraint. <literal>InnoDB</literal> also sets these locks
in the case where the constraint fails.
</para>
@@ -4342,7 +4346,7 @@
the higher MySQL layer above the <literal>InnoDB</literal>
layer that sets these locks. Beginning with MySQL 4.0.20 and
4.1.2, <literal>InnoDB</literal> is aware of table locks if
- <literal>innodb_table_locks=1</literal> and
+ <literal>innodb_table_locks=1</literal> (the default) and
<literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
<literal>InnoDB</literal> knows about row-level locks.
Otherwise, InnoDB's automatic deadlock detection cannot
@@ -4370,24 +4374,20 @@
</remark>
<para>
- MySQL begins each client connection with autocommit mode enabled
- by default. When autocommit is enabled, MySQL does a commit
+ By default, MySQL begins each client connection with autocommit
+ mode enabled. When autocommit is enabled, MySQL does a commit
after each SQL statement if that statement did not return an
- error.
+ error. If an SQL statement returns an error, the commit or
+ rollback behavior depends on the error. See
+ <xref linkend="innodb-error-handling"/>.
</para>
<para>
If you have the autocommit mode off and close a connection
- without calling an explicit commit of your transaction, then
- MySQL rolls back your transaction.
+ without explicitly committing the final transaction, MySQL rolls
+ back that transaction.
</para>
- <para>
- If an SQL statement returns an error, the commit or rollback
- behavior depends on the error. See
- <xref linkend="innodb-error-handling"/>.
- </para>
-
<remark role="note">
The following material also appears in id="implicit-commit".
Edits should be made to both sections.
@@ -4462,10 +4462,10 @@
<para>
<literal>InnoDB</literal> automatically detects a deadlock of
transactions and rolls back a transaction or transactions to
- prevent the deadlock. Starting from MySQL 4.0.5,
+ break the deadlock. Starting from MySQL 4.0.5,
<literal>InnoDB</literal> tries to pick small transactions to
- roll back. The size of a transaction is determined by the number
- of rows it has inserted, updated, or deleted. Prior to 4.0.5,
+ roll back, the size of a transaction being determined by the
+ number of rows inserted, updated, or deleted. Prior to 4.0.5,
<literal>InnoDB</literal> always rolled back the transaction
whose lock request was the last one to build a deadlock, that
is, a cycle in the <quote>waits-for</quote> graph of
@@ -4475,25 +4475,25 @@
<para>
Beginning with MySQL 4.0.20 and 4.1.2, <literal>InnoDB</literal>
is aware of table locks if
- <literal>innodb_table_locks=1</literal> (1 is the default), and
- the MySQL layer above <literal>InnoDB</literal> knows about
- row-level locks. Before that, <literal>InnoDB</literal> cannot
- detect deadlocks where a table lock set by a MySQL <literal>LOCK
- TABLES</literal> statement is involved, or if a lock set by
- another storage engine than <literal>InnoDB</literal> is
- involved. You have to resolve these situations by setting the
- value of the <literal>innodb_lock_wait_timeout</literal> system
- variable.
+ <literal>innodb_table_locks=1</literal> (the default) and
+ <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
+ <literal>InnoDB</literal> knows about row-level locks. Before
+ that, <literal>InnoDB</literal> cannot detect deadlocks where a
+ table lock set by a MySQL <literal>LOCK TABLES</literal>
+ statement is involved, or if a lock set by another storage
+ engine than <literal>InnoDB</literal> is involved. You have to
+ resolve these situations by setting the value of the
+ <literal>innodb_lock_wait_timeout</literal> system variable.
</para>
<para>
When <literal>InnoDB</literal> performs a complete rollback of a
- transaction, all the locks of the transaction are released.
+ transaction, all locks set by the transaction are released.
However, if just a single SQL statement is rolled back as a
- result of an error, some of the locks set by the SQL statement
- may be preserved. This happens because <literal>InnoDB</literal>
- stores row locks in a format such it cannot know afterward which
- lock was set by which SQL statement.
+ result of an error, some of the locks set by the statement may
+ be preserved. This happens because <literal>InnoDB</literal>
+ stores row locks in a format such that it cannot know afterward
+ which lock was set by which statement.
</para>
</section>
@@ -4547,7 +4547,7 @@
<listitem>
<para>
Commit your transactions often. Small transactions are less
- prone to collide.
+ prone to collision.
</para>
</listitem>
@@ -4593,18 +4593,19 @@
<para>
If nothing else helps, serialize your transactions with
table-level locks. The correct way to use <literal>LOCK
- TABLES</literal> with transactional tables, like
- <literal>InnoDB</literal>, is to set <literal>AUTOCOMMIT =
- 0</literal> and not to call <literal>UNLOCK TABLES</literal>
- until you commit the transaction explicitly. For example, if
- you need to write to table <literal>t1</literal> and read
- from table <literal>t2</literal>, you can do this:
+ TABLES</literal> with transactional tables, such as
+ <literal>InnoDB</literal> tables, is to set
+ <literal>AUTOCOMMIT = 0</literal> and not to call
+ <literal>UNLOCK TABLES</literal> until after you commit the
+ transaction explicitly. For example, if you need to write to
+ table <literal>t1</literal> and read from table
+ <literal>t2</literal>, you can do this:
</para>
<programlisting>
SET AUTOCOMMIT=0;
LOCK TABLES t1 WRITE, t2 READ, ...;
-[do something with tables t1 and t2 here];
+<replaceable>... do something with tables t1 and t2 here ...</replaceable>
COMMIT;
UNLOCK TABLES;
</programlisting>
@@ -4631,7 +4632,7 @@
<listitem>
<para>
- In applications using <literal>AUTOCOMMIT=1</literal> and
+ In applications that use <literal>AUTOCOMMIT=1</literal> and
MySQL's <literal>LOCK TABLES</literal> command,
<literal>InnoDB</literal>'s internal table locks that were
present from 4.0.20 to 4.0.23 can cause deadlocks. Starting
@@ -4687,8 +4688,8 @@
<listitem>
<para>
If you can afford the loss of some of the latest committed
- transactions, you can set the <filename>my.cnf</filename>
- parameter <literal>innodb_flush_log_at_trx_commit</literal> to
+ transactions if a crash occurs, you can set the
+ <literal>innodb_flush_log_at_trx_commit</literal> parameter to
0. <literal>InnoDB</literal> tries to flush the log once per
second anyway, although the flush is not guaranteed.
</para>
@@ -4718,8 +4719,8 @@
strings or if the column may contain many
<literal>NULL</literal> values. A
<literal>CHAR(<replaceable>N</replaceable>)</literal> column
- always takes <replaceable>N</replaceable> bytes to store data,
- even if the string is shorter or its value is
+ always takes <replaceable>N</replaceable> characters to store
+ data, even if the string is shorter or its value is
<literal>NULL</literal>. Smaller tables fit better in the
buffer pool and reduce disk I/O.
</para>
@@ -4729,15 +4730,14 @@
<para>
(Relevant from 3.23.39 up.) In some versions of GNU/Linux and
Unix, flushing files to disk with the Unix
- <literal>fsync()</literal> and other similar methods is
- surprisingly slow. The default method
- <literal>InnoDB</literal> uses is the
- <literal>fsync()</literal> function. If you are not satisfied
- with the database write performance, you might try setting
- <literal>innodb_flush_method</literal> in
- <filename>my.cnf</filename> to <literal>O_DSYNC</literal>,
- although <literal>O_DSYNC</literal> seems to be slower on most
- systems.
+ <literal>fsync()</literal> call (which
+ <literal>InnoDB</literal> uses by default) and other similar
+ methods is surprisingly slow. If you are dissatisfied with
+ database write performance, you might try setting the
+ <literal>innodb_flush_method</literal> parameter to
+ <literal>O_DSYNC</literal>. Although
+ <literal>O_DSYNC</literal> seems to be slower on most systems,
+ yours might not be one of them.
</para>
</listitem>
@@ -4751,28 +4751,28 @@
<literal>InnoDB</literal>-related files using the
<literal>forcedirectio</literal> option. (The default on
Solaris 10/x86_64 is <emphasis>not</emphasis> to use this
- filesystem mounting option.) Failing to use
- <literal>forcedirectio</literal> will cause a serious
- degradation of <literal>InnoDB</literal>'s speed and
- performance on this platform.
+ option.) Failure to use <literal>forcedirectio</literal>
+ causes a serious degradation of <literal>InnoDB</literal>'s
+ speed and performance on this platform.
</para>
<para>
When using the <literal>InnoDB</literal> storage engine with a
large <literal>innodb_buffer_pool_size</literal> value on any
- release Solaris ≥ 2.6 and any platform
+ release of Solaris 2.6 and up and any platform
(sparc/x86/x64/amd64), a significant performance gain can be
achieved by placing <literal>InnoDB</literal> data files and
log files on raw devices or on a separate direct I/O UFS
- Filesystem (mount option <literal>forcedirectio</literal>; see
+ filesystem (using mount option
+ <literal>forcedirectio</literal>; see
<literal>mount_ufs(1M)</literal>). Users of the Veritas
filesystem VxFS should use the mount option
<literal>convosync=direct</literal>.
</para>
<para>
- Other MySQL data files such as those for
- <literal>MyISAM</literal> tables should not be placed on a
+ Other MySQL data files, such as those for
+ <literal>MyISAM</literal> tables, should not be placed on a
direct I/O filesystem. Executables or libraries <emphasis>must
not</emphasis> be placed on a direct I/O filesystem.
</para>
@@ -4782,7 +4782,7 @@
<para>
When importing data into <literal>InnoDB</literal>, make sure
that MySQL does not have autocommit mode enabled because that
- would require a log flush to disk for every insert. To disable
+ requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
<literal>SET AUTOCOMMIT</literal> and
<literal>COMMIT</literal> statements:
@@ -4790,7 +4790,7 @@
<programlisting>
SET AUTOCOMMIT=0;
-/* SQL import statements ... */
+<replaceable>... SQL import statements ...</replaceable>
COMMIT;
</programlisting>
@@ -7056,14 +7056,13 @@
<para>
Beginning with MySQL 4.0.20 and 4.1.2, the MySQL <literal>LOCK
TABLES</literal> operation acquires two locks on each table if
- <literal>innodb_table_locks=1</literal>. (1 is the default.)
- In addition to a table lock on the MySQL layer, it also
- acquires an <literal>InnoDB</literal> table lock. Older
- versions of MySQL do not acquire <literal>InnoDB</literal>
- table locks. Beginning with MySQL 4.0.22 and 4.1.7, the old
- behavior can be selected by setting
- <literal>innodb_table_locks=0</literal>. If no
- <literal>InnoDB</literal> table lock is acquired,
+ <literal>innodb_table_locks=1</literal> (the default). In
+ addition to a table lock on the MySQL layer, it also acquires
+ an <literal>InnoDB</literal> table lock. Older versions of
+ MySQL do not acquire <literal>InnoDB</literal> table locks.
+ Beginning with MySQL 4.0.22 and 4.1.7, the old behavior can be
+ selected by setting <literal>innodb_table_locks=0</literal>.
+ If no <literal>InnoDB</literal> table lock is acquired,
<literal>LOCK TABLES</literal> completes even if some records
of the tables are being locked by other transactions.
</para>
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-01-10 04:12:02 UTC (rev 749)
+++ trunk/refman-5.0/innodb.xml 2006-01-10 04:12:27 UTC (rev 750)
@@ -1191,8 +1191,7 @@
</para>
<para>
- This option is relevant only on Unix systems. If set to
- <literal>fdatasync</literal> (the default),
+ If set to <literal>fdatasync</literal> (the default),
<literal>InnoDB</literal> uses <literal>fsync()</literal> to
flush both the data and log files. If set to
<literal>O_DSYNC</literal>, <literal>InnoDB</literal> uses
@@ -4141,9 +4140,9 @@
</para>
<para>
- If the locks to be set are exclusive, then
- <literal>InnoDB</literal> always retrieves also the clustered
- index record and sets a lock on it.
+ If the locks to be set are exclusive, <literal>InnoDB</literal>
+ always retrieves also the clustered index record and sets a lock
+ on it.
</para>
<para>
@@ -4155,6 +4154,11 @@
rows.
</para>
+ <para>
+ <literal>InnoDB</literal> sets specific types of locks as
+ follows:
+ </para>
+
<itemizedlist>
<listitem>
@@ -4205,7 +4209,7 @@
auto-increment counter, <literal>InnoDB</literal> uses a
specific table lock mode <literal>AUTO-INC</literal> where
the lock lasts only to the end of the current SQL statement,
- instead of to the end of the whole transaction. See
+ not to the end of the entire transaction. See
<xref linkend="innodb-and-autocommit"/>.
</para>
@@ -4264,9 +4268,9 @@
<listitem>
<para>
If a <literal>FOREIGN KEY</literal> constraint is defined on
- a table, any insert, update, or delete that requires
- checking of the constraint condition sets shared
- record-level locks on the records it looks at to check the
+ a table, any insert, update, or delete that requires the
+ constraint condition to be checked sets shared record-level
+ locks on the records that it looks at to check the
constraint. <literal>InnoDB</literal> also sets these locks
in the case where the constraint fails.
</para>
@@ -4278,7 +4282,7 @@
the higher MySQL layer above the <literal>InnoDB</literal>
layer that sets these locks. <literal>InnoDB</literal> is
aware of table locks if
- <literal>innodb_table_locks=1</literal> and
+ <literal>innodb_table_locks=1</literal> (the default) and
<literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
<literal>InnoDB</literal> knows about row-level locks.
Otherwise, <literal>InnoDB</literal>'s automatic deadlock
@@ -4306,24 +4310,20 @@
</remark>
<para>
- MySQL begins each client connection with autocommit mode enabled
- by default. When autocommit is enabled, MySQL does a commit
+ By default, MySQL begins each client connection with autocommit
+ mode enabled. When autocommit is enabled, MySQL does a commit
after each SQL statement if that statement did not return an
- error.
+ error. If an SQL statement returns an error, the commit or
+ rollback behavior depends on the error. See
+ <xref linkend="innodb-error-handling"/>.
</para>
<para>
If you have the autocommit mode off and close a connection
- without calling an explicit commit of your transaction, then
- MySQL rolls back your transaction.
+ without explicitly committing the final transaction, MySQL rolls
+ back that transaction.
</para>
- <para>
- If an SQL statement returns an error, the commit or rollback
- behavior depends on the error. See
- <xref linkend="innodb-error-handling"/>.
- </para>
-
<remark role="note">
The following material also appears in id="implicit-commit".
Edits should be made to both sections.
@@ -4407,15 +4407,17 @@
<para>
<literal>InnoDB</literal> automatically detects a deadlock of
transactions and rolls back a transaction or transactions to
- prevent the deadlock. <literal>InnoDB</literal> tries to pick
- small transactions to roll back, the size of a transaction being
- determined by the number of rows inserted, updated, or deleted.
+ break the deadlock. <literal>InnoDB</literal> tries to pick
+ small transactions to roll back, where the size of a transaction
+ is determined by the number of rows inserted, updated, or
+ deleted.
</para>
<para>
<literal>InnoDB</literal> is aware of table locks if
- <literal>innodb_table_locks=1</literal> (1 is the default), and
- the MySQL layer above it knows about row-level locks. Otherwise,
+ <literal>innodb_table_locks=1</literal> (the default) and
+ <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above it
+ knows about row-level locks. Otherwise,
<literal>InnoDB</literal> cannot detect deadlocks where a table
lock set by a MySQL <literal>LOCK TABLES</literal> statement or
a lock set by a storage engine other than
@@ -4426,12 +4428,12 @@
<para>
When <literal>InnoDB</literal> performs a complete rollback of a
- transaction, all the locks of the transaction are released.
+ transaction, all locks set by the transaction are released.
However, if just a single SQL statement is rolled back as a
- result of an error, some of the locks set by the SQL statement
- may be preserved. This happens because <literal>InnoDB</literal>
- stores row locks in a format such it cannot know afterward which
- lock was set by which SQL statement.
+ result of an error, some of the locks set by the statement may
+ be preserved. This happens because <literal>InnoDB</literal>
+ stores row locks in a format such that it cannot know afterward
+ which lock was set by which statement.
</para>
</section>
@@ -4482,7 +4484,7 @@
<listitem>
<para>
Commit your transactions often. Small transactions are less
- prone to collide.
+ prone to collision.
</para>
</listitem>
@@ -4528,18 +4530,19 @@
<para>
If nothing else helps, serialize your transactions with
table-level locks. The correct way to use <literal>LOCK
- TABLES</literal> with transactional tables, like
- <literal>InnoDB</literal>, is to set <literal>AUTOCOMMIT =
- 0</literal> and not to call <literal>UNLOCK TABLES</literal>
- until you commit the transaction explicitly. For example, if
- you need to write to table <literal>t1</literal> and read
- from table <literal>t2</literal>, you can do this:
+ TABLES</literal> with transactional tables, such as
+ <literal>InnoDB</literal> tables, is to set
+ <literal>AUTOCOMMIT = 0</literal> and not to call
+ <literal>UNLOCK TABLES</literal> until after you commit the
+ transaction explicitly. For example, if you need to write to
+ table <literal>t1</literal> and read from table
+ <literal>t2</literal>, you can do this:
</para>
<programlisting>
SET AUTOCOMMIT=0;
LOCK TABLES t1 WRITE, t2 READ, ...;
-[do something with tables t1 and t2 here];
+<replaceable>... do something with tables t1 and t2 here ...</replaceable>
COMMIT;
UNLOCK TABLES;
</programlisting>
@@ -4566,7 +4569,7 @@
<listitem>
<para>
- In applications using the <literal>LOCK TABLES</literal>
+ In applications that use the <literal>LOCK TABLES</literal>
command, MySQL does not set <literal>InnoDB</literal> table
locks if <literal>AUTOCOMMIT=1</literal>.
</para>
@@ -4615,8 +4618,8 @@
<listitem>
<para>
If you can afford the loss of some of the latest committed
- transactions, you can set the <filename>my.cnf</filename>
- parameter <literal>innodb_flush_log_at_trx_commit</literal> to
+ transactions if a crash occurs, you can set the
+ <literal>innodb_flush_log_at_trx_commit</literal> parameter to
0. <literal>InnoDB</literal> tries to flush the log once per
second anyway, although the flush is not guaranteed.
</para>
@@ -4646,8 +4649,8 @@
strings or if the column may contain many
<literal>NULL</literal> values. A
<literal>CHAR(<replaceable>N</replaceable>)</literal> column
- always takes <replaceable>N</replaceable> bytes to store data,
- even if the string is shorter or its value is
+ always takes <replaceable>N</replaceable> characters to store
+ data, even if the string is shorter or its value is
<literal>NULL</literal>. Smaller tables fit better in the
buffer pool and reduce disk I/O.
</para>
@@ -4666,14 +4669,14 @@
<listitem>
<para>
In some versions of GNU/Linux and Unix, flushing files to disk
- with the Unix <literal>fsync()</literal> (which
+ with the Unix <literal>fsync()</literal> call (which
<literal>InnoDB</literal> uses by default) and other similar
methods is surprisingly slow. If you are dissatisfied with
- database write performance, you might try setting
- <literal>innodb_flush_method</literal> in
- <filename>my.cnf</filename> to <literal>O_DSYNC</literal>,
- although <literal>O_DSYNC</literal> seems to be slower on most
- systems.
+ database write performance, you might try setting the
+ <literal>innodb_flush_method</literal> parameter to
+ <literal>O_DSYNC</literal>. Although
+ <literal>O_DSYNC</literal> seems to be slower on most systems,
+ yours might not be one of them.
</para>
</listitem>
@@ -4685,28 +4688,28 @@
<literal>InnoDB</literal>-related files using the
<literal>forcedirectio</literal> option. (The default on
Solaris 10/x86_64 is <emphasis>not</emphasis> to use this
- filesystem mounting option.) Failing to use
- <literal>forcedirectio</literal> will cause a serious
- degradation of <literal>InnoDB</literal>'s speed and
- performance on this platform.
+ option.) Failure to use <literal>forcedirectio</literal>
+ causes a serious degradation of <literal>InnoDB</literal>'s
+ speed and performance on this platform.
</para>
<para>
When using the <literal>InnoDB</literal> storage engine with a
large <literal>innodb_buffer_pool_size</literal> value on any
- release Solaris ≥ 2.6 and any platform
+ release of Solaris 2.6 and up and any platform
(sparc/x86/x64/amd64), a significant performance gain can be
achieved by placing <literal>InnoDB</literal> data files and
log files on raw devices or on a separate direct I/O UFS
- Filesystem (mount option <literal>forcedirectio</literal>; see
+ filesystem (using mount option
+ <literal>forcedirectio</literal>; see
<literal>mount_ufs(1M)</literal>). Users of the Veritas
filesystem VxFS should use the mount option
<literal>convosync=direct</literal>.
</para>
<para>
- Other MySQL data files such as those for
- <literal>MyISAM</literal> tables should not be placed on a
+ Other MySQL data files, such as those for
+ <literal>MyISAM</literal> tables, should not be placed on a
direct I/O filesystem. Executables or libraries <emphasis>must
not</emphasis> be placed on a direct I/O filesystem.
</para>
@@ -4716,7 +4719,7 @@
<para>
When importing data into <literal>InnoDB</literal>, make sure
that MySQL does not have autocommit mode enabled because that
- would require a log flush to disk for every insert. To disable
+ requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
<literal>SET AUTOCOMMIT</literal> and
<literal>COMMIT</literal> statements:
@@ -4724,7 +4727,7 @@
<programlisting>
SET AUTOCOMMIT=0;
-/* SQL import statements ... */
+<replaceable>... SQL import statements ...</replaceable>
COMMIT;
</programlisting>
@@ -6971,11 +6974,11 @@
<para>
In MySQL ¤t-series;, the MySQL <literal>LOCK
TABLES</literal> operation acquires two locks on each table if
- <literal>innodb_table_locks=1</literal>, with 1 being the
- default.) In addition to a table lock on the MySQL layer, it
- also acquires an <literal>InnoDB</literal> table lock. Older
- versions of MySQL did not acquire <literal>InnoDB</literal>
- table locks; the old behavior can be selected by setting
+ <literal>innodb_table_locks=1</literal> (the default). In
+ addition to a table lock on the MySQL layer, it also acquires
+ an <literal>InnoDB</literal> table lock. Older versions of
+ MySQL did not acquire <literal>InnoDB</literal> table locks;
+ the old behavior can be selected by setting
<literal>innodb_table_locks=0</literal>. If no
<literal>InnoDB</literal> table lock is acquired,
<literal>LOCK TABLES</literal> completes even if some records
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2006-01-10 04:12:02 UTC (rev 749)
+++ trunk/refman-5.1/innodb.xml 2006-01-10 04:12:27 UTC (rev 750)
@@ -1188,8 +1188,7 @@
</para>
<para>
- This option is relevant only on Unix systems. If set to
- <literal>fdatasync</literal> (the default),
+ If set to <literal>fdatasync</literal> (the default),
<literal>InnoDB</literal> uses <literal>fsync()</literal> to
flush both the data and log files. If set to
<literal>O_DSYNC</literal>, <literal>InnoDB</literal> uses
@@ -4117,9 +4116,9 @@
</para>
<para>
- If the locks to be set are exclusive, then
- <literal>InnoDB</literal> always retrieves also the clustered
- index record and sets a lock on it.
+ If the locks to be set are exclusive, <literal>InnoDB</literal>
+ always retrieves also the clustered index record and sets a lock
+ on it.
</para>
<para>
@@ -4131,6 +4130,11 @@
rows.
</para>
+ <para>
+ <literal>InnoDB</literal> sets specific types of locks as
+ follows:
+ </para>
+
<itemizedlist>
<listitem>
@@ -4181,7 +4185,7 @@
auto-increment counter, <literal>InnoDB</literal> uses a
specific table lock mode <literal>AUTO-INC</literal> where
the lock lasts only to the end of the current SQL statement,
- instead of to the end of the whole transaction. See
+ not to the end of the entire transaction. See
<xref linkend="innodb-and-autocommit"/>.
</para>
@@ -4240,9 +4244,9 @@
<listitem>
<para>
If a <literal>FOREIGN KEY</literal> constraint is defined on
- a table, any insert, update, or delete that requires
- checking of the constraint condition sets shared
- record-level locks on the records it looks at to check the
+ a table, any insert, update, or delete that requires the
+ constraint condition to be checked sets shared record-level
+ locks on the records that it looks at to check the
constraint. <literal>InnoDB</literal> also sets these locks
in the case where the constraint fails.
</para>
@@ -4254,7 +4258,7 @@
the higher MySQL layer above the <literal>InnoDB</literal>
layer that sets these locks. <literal>InnoDB</literal> is
aware of table locks if
- <literal>innodb_table_locks=1</literal> and
+ <literal>innodb_table_locks=1</literal> (the default) and
<literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
<literal>InnoDB</literal> knows about row-level locks.
Otherwise, <literal>InnoDB</literal>'s automatic deadlock
@@ -4282,24 +4286,20 @@
</remark>
<para>
- MySQL begins each client connection with autocommit mode enabled
- by default. When autocommit is enabled, MySQL does a commit
+ By default, MySQL begins each client connection with autocommit
+ mode enabled. When autocommit is enabled, MySQL does a commit
after each SQL statement if that statement did not return an
- error.
+ error. If an SQL statement returns an error, the commit or
+ rollback behavior depends on the error. See
+ <xref linkend="innodb-error-handling"/>.
</para>
<para>
If you have the autocommit mode off and close a connection
- without calling an explicit commit of your transaction, then
- MySQL rolls back your transaction.
+ without explicitly committing the final transaction, MySQL rolls
+ back that transaction.
</para>
- <para>
- If an SQL statement returns an error, the commit or rollback
- behavior depends on the error. See
- <xref linkend="innodb-error-handling"/>.
- </para>
-
<remark role="note">
The following material also appears in id="implicit-commit".
Edits should be made to both sections.
@@ -4368,15 +4368,17 @@
<para>
<literal>InnoDB</literal> automatically detects a deadlock of
transactions and rolls back a transaction or transactions to
- prevent the deadlock. <literal>InnoDB</literal> tries to pick
- small transactions to roll back, the size of a transaction being
- determined by the number of rows inserted, updated, or deleted.
+ break the deadlock. <literal>InnoDB</literal> tries to pick
+ small transactions to roll back, where the size of a transaction
+ is determined by the number of rows inserted, updated, or
+ deleted.
</para>
<para>
<literal>InnoDB</literal> is aware of table locks if
- <literal>innodb_table_locks=1</literal> (1 is the default), and
- the MySQL layer above it knows about row-level locks. Otherwise,
+ <literal>innodb_table_locks=1</literal> (the default) and
+ <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above it
+ knows about row-level locks. Otherwise,
<literal>InnoDB</literal> cannot detect deadlocks where a table
lock set by a MySQL <literal>LOCK TABLES</literal> statement or
a lock set by a storage engine other than
@@ -4387,12 +4389,12 @@
<para>
When <literal>InnoDB</literal> performs a complete rollback of a
- transaction, all the locks of the transaction are released.
+ transaction, all locks set by the transaction are released.
However, if just a single SQL statement is rolled back as a
- result of an error, some of the locks set by the SQL statement
- may be preserved. This happens because <literal>InnoDB</literal>
- stores row locks in a format such it cannot know afterward which
- lock was set by which SQL statement.
+ result of an error, some of the locks set by the statement may
+ be preserved. This happens because <literal>InnoDB</literal>
+ stores row locks in a format such that it cannot know afterward
+ which lock was set by which statement.
</para>
</section>
@@ -4443,7 +4445,7 @@
<listitem>
<para>
Commit your transactions often. Small transactions are less
- prone to collide.
+ prone to collision.
</para>
</listitem>
@@ -4489,18 +4491,19 @@
<para>
If nothing else helps, serialize your transactions with
table-level locks. The correct way to use <literal>LOCK
- TABLES</literal> with transactional tables, like
- <literal>InnoDB</literal>, is to set <literal>AUTOCOMMIT =
- 0</literal> and not to call <literal>UNLOCK TABLES</literal>
- until you commit the transaction explicitly. For example, if
- you need to write to table <literal>t1</literal> and read
- from table <literal>t2</literal>, you can do this:
+ TABLES</literal> with transactional tables, such as
+ <literal>InnoDB</literal> tables, is to set
+ <literal>AUTOCOMMIT = 0</literal> and not to call
+ <literal>UNLOCK TABLES</literal> until after you commit the
+ transaction explicitly. For example, if you need to write to
+ table <literal>t1</literal> and read from table
+ <literal>t2</literal>, you can do this:
</para>
<programlisting>
SET AUTOCOMMIT=0;
LOCK TABLES t1 WRITE, t2 READ, ...;
-[do something with tables t1 and t2 here];
+<replaceable>... do something with tables t1 and t2 here ...</replaceable>
COMMIT;
UNLOCK TABLES;
</programlisting>
@@ -4527,7 +4530,7 @@
<listitem>
<para>
- In applications using the <literal>LOCK TABLES</literal>
+ In applications that use the <literal>LOCK TABLES</literal>
command, MySQL does not set <literal>InnoDB</literal> table
locks if <literal>AUTOCOMMIT=1</literal>.
</para>
@@ -4576,8 +4579,8 @@
<listitem>
<para>
If you can afford the loss of some of the latest committed
- transactions, you can set the <filename>my.cnf</filename>
- parameter <literal>innodb_flush_log_at_trx_commit</literal> to
+ transactions if a crash occurs, you can set the
+ <literal>innodb_flush_log_at_trx_commit</literal> parameter to
0. <literal>InnoDB</literal> tries to flush the log once per
second anyway, although the flush is not guaranteed.
</para>
@@ -4607,8 +4610,8 @@
strings or if the column may contain many
<literal>NULL</literal> values. A
<literal>CHAR(<replaceable>N</replaceable>)</literal> column
- always takes <replaceable>N</replaceable> bytes to store data,
- even if the string is shorter or its value is
+ always takes <replaceable>N</replaceable> characters to store
+ data, even if the string is shorter or its value is
<literal>NULL</literal>. Smaller tables fit better in the
buffer pool and reduce disk I/O.
</para>
@@ -4627,14 +4630,14 @@
<listitem>
<para>
In some versions of GNU/Linux and Unix, flushing files to disk
- with the Unix <literal>fsync()</literal> (which
+ with the Unix <literal>fsync()</literal> call (which
<literal>InnoDB</literal> uses by default) and other similar
methods is surprisingly slow. If you are dissatisfied with
- database write performance, you might try setting
- <literal>innodb_flush_method</literal> in
- <filename>my.cnf</filename> to <literal>O_DSYNC</literal>,
- although <literal>O_DSYNC</literal> seems to be slower on most
- systems.
+ database write performance, you might try setting the
+ <literal>innodb_flush_method</literal> parameter to
+ <literal>O_DSYNC</literal>. Although
+ <literal>O_DSYNC</literal> seems to be slower on most systems,
+ yours might not be one of them.
</para>
</listitem>
@@ -4646,28 +4649,28 @@
<literal>InnoDB</literal>-related files using the
<literal>forcedirectio</literal> option. (The default on
Solaris 10/x86_64 is <emphasis>not</emphasis> to use this
- filesystem mounting option.) Failing to use
- <literal>forcedirectio</literal> will cause a serious
- degradation of <literal>InnoDB</literal>'s speed and
- performance on this platform.
+ option.) Failure to use <literal>forcedirectio</literal>
+ causes a serious degradation of <literal>InnoDB</literal>'s
+ speed and performance on this platform.
</para>
<para>
When using the <literal>InnoDB</literal> storage engine with a
large <literal>innodb_buffer_pool_size</literal> value on any
- release Solaris ≥ 2.6 and any platform
+ release of Solaris 2.6 and up and any platform
(sparc/x86/x64/amd64), a significant performance gain can be
achieved by placing <literal>InnoDB</literal> data files and
log files on raw devices or on a separate direct I/O UFS
- Filesystem (mount option <literal>forcedirectio</literal>; see
+ filesystem (using mount option
+ <literal>forcedirectio</literal>; see
<literal>mount_ufs(1M)</literal>). Users of the Veritas
filesystem VxFS should use the mount option
<literal>convosync=direct</literal>.
</para>
<para>
- Other MySQL data files such as those for
- <literal>MyISAM</literal> tables should not be placed on a
+ Other MySQL data files, such as those for
+ <literal>MyISAM</literal> tables, should not be placed on a
direct I/O filesystem. Executables or libraries <emphasis>must
not</emphasis> be placed on a direct I/O filesystem.
</para>
@@ -4677,7 +4680,7 @@
<para>
When importing data into <literal>InnoDB</literal>, make sure
that MySQL does not have autocommit mode enabled because that
- would require a log flush to disk for every insert. To disable
+ requires a log flush to disk for every insert. To disable
autocommit during your import operation, surround it with
<literal>SET AUTOCOMMIT</literal> and
<literal>COMMIT</literal> statements:
@@ -4685,7 +4688,7 @@
<programlisting>
SET AUTOCOMMIT=0;
-/* SQL import statements ... */
+<replaceable>... SQL import statements ...</replaceable>
COMMIT;
</programlisting>
@@ -6906,11 +6909,11 @@
<para>
In MySQL ¤t-series;, the MySQL <literal>LOCK
TABLES</literal> operation acquires two locks on each table if
- <literal>innodb_table_locks=1</literal>, with 1 being the
- default.) In addition to a table lock on the MySQL layer, it
- also acquires an <literal>InnoDB</literal> table lock. Older
- versions of MySQL did not acquire <literal>InnoDB</literal>
- table locks; the old behavior can be selected by setting
+ <literal>innodb_table_locks=1</literal> (the default). In
+ addition to a table lock on the MySQL layer, it also acquires
+ an <literal>InnoDB</literal> table lock. Older versions of
+ MySQL did not acquire <literal>InnoDB</literal> table locks;
+ the old behavior can be selected by setting
<literal>innodb_table_locks=0</literal>. If no
<literal>InnoDB</literal> table lock is acquired,
<literal>LOCK TABLES</literal> completes even if some records
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r750 - in trunk: . internals refman-4.1 refman-5.0 refman-5.1 | paul | 10 Jan |
