Author: paul
Date: 2006-01-09 17:07:01 +0100 (Mon, 09 Jan 2006)
New Revision: 741
Log:
r5992@frost: paul | 2006-01-09 09:06:52 -0600
Fix use of "query" for non-query statements.
Modified:
trunk/
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:5991
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5992
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2006-01-09 16:06:44 UTC (rev 740)
+++ trunk/refman-4.1/innodb.xml 2006-01-09 16:07:01 UTC (rev 741)
@@ -4247,14 +4247,14 @@
<para>
A locking read, an <literal>UPDATE</literal>, or a
<literal>DELETE</literal> generally set record locks on every
- index record that is scanned in the processing of the SQL query.
- It does not matter if there are <literal>WHERE</literal>
- conditions in the query that would exclude the row from the
- result set of the query. <literal>InnoDB</literal> does not
- remember the exact <literal>WHERE</literal> condition, but only
- knows which index ranges were scanned. The record locks are
- normally next-key locks that also block inserts to the
- <quote>gap</quote> immediately before the record.
+ index record that is scanned in the processing of the SQL
+ statement. It does not matter if there are
+ <literal>WHERE</literal> conditions in the statement that would
+ exclude the row. <literal>InnoDB</literal> does not remember the
+ exact <literal>WHERE</literal> condition, but only knows which
+ index ranges were scanned. The record locks are normally
+ next-key locks that also block inserts to the <quote>gap</quote>
+ immediately before the record.
</para>
<para>
@@ -4264,11 +4264,12 @@
</para>
<para>
- If you do not have indexes suitable for your query and MySQL has
- to scan the whole table to process the query, every row of the
- table becomes locked, which in turn blocks all inserts by other
- users to the table. It is important to create good indexes so
- that your queries do not unnecessarily need to scan many rows.
+ If you do not have indexes suitable for your statement and MySQL
+ has to scan the whole table to process the statement, every row
+ of the table becomes locked, which in turn blocks all inserts by
+ other users to the table. It is important to create good indexes
+ so that your queries do not unnecessarily need to scan many
+ rows.
</para>
<itemizedlist>
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-01-09 16:06:44 UTC (rev 740)
+++ trunk/refman-5.0/innodb.xml 2006-01-09 16:07:01 UTC (rev 741)
@@ -4192,14 +4192,14 @@
<para>
A locking read, an <literal>UPDATE</literal>, or a
<literal>DELETE</literal> generally set record locks on every
- index record that is scanned in the processing of the SQL query.
- It does not matter if there are <literal>WHERE</literal>
- conditions in the query that would exclude the row from the
- result set of the query. <literal>InnoDB</literal> does not
- remember the exact <literal>WHERE</literal> condition, but only
- knows which index ranges were scanned. The record locks are
- normally next-key locks that also block inserts to the
- <quote>gap</quote> immediately before the record.
+ index record that is scanned in the processing of the SQL
+ statement. It does not matter if there are
+ <literal>WHERE</literal> conditions in the statement that would
+ exclude the row. <literal>InnoDB</literal> does not remember the
+ exact <literal>WHERE</literal> condition, but only knows which
+ index ranges were scanned. The record locks are normally
+ next-key locks that also block inserts to the <quote>gap</quote>
+ immediately before the record.
</para>
<para>
@@ -4209,11 +4209,12 @@
</para>
<para>
- If you do not have indexes suitable for your query and MySQL has
- to scan the whole table to process the query, every row of the
- table becomes locked, which in turn blocks all inserts by other
- users to the table. It is important to create good indexes so
- that your queries do not unnecessarily need to scan many rows.
+ If you do not have indexes suitable for your statement and MySQL
+ has to scan the whole table to process the statement, every row
+ of the table becomes locked, which in turn blocks all inserts by
+ other users to the table. It is important to create good indexes
+ so that your queries do not unnecessarily need to scan many
+ rows.
</para>
<itemizedlist>
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2006-01-09 16:06:44 UTC (rev 740)
+++ trunk/refman-5.1/innodb.xml 2006-01-09 16:07:01 UTC (rev 741)
@@ -4168,14 +4168,14 @@
<para>
A locking read, an <literal>UPDATE</literal>, or a
<literal>DELETE</literal> generally set record locks on every
- index record that is scanned in the processing of the SQL query.
- It does not matter if there are <literal>WHERE</literal>
- conditions in the query that would exclude the row from the
- result set of the query. <literal>InnoDB</literal> does not
- remember the exact <literal>WHERE</literal> condition, but only
- knows which index ranges were scanned. The record locks are
- normally next-key locks that also block inserts to the
- <quote>gap</quote> immediately before the record.
+ index record that is scanned in the processing of the SQL
+ statement. It does not matter if there are
+ <literal>WHERE</literal> conditions in the statement that would
+ exclude the row. <literal>InnoDB</literal> does not remember the
+ exact <literal>WHERE</literal> condition, but only knows which
+ index ranges were scanned. The record locks are normally
+ next-key locks that also block inserts to the <quote>gap</quote>
+ immediately before the record.
</para>
<para>
@@ -4185,11 +4185,12 @@
</para>
<para>
- If you do not have indexes suitable for your query and MySQL has
- to scan the whole table to process the query, every row of the
- table becomes locked, which in turn blocks all inserts by other
- users to the table. It is important to create good indexes so
- that your queries do not unnecessarily need to scan many rows.
+ If you do not have indexes suitable for your statement and MySQL
+ has to scan the whole table to process the statement, every row
+ of the table becomes locked, which in turn blocks all inserts by
+ other users to the table. It is important to create good indexes
+ so that your queries do not unnecessarily need to scan many
+ rows.
</para>
<itemizedlist>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r741 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 9 Jan |
