Author: paul
Date: 2009-04-08 21:13:49 +0200 (Wed, 08 Apr 2009)
New Revision: 14553
Log:
r40317@frost: paul | 2009-04-08 12:45:42 -0500
InnoDB minor revisions
Modified:
trunk/refman-4.1/se-innodb-core.xml
trunk/refman-5.0/se-innodb-core.xml
trunk/refman-5.1/se-innodb-core.xml
trunk/refman-6.0/se-innodb-core.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:41755
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:40304
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:37553
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:41755
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:40317
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:37553
Modified: trunk/refman-4.1/se-innodb-core.xml
===================================================================
--- trunk/refman-4.1/se-innodb-core.xml 2009-04-08 16:49:12 UTC (rev 14552)
+++ trunk/refman-4.1/se-innodb-core.xml 2009-04-08 19:13:49 UTC (rev 14553)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 5; 1590 bytes
@@ -1797,7 +1797,8 @@
one session has a shared or exclusive lock on record
<literal>R</literal> in an index, another session cannot
insert a new index record in the gap immediately before
- <literal>R</literal> in the index order.
+ <literal>R</literal> in the index order. See
+ <xref linkend="innodb-record-level-locks"/>.
</para>
<para>
@@ -4129,8 +4130,8 @@
</para>
<para>
- For more information about row-level locking and the circumstances
- under which gap locking is disabled, see
+ For more information about row-level locking, and the
+ circumstances under which gap locking is disabled, see
<xref linkend="innodb-record-level-locks"/>.
</para>
@@ -5070,8 +5071,10 @@
exact <literal>WHERE</literal> condition, but only knows which
index ranges were scanned. The locks are normally next-key locks
that also block inserts into the <quote>gap</quote> immediately
- before the record (see
- <xref linkend="innodb-record-level-locks"/>).
+ before the record. However, gap locking can be disabled
+ explicitly, which causes next-key locking not to be used. For
+ more information, see
+ <xref linkend="innodb-record-level-locks"/>.
</para>
<para>
Modified: trunk/refman-5.0/se-innodb-core.xml
===================================================================
--- trunk/refman-5.0/se-innodb-core.xml 2009-04-08 16:49:12 UTC (rev 14552)
+++ trunk/refman-5.0/se-innodb-core.xml 2009-04-08 19:13:49 UTC (rev 14553)
Changed blocks: 4, Lines Added: 13, Lines Deleted: 7; 2160 bytes
@@ -1764,7 +1764,8 @@
one session has a shared or exclusive lock on record
<literal>R</literal> in an index, another session cannot
insert a new index record in the gap immediately before
- <literal>R</literal> in the index order.
+ <literal>R</literal> in the index order. See
+ <xref linkend="innodb-record-level-locks"/>.
</para>
<para>
@@ -1872,10 +1873,13 @@
<literal role="stmt">UPDATE</literal> to overtake other
similar operations (such as another
<literal role="stmt">UPDATE</literal>) even when they affect
- different rows. Consider the following example, beginning with
- this table:
+ different rows.
</para>
+ <para>
+ Consider the following example, beginning with this table:
+ </para>
+
<programlisting>
CREATE TABLE t (a INT NOT NULL, b INT) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
@@ -4234,8 +4238,8 @@
</para>
<para>
- For more information about row-level locking and the circumstances
- under which gap locking is disabled, see
+ For more information about row-level locking, and the
+ circumstances under which gap locking is disabled, see
<xref linkend="innodb-record-level-locks"/>.
</para>
@@ -5204,8 +5208,10 @@
exact <literal>WHERE</literal> condition, but only knows which
index ranges were scanned. The locks are normally next-key locks
that also block inserts into the <quote>gap</quote> immediately
- before the record (see
- <xref linkend="innodb-record-level-locks"/>).
+ before the record. However, gap locking can be disabled
+ explicitly, which causes next-key locking not to be used. For
+ more information, see
+ <xref linkend="innodb-record-level-locks"/>.
</para>
<para>
Modified: trunk/refman-5.1/se-innodb-core.xml
===================================================================
--- trunk/refman-5.1/se-innodb-core.xml 2009-04-08 16:49:12 UTC (rev 14552)
+++ trunk/refman-5.1/se-innodb-core.xml 2009-04-08 19:13:49 UTC (rev 14553)
Changed blocks: 5, Lines Added: 44, Lines Deleted: 44; 5562 bytes
@@ -1862,7 +1862,8 @@
one session has a shared or exclusive lock on record
<literal>R</literal> in an index, another session cannot
insert a new index record in the gap immediately before
- <literal>R</literal> in the index order.
+ <literal>R</literal> in the index order. See
+ <xref linkend="innodb-record-level-locks"/>.
</para>
<para>
@@ -1958,26 +1959,44 @@
<para>
Enabling
<literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
- has additional effects. For
- <literal role="stmt">UPDATE</literal> or
- <literal role="stmt">DELETE</literal> statements,
- <literal>InnoDB</literal> holds locks only for rows that it
- updates or deletes. Record locks for non-matching rows are
- released after MySQL has evaluated the
- <literal>WHERE</literal> condition. This greatly reduces the
- probability of deadlocks, but they can still happen. Also, for
- <literal role="stmt">UPDATE</literal> statements, if a row is
- already locked, <literal>InnoDB</literal> performs a
- <quote>semi-consistent</quote> read, returning the latest
- committed version to MySQL so that MySQL can determine whether
- the row matches the <literal>WHERE</literal> condition of the
- <literal role="stmt">UPDATE</literal>. If the row matches
- (must be updated), MySQL reads the row again and this time
- <literal>InnoDB</literal> either locks it or waits for a lock
- on it. Consider the following example, beginning with this
- table:
+ has additional effects:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ For <literal role="stmt">UPDATE</literal> or
+ <literal role="stmt">DELETE</literal> statements,
+ <literal>InnoDB</literal> holds locks only for rows that
+ it updates or deletes. Record locks for non-matching rows
+ are released after MySQL has evaluated the
+ <literal>WHERE</literal> condition. This greatly reduces
+ the probability of deadlocks, but they can still happen.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For <literal role="stmt">UPDATE</literal> statements, if a
+ row is already locked, <literal>InnoDB</literal> performs
+ a <quote>semi-consistent</quote> read, returning the
+ latest committed version to MySQL so that MySQL can
+ determine whether the row matches the
+ <literal>WHERE</literal> condition of the
+ <literal role="stmt">UPDATE</literal>. If the row matches
+ (must be updated), MySQL reads the row again and this time
+ <literal>InnoDB</literal> either locks it or waits for a
+ lock on it.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Consider the following example, beginning with this table:
+ </para>
+
<programlisting>
CREATE TABLE t (a INT NOT NULL, b INT) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
@@ -5025,8 +5044,8 @@
</para>
<para>
- For more information about row-level locking and the circumstances
- under which gap locking is disabled, see
+ For more information about row-level locking, and the
+ circumstances under which gap locking is disabled, see
<xref linkend="innodb-record-level-locks"/>.
</para>
@@ -6001,8 +6020,10 @@
exact <literal>WHERE</literal> condition, but only knows which
index ranges were scanned. The locks are normally next-key locks
that also block inserts into the <quote>gap</quote> immediately
- before the record (see
- <xref linkend="innodb-record-level-locks"/>).
+ before the record. However, gap locking can be disabled
+ explicitly, which causes next-key locking not to be used. For
+ more information, see
+ <xref linkend="innodb-record-level-locks"/>.
</para>
<para>
@@ -6254,27 +6275,6 @@
</para>
</listitem>
- <listitem>
- <para>
- In MySQL ¤t-series;, if the
- <literal role="isolevel">READ COMMITTED</literal> isolation
- level is used or the
- <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
- system variable is enabled, there is no
- <literal>InnoDB</literal> gap locking except for foreign-key
- constraint checking and duplicate-key checking. Also, record
- locks for non-matching rows are released after MySQL has
- evaluated the <literal>WHERE</literal> condition. For
- <literal>UPDATE</literal> statements,
- <literal role="se">InnoDB</literal> does a
- <quote>semi-consistent</quote> read, such that it returns
- the latest committed version to MySQL so that MySQL can
- determine whether the row matches the
- <literal>WHERE</literal> condition of the
- <literal role="stmt">UPDATE</literal>.
- </para>
- </listitem>
-
</itemizedlist>
</section>
Modified: trunk/refman-6.0/se-innodb-core.xml
===================================================================
--- trunk/refman-6.0/se-innodb-core.xml 2009-04-08 16:49:12 UTC (rev 14552)
+++ trunk/refman-6.0/se-innodb-core.xml 2009-04-08 19:13:49 UTC (rev 14553)
Changed blocks: 5, Lines Added: 44, Lines Deleted: 44; 5562 bytes
@@ -1747,7 +1747,8 @@
one session has a shared or exclusive lock on record
<literal>R</literal> in an index, another session cannot
insert a new index record in the gap immediately before
- <literal>R</literal> in the index order.
+ <literal>R</literal> in the index order. See
+ <xref linkend="innodb-record-level-locks"/>.
</para>
<para>
@@ -1843,26 +1844,44 @@
<para>
Enabling
<literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
- has additional effects. For
- <literal role="stmt">UPDATE</literal> or
- <literal role="stmt">DELETE</literal> statements,
- <literal>InnoDB</literal> holds locks only for rows that it
- updates or deletes. Record locks for non-matching rows are
- released after MySQL has evaluated the
- <literal>WHERE</literal> condition. This greatly reduces the
- probability of deadlocks, but they can still happen. Also, for
- <literal role="stmt">UPDATE</literal> statements, if a row is
- already locked, <literal>InnoDB</literal> performs a
- <quote>semi-consistent</quote> read, returning the latest
- committed version to MySQL so that MySQL can determine whether
- the row matches the <literal>WHERE</literal> condition of the
- <literal role="stmt">UPDATE</literal>. If the row matches
- (must be updated), MySQL reads the row again and this time
- <literal>InnoDB</literal> either locks it or waits for a lock
- on it. Consider the following example, beginning with this
- table:
+ has additional effects:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ For <literal role="stmt">UPDATE</literal> or
+ <literal role="stmt">DELETE</literal> statements,
+ <literal>InnoDB</literal> holds locks only for rows that
+ it updates or deletes. Record locks for non-matching rows
+ are released after MySQL has evaluated the
+ <literal>WHERE</literal> condition. This greatly reduces
+ the probability of deadlocks, but they can still happen.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For <literal role="stmt">UPDATE</literal> statements, if a
+ row is already locked, <literal>InnoDB</literal> performs
+ a <quote>semi-consistent</quote> read, returning the
+ latest committed version to MySQL so that MySQL can
+ determine whether the row matches the
+ <literal>WHERE</literal> condition of the
+ <literal role="stmt">UPDATE</literal>. If the row matches
+ (must be updated), MySQL reads the row again and this time
+ <literal>InnoDB</literal> either locks it or waits for a
+ lock on it.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ Consider the following example, beginning with this table:
+ </para>
+
<programlisting>
CREATE TABLE t (a INT NOT NULL, b INT) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
@@ -4814,8 +4833,8 @@
</para>
<para>
- For more information about row-level locking and the circumstances
- under which gap locking is disabled, see
+ For more information about row-level locking, and the
+ circumstances under which gap locking is disabled, see
<xref linkend="innodb-record-level-locks"/>.
</para>
@@ -5790,8 +5809,10 @@
exact <literal>WHERE</literal> condition, but only knows which
index ranges were scanned. The locks are normally next-key locks
that also block inserts into the <quote>gap</quote> immediately
- before the record (see
- <xref linkend="innodb-record-level-locks"/>).
+ before the record. However, gap locking can be disabled
+ explicitly, which causes next-key locking not to be used. For
+ more information, see
+ <xref linkend="innodb-record-level-locks"/>.
</para>
<para>
@@ -6043,27 +6064,6 @@
</para>
</listitem>
- <listitem>
- <para>
- In MySQL ¤t-series;, if the
- <literal role="isolevel">READ COMMITTED</literal> isolation
- level is used or the
- <literal role="sysvar">innodb_locks_unsafe_for_binlog</literal>
- system variable is enabled, there is no
- <literal>InnoDB</literal> gap locking except for foreign-key
- constraint checking and duplicate-key checking. Also, record
- locks for non-matching rows are released after MySQL has
- evaluated the <literal>WHERE</literal> condition. For
- <literal>UPDATE</literal> statements,
- <literal role="se">InnoDB</literal> does a
- <quote>semi-consistent</quote> read, such that it returns
- the latest committed version to MySQL so that MySQL can
- determine whether the row matches the
- <literal>WHERE</literal> condition of the
- <literal role="stmt">UPDATE</literal>.
- </para>
- </listitem>
-
</itemizedlist>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r14553 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul.dubois | 8 Apr |
