Author: paul
Date: 2009-01-13 20:48:09 +0100 (Tue, 13 Jan 2009)
New Revision: 13146
Log:
r37264@frost: paul | 2009-01-13 13:47:46 -0500
Reformat
Modified:
trunk/dynamic-docs/changelog/connector-j.xml
trunk/dynamic-docs/changelog/mysqld-1.xml
trunk/dynamic-docs/changelog/mysqld.xml
trunk/refman-4.1/apis-c.xml
trunk/refman-4.1/dba-security-core.xml
trunk/refman-4.1/mysql-cluster-management.xml
trunk/refman-4.1/news-3.22.xml
trunk/refman-4.1/news-3.23.xml
trunk/refman-4.1/news-4.0.xml
trunk/refman-4.1/optimization.xml
trunk/refman-4.1/programs-admin-util.xml
trunk/refman-4.1/replication.xml
trunk/refman-4.1/sql-syntax-data-manipulation.xml
trunk/refman-4.1/storage-engines.xml
trunk/refman-5.0/apis-c.xml
trunk/refman-5.0/dba-security-core.xml
trunk/refman-5.0/mysql-cluster-management.xml
trunk/refman-5.0/optimization.xml
trunk/refman-5.0/programs-admin-util-core.xml
trunk/refman-5.0/replication-notes.xml
trunk/refman-5.0/se-merge.xml
trunk/refman-5.0/sql-syntax-data-manipulation.xml
trunk/refman-5.1/apis-c.xml
trunk/refman-5.1/dba-security-core.xml
trunk/refman-5.1/mysql-cluster-management.xml
trunk/refman-5.1/optimization.xml
trunk/refman-5.1/programs-admin-util-core.xml
trunk/refman-5.1/replication-notes.xml
trunk/refman-5.1/se-merge.xml
trunk/refman-5.1/sql-syntax-data-manipulation.xml
trunk/refman-6.0/apis-c.xml
trunk/refman-6.0/dba-security-core.xml
trunk/refman-6.0/optimization.xml
trunk/refman-6.0/programs-admin-util-core.xml
trunk/refman-6.0/replication-notes.xml
trunk/refman-6.0/se-merge.xml
trunk/refman-6.0/sql-syntax-data-manipulation.xml
trunk/refman-common/connector-j.xml
trunk/refman-common/connector-net.xml
trunk/refman-common/credits.xml
trunk/refman-common/news-cnet-core.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:41130
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:37263
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:35634
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:41130
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:37264
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:35634
Modified: trunk/dynamic-docs/changelog/connector-j.xml
===================================================================
--- trunk/dynamic-docs/changelog/connector-j.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/dynamic-docs/changelog/connector-j.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 7, Lines Added: 20, Lines Deleted: 12; 4121 bytes
@@ -1466,7 +1466,8 @@
<para>
<literal>setLocalInfileInputStream()</literal> sets an
<literal>InputStream</literal> instance that will be used to
- send data to the MySQL server for a <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ send data to the MySQL server for a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal> statement rather than a
<literal>FileInputStream</literal> or
<literal>URLInputStream</literal> that represents the path
@@ -1474,11 +1475,13 @@
</para>
<para>
This stream will be read to completion upon execution of a
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> statement, and
- will automatically be closed by the driver, so it needs to
- be reset before each call to <literal>execute*()</literal>
- that would cause the MySQL server to request data to fulfill
- the request for <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>.
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statement, and will automatically be closed
+ by the driver, so it needs to be reset before each call to
+ <literal>execute*()</literal> that would cause the MySQL
+ server to request data to fulfill the request for
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal>.
</para>
<para>
If this value is set to <literal>NULL</literal>, the driver
@@ -1491,7 +1494,8 @@
<para>
<literal>getLocalInfileInputStream()</literal> returns the
<literal>InputStream</literal> instance that will be used to
- send data in response to a <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ send data in response to a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal> statement.
</para>
<para>
@@ -2693,7 +2697,8 @@
<message>
<para>
- Use 1MB packet for sending file for <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ Use 1MB packet for sending file for
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal> if that is <
<literal role="sysvar">max_allowed_packet</literal> on server.
</para>
@@ -3985,7 +3990,8 @@
<para>
Fixed security exception when used in Applets (applets can't
read the system property <literal>file.encoding</literal> which
- is needed for <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>).
+ is needed for <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL INFILE</literal>).
</para>
</message>
@@ -7705,8 +7711,9 @@
<message>
<para>
- Fixed <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> bug when file
- > <literal role="sysvar">max_allowed_packet</literal>.
+ Fixed <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> bug when file >
+ <literal role="sysvar">max_allowed_packet</literal>.
</para>
</message>
@@ -13641,7 +13648,8 @@
<message>
<para>
- You can now use URLs in <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ You can now use URLs in
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal> statements, and the driver will use Java's
built-in handlers for retreiving the data and sending it to the
server. This feature is not enabled by default, you must set the
Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 9, Lines Added: 37, Lines Deleted: 34; 6359 bytes
@@ -10615,9 +10615,9 @@
<para>
It was possible to exhaust memory by repeatedly running
- <literal role="jointype">index_merge</literal> queries and never performing any
- <literal role="stmt" condition="flush">FLUSH TABLES</literal>
- statements.
+ <literal role="jointype">index_merge</literal> queries and never
+ performing any <literal role="stmt" condition="flush">FLUSH
+ TABLES</literal> statements.
</para>
</message>
@@ -12304,9 +12304,10 @@
<message>
<para>
- A query that performed a <literal role="jointype">ref_or_null</literal> join
- where the second table used a key having one or columns that
- could be <literal>NULL</literal> and had a column value that was
+ A query that performed a
+ <literal role="jointype">ref_or_null</literal> join where the
+ second table used a key having one or columns that could be
+ <literal>NULL</literal> and had a column value that was
<literal>NULL</literal> caused the server to crash.
</para>
@@ -12622,11 +12623,11 @@
<message ver="6.0.5">
<para>
- When the <literal role="jointype">range</literal> access method was used on a
- partitioned <literal>Falcon</literal> table, the entire index
- was scanned. For partitioned tables using other storage engines,
- a related issue caused an ordered range scan to return some rows
- twice.
+ When the <literal role="jointype">range</literal> access method
+ was used on a partitioned <literal>Falcon</literal> table, the
+ entire index was scanned. For partitioned tables using other
+ storage engines, a related issue caused an ordered range scan to
+ return some rows twice.
</para>
</message>
@@ -18228,11 +18229,11 @@
<message>
<para>
- Queries that used the <literal role="jointype">ref</literal> access method or
- index-based subquery execution over indexes that have
- <literal role="type">DECIMAL</literal> columns could fail with
- an error <literal>Column <replaceable>col_name</replaceable>
- cannot be null</literal>.
+ Queries that used the <literal role="jointype">ref</literal>
+ access method or index-based subquery execution over indexes
+ that have <literal role="type">DECIMAL</literal> columns could
+ fail with an error <literal>Column
+ <replaceable>col_name</replaceable> cannot be null</literal>.
</para>
</message>
@@ -21143,8 +21144,8 @@
The server crashed when executing a query that had a subquery
containing an equality X=Y where Y referred to a named select
list expression from the parent select. The server crashed when
- trying to use the X=Y equality for <literal role="jointype">ref</literal>-based
- access.
+ trying to use the X=Y equality for
+ <literal role="jointype">ref</literal>-based access.
</para>
</message>
@@ -23161,9 +23162,10 @@
faster scan. <literal role="stmt">EXPLAIN</literal> output now
indicates use of the clustered index (for tables that have one)
as lines with a <literal>type</literal> value of
- <literal role="jointype">index</literal>, a <literal>key</literal> value of
- <literal>PRIMARY</literal>, and without <literal>Using
- index</literal> in the <literal>Extra</literal> value.
+ <literal role="jointype">index</literal>, a
+ <literal>key</literal> value of <literal>PRIMARY</literal>, and
+ without <literal>Using index</literal> in the
+ <literal>Extra</literal> value.
</para>
</message>
@@ -26249,11 +26251,12 @@
<literal>libmysqlclient</literal> client library would respond
to a <literal>FETCH LOCAL FILE</literal> request from the server
even if the request is sent for statements from the client other
- than <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>. The client
- library has been modified to respond to a <literal>FETCH LOCAL
- FILE</literal> request from the server only if is is sent in
- response to a <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- statement from the client.
+ than <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal>. The client library has been modified to
+ respond to a <literal>FETCH LOCAL FILE</literal> request from
+ the server only if is is sent in response to a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statement from the client.
</para>
<para>
@@ -28354,12 +28357,12 @@
<para>
The server ignored any covering index used for
- <literal role="jointype">ref</literal> access of a table in a query with
- <literal>ORDER BY</literal> if this index was incompatible with
- the <literal>ORDER BY</literal> list and there was another
- covering index compatible with this list. As a result,
- suboptimal execution plans were chosen for some queries that
- used an <literal>ORDER BY</literal> clause.
+ <literal role="jointype">ref</literal> access of a table in a
+ query with <literal>ORDER BY</literal> if this index was
+ incompatible with the <literal>ORDER BY</literal> list and there
+ was another covering index compatible with this list. As a
+ result, suboptimal execution plans were chosen for some queries
+ that used an <literal>ORDER BY</literal> clause.
</para>
</message>
@@ -39940,8 +39943,8 @@
<para>
Queries executed using the batched-key access method could cause
an assertion fail when key expressions for a
- <literal role="jointype">ref</literal> access depended on columns not only from
- the previous join table.
+ <literal role="jointype">ref</literal> access depended on
+ columns not only from the previous join table.
</para>
</message>
Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/dynamic-docs/changelog/mysqld.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 27, Lines Added: 76, Lines Deleted: 61; 13105 bytes
@@ -11007,9 +11007,9 @@
<para>
The <literal role="func">CONVERT_TZ()</literal> function, when
- its second or third argument was from a <literal role="jointype">const</literal>
- table, caused the server to crash. (See
- <xref linkend="explain"/>.)
+ its second or third argument was from a
+ <literal role="jointype">const</literal> table, caused the
+ server to crash. (See <xref linkend="explain"/>.)
</para>
</message>
@@ -11162,7 +11162,8 @@
<para>
Indexes on <literal role="type">TEXT</literal> columns were
- ignored when <literal role="jointype">ref</literal> accesses were evaluated.
+ ignored when <literal role="jointype">ref</literal> accesses
+ were evaluated.
</para>
</message>
@@ -12886,8 +12887,8 @@
could cause a server crash if the <literal>FULLTEXT</literal>
index was not used in a join (that is,
<literal role="stmt">EXPLAIN</literal> did not show
- <literal role="jointype">fulltext</literal> join mode) and the search query
- matched no rows in the table.
+ <literal role="jointype">fulltext</literal> join mode) and the
+ search query matched no rows in the table.
</para>
</message>
@@ -23380,8 +23381,9 @@
<message>
<para>
- A query of type <literal role="jointype">index_merge</literal>, and with a
- <literal>WHERE</literal> clause having the form <literal>WHERE
+ A query of type <literal role="jointype">index_merge</literal>,
+ and with a <literal>WHERE</literal> clause having the form
+ <literal>WHERE
<replaceable>indexed_column_1</replaceable>=<replaceable>value_1</replaceable>
OR
<replaceable>indexed_column_2</replaceable>=<replaceable>value_2</replaceable>
@@ -23709,7 +23711,8 @@
<replaceable>col_name</replaceable> =
<replaceable>const</replaceable></literal>, even though the two
expressions are logically equivalent. Now the optimizer can use
- the <literal role="jointype">ref</literal> access method for both expressions.
+ the <literal role="jointype">ref</literal> access method for
+ both expressions.
</para>
</message>
@@ -24955,8 +24958,8 @@
<para>
In prepared statements, subqueries containing parameters were
- erroneously treated as <literal role="jointype">const</literal> tables during
- preparation, resulting in a server crash.
+ erroneously treated as <literal role="jointype">const</literal>
+ tables during preparation, resulting in a server crash.
</para>
</message>
@@ -33180,8 +33183,9 @@
<para>
For <literal>InnoDB</literal>, in some rare cases the optimizer
- preferred a more expensive <literal role="jointype">ref</literal> access to a
- less expensive range access.
+ preferred a more expensive
+ <literal role="jointype">ref</literal> access to a less
+ expensive range access.
</para>
</message>
@@ -34249,10 +34253,11 @@
<para>
<literal>InnoDB</literal>: Queries that were executed using an
- <literal role="jointype">index_merge</literal> union or intersection could
- produce incorrect results if the underlying table used the
- <literal>InnoDB</literal> storage engine and had a primary key
- containing <literal role="type">VARCHAR</literal> members.
+ <literal role="jointype">index_merge</literal> union or
+ intersection could produce incorrect results if the underlying
+ table used the <literal>InnoDB</literal> storage engine and had
+ a primary key containing <literal role="type">VARCHAR</literal>
+ members.
</para>
</message>
@@ -40718,8 +40723,8 @@
<para>
The optimizer used a filesort rather than a
- <literal role="jointype">const</literal> table read in some cases when the
- latter was possible.
+ <literal role="jointype">const</literal> table read in some
+ cases when the latter was possible.
</para>
</message>
@@ -45204,9 +45209,10 @@
<para>
The optimizer sometimes produced an incorrect row-count estimate
- after elimination of <literal role="jointype">const</literal> tables. This
- resulted in choosing extremely inefficient execution plans in
- same cases when distribution of data in joins were skewed.
+ after elimination of <literal role="jointype">const</literal>
+ tables. This resulted in choosing extremely inefficient
+ execution plans in same cases when distribution of data in joins
+ were skewed.
</para>
</message>
@@ -51420,8 +51426,9 @@
<message>
<para>
- The optimizer used the <literal role="jointype">ref</literal> join type rather
- than <literal role="jointype">eq_ref</literal> for a simple join on strings.
+ The optimizer used the <literal role="jointype">ref</literal>
+ join type rather than <literal role="jointype">eq_ref</literal>
+ for a simple join on strings.
</para>
</message>
@@ -53923,8 +53930,8 @@
<para>
The range analysis optimizer did not take into account
predicates for which an index could be used after reading
- <literal role="jointype">const</literal> tables. In some cases this resulted in
- non-optimal execution plans.
+ <literal role="jointype">const</literal> tables. In some cases
+ this resulted in non-optimal execution plans.
</para>
</message>
@@ -54443,8 +54450,8 @@
<para>
Queries on <literal role="se">NDB</literal> tables that were
- executed using <literal role="jointype">index_merge</literal> could produce
- incorrect results.
+ executed using <literal role="jointype">index_merge</literal>
+ could produce incorrect results.
</para>
</message>
@@ -61574,7 +61581,8 @@
<para>
<literal>ROLLUP</literal> did not work correctly when all tables
- in the join were <literal role="jointype">const</literal> tables.
+ in the join were <literal role="jointype">const</literal>
+ tables.
</para>
</message>
@@ -62612,8 +62620,8 @@
<message>
<para>
- Non-optimal <literal role="jointype">index_merge</literal> query execution plans
- were chosen on IRIX.
+ Non-optimal <literal role="jointype">index_merge</literal> query
+ execution plans were chosen on IRIX.
</para>
</message>
@@ -77778,8 +77786,9 @@
<message>
<para>
- Use of yaSSL for a secure client connection caused <literal role="stmt" condition="load-data">LOAD
- DATA LOCAL INFILE</literal> to fail.
+ Use of yaSSL for a secure client connection caused
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> to fail.
</para>
</message>
@@ -77889,10 +77898,10 @@
<message>
<para>
- The <literal role="jointype">ref</literal> optimizer could choose the
- <literal role="jointype">ref_or_null</literal> access method in cases where it
- was not applicable. This could cause inconsistent
- <literal role="stmt">EXPLAIN</literal> or
+ The <literal role="jointype">ref</literal> optimizer could
+ choose the <literal role="jointype">ref_or_null</literal> access
+ method in cases where it was not applicable. This could cause
+ inconsistent <literal role="stmt">EXPLAIN</literal> or
<literal role="stmt">SELECT</literal> results for a given
statement.
</para>
@@ -81988,8 +81997,8 @@
<literal>FULLTEXT</literal> index to retrieve rows and there was
another index that was usable for <literal>ORDER BY</literal>.
For such a query, <literal role="stmt">EXPLAIN</literal> showed
- the <literal role="jointype">fulltext</literal> join type, but showed the other
- (not <literal>FULLTEXT</literal>) index in the
+ the <literal role="jointype">fulltext</literal> join type, but
+ showed the other (not <literal>FULLTEXT</literal>) index in the
<literal>Key</literal> column.
</para>
@@ -88785,8 +88794,8 @@
<para>
For a <literal>MyISAM</literal> table locked with <literal>LOCK
TABLES ...WRITE</literal>, queries optimized using the
- <literal role="jointype">index_merge</literal> method did not show rows inserted
- with the lock in place.
+ <literal role="jointype">index_merge</literal> method did not
+ show rows inserted with the lock in place.
</para>
</message>
@@ -92006,10 +92015,10 @@
=
<replaceable>tableY</replaceable>.<replaceable>key</replaceable>
</literal>, which participated in equality propagation and also
- was used for <literal role="jointype">ref</literal> access, then early
- <literal role="jointype">ref</literal>-access <literal>NULL</literal> filtering
- was not performed for the condition. This could make query
- execution slower.
+ was used for <literal role="jointype">ref</literal> access, then
+ early <literal role="jointype">ref</literal>-access
+ <literal>NULL</literal> filtering was not performed for the
+ condition. This could make query execution slower.
</para>
</message>
@@ -99367,8 +99376,9 @@
<para>
Queries with subqueries, where the inner subquery uses the
- <literal role="jointype">range</literal> or <literal role="jointype">index_merge</literal>
- access method, could return incorrect results.
+ <literal role="jointype">range</literal> or
+ <literal role="jointype">index_merge</literal> access method,
+ could return incorrect results.
</para>
</message>
@@ -103449,7 +103459,8 @@
<message>
<para>
- Queries that used the <literal role="jointype">index_merge</literal> and
+ Queries that used the
+ <literal role="jointype">index_merge</literal> and
<literal>sort_union</literal> methods to access an
<literal>InnoDB</literal> table could produce inaccurate
results. This issue was introduced in MySQL 5.1.10 when a new
@@ -110024,8 +110035,9 @@
<message>
<para>
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> failed to ignore duplicate
- keys in Cluster tables.
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> failed to ignore duplicate keys in Cluster
+ tables.
</para>
</message>
@@ -119229,8 +119241,9 @@
<para>
Added an optimization that avoids key access with
- <literal>NULL</literal> keys for the <literal role="jointype">ref</literal>
- method when used in outer joins.
+ <literal>NULL</literal> keys for the
+ <literal role="jointype">ref</literal> method when used in outer
+ joins.
</para>
</message>
@@ -123601,8 +123614,8 @@
<para>
For <literal>MEMORY</literal> tables, the
- <literal role="jointype">index_merge</literal> union access method could return
- incorrect results.
+ <literal role="jointype">index_merge</literal> union access
+ method could return incorrect results.
</para>
</message>
@@ -123915,7 +123928,9 @@
<para>
<literal role="cfunc">mysql_options(...,MYSQL_OPT_LOCAL_INFILE,...)</literal>
- failed to disable <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>.
+ failed to disable
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal>.
</para>
</message>
@@ -139164,12 +139179,12 @@
Threads that were calculating the estimated number of records
for a range scan did not respond to the
<literal role="stmt">KILL</literal> statement. That is, if a
- <literal role="jointype">range</literal> join type is possible (even if not
- selected by the optimizer as a join type of choice and thus not
- shown by <literal role="stmt">EXPLAIN</literal>), the query in
- the <literal>statistics</literal> state (shown by the
- <literal role="stmt">SHOW PROCESSLIST</literal>) did not respond
- to the <literal role="stmt">KILL</literal> statement.
+ <literal role="jointype">range</literal> join type is possible
+ (even if not selected by the optimizer as a join type of choice
+ and thus not shown by <literal role="stmt">EXPLAIN</literal>),
+ the query in the <literal>statistics</literal> state (shown by
+ the <literal role="stmt">SHOW PROCESSLIST</literal>) did not
+ respond to the <literal role="stmt">KILL</literal> statement.
</para>
</message>
Modified: trunk/refman-4.1/apis-c.xml
===================================================================
--- trunk/refman-4.1/apis-c.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/apis-c.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 6, Lines Added: 24, Lines Deleted: 18; 4806 bytes
@@ -1123,13 +1123,14 @@
</row>
<row>
<entry><literal role="cfunc">mysql_set_local_infile_default()</literal></entry>
- <entry>Set the <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> handler callbacks to
- their default values</entry>
+ <entry>Set the <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> handler callbacks to their default values</entry>
</row>
<row>
<entry><literal role="cfunc">mysql_set_local_infile_handler()</literal></entry>
- <entry>Install application-specific <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- handler callbacks</entry>
+ <entry>Install application-specific
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> handler callbacks</entry>
</row>
<row>
<entry><literal role="cfunc">mysql_set_server_option()</literal></entry>
@@ -5533,7 +5534,8 @@
</row>
<row>
<entry><literal>disable-local-infile</literal></entry>
- <entry>Disable use of <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal>.</entry>
+ <entry>Disable use of <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal>.</entry>
</row>
<row>
<entry><literal>host=<replaceable>host_name</replaceable></literal></entry>
@@ -5552,7 +5554,8 @@
</row>
<row>
<entry><literal>local-infile[={0|1}]</literal></entry>
- <entry>If no argument or non-zero argument, enable use of <literal role="stmt" condition="load-data">LOAD DATA
+ <entry>If no argument or non-zero argument, enable use of
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal>; otherwise disable.</entry>
</row>
<row>
@@ -6080,7 +6083,8 @@
</row>
<row>
<entry><literal>CLIENT_LOCAL_FILES</literal></entry>
- <entry>Enable <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> handling.</entry>
+ <entry>Enable <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> handling.</entry>
</row>
<row>
<entry><literal>CLIENT_MULTI_RESULTS</literal></entry>
@@ -7260,12 +7264,12 @@
<para>
This function installs callbacks to be used during the execution
- of <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> statements. It
- enables application programs to exert control over local
- (client-side) data file reading. The arguments are the
- connection handler, a set of pointers to callback functions, and
- a pointer to a data area that the callbacks can use to share
- information.
+ of <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statements. It enables application programs to
+ exert control over local (client-side) data file reading. The
+ arguments are the connection handler, a set of pointers to
+ callback functions, and a pointer to a data area that the
+ callbacks can use to share information.
</para>
<para>
@@ -7364,13 +7368,15 @@
After calling
<literal role="cfunc">mysql_set_local_infile_handler()</literal>
in your C code and passing pointers to your callback functions,
- you can then issue a <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- statement (for example, by using
+ you can then issue a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statement (for example, by using
<literal role="cfunc">mysql_query()</literal>). The client
library automatically invokes your callbacks. The filename
- specified in <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> will be
- passed as the second parameter to the
- <literal>local_infile_init()</literal> callback.
+ specified in <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL INFILE</literal> will be passed as the second
+ parameter to the <literal>local_infile_init()</literal>
+ callback.
</para>
<para>
Modified: trunk/refman-4.1/dba-security-core.xml
===================================================================
--- trunk/refman-4.1/dba-security-core.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/dba-security-core.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 7, Lines Added: 32, Lines Deleted: 25; 5533 bytes
@@ -928,7 +928,8 @@
<section id="load-data-local">
- <title>Security Issues with <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal></title>
+ <title>Security Issues with <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL</literal></title>
<para>
The <literal role="stmt">LOAD DATA</literal> statement can load a
@@ -960,7 +961,8 @@
<listitem>
<para>
In a Web environment where the clients are connecting from a
- Web server, a user could use <literal role="stmt" condition="load-data">LOAD DATA
+ Web server, a user could use
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> to read any files that the Web server process
has read access to (assuming that a user could run any command
against the SQL server). In this environment, the client with
@@ -973,7 +975,8 @@
</itemizedlist>
<para>
- To deal with these problems, we changed how <literal role="stmt" condition="load-data">LOAD DATA
+ To deal with these problems, we changed how
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> is handled as of MySQL 3.23.49 and MySQL 4.0.2
(4.0.13 on Windows):
</para>
@@ -993,8 +996,9 @@
<para>
If you build MySQL from source but do not invoke
<command>configure</command> with the
- <option>--enable-local-infile</option> option, <literal role="stmt" condition="load-data">LOAD
- DATA LOCAL</literal> cannot be used by any client unless it is
+ <option>--enable-local-infile</option> option,
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> cannot be used by any client unless it is
written explicitly to invoke
<literal role="cfunc">mysql_options(...
MYSQL_OPT_LOCAL_INFILE, 0)</literal>. See
@@ -1004,8 +1008,9 @@
<listitem>
<para>
- You can disable all <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal>
- commands from the server side by starting
+ You can disable all
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> commands from the server side by starting
<command>mysqld</command> with the
<option>--local-infile=0</option> option.
</para>
@@ -1014,26 +1019,27 @@
<listitem>
<para>
For the <command>mysql</command> command-line client,
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> can be enabled by
- specifying the <option>--local-infile[=1]</option> option, or
- disabled with the <option>--local-infile=0</option> option.
- Similarly, for <command>mysqlimport</command>, the
- <option>--local</option> or <option>-L</option> option enables
- local data file loading. In any case, successful use of a
- local loading operation requires that the server is enabled to
- allow it.
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> can be enabled by specifying the
+ <option>--local-infile[=1]</option> option, or disabled with
+ the <option>--local-infile=0</option> option. Similarly, for
+ <command>mysqlimport</command>, the <option>--local</option>
+ or <option>-L</option> option enables local data file loading.
+ In any case, successful use of a local loading operation
+ requires that the server is enabled to allow it.
</para>
</listitem>
<listitem>
<para>
- If you use <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> in Perl scripts
- or other programs that read the <literal>[client]</literal>
- group from option files, you can add the
- <literal>local-infile=1</literal> option to that group.
- However, to keep this from causing problems for programs that
- do not understand <literal>local-infile</literal>, specify it
- using the <literal>loose-</literal> prefix:
+ If you use <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL</literal> in Perl scripts or other programs that
+ read the <literal>[client]</literal> group from option files,
+ you can add the <literal>local-infile=1</literal> option to
+ that group. However, to keep this from causing problems for
+ programs that do not understand
+ <literal>local-infile</literal>, specify it using the
+ <literal>loose-</literal> prefix:
</para>
<programlisting>
@@ -1049,9 +1055,10 @@
<listitem>
<para>
- If <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> is disabled,
- either in the server or the client, a client that attempts to
- issue such a statement receives the following error message:
+ If <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> is disabled, either in the server or the
+ client, a client that attempts to issue such a statement
+ receives the following error message:
</para>
<programlisting>
Modified: trunk/refman-4.1/mysql-cluster-management.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster-management.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/mysql-cluster-management.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 3, Lines Deleted: 2; 882 bytes
@@ -4671,8 +4671,9 @@
<xref linkend="mysql-cluster-start-phases"/>.
(<replaceable>type</replaceable> is one of
<literal>initial</literal>,
- <literal role="jointype">system</literal>, <literal>node</literal>,
- <literal>initial node</literal>, or
+ <literal role="jointype">system</literal>,
+ <literal>node</literal>, <literal>initial
+ node</literal>, or
<literal><Unknown></literal>.)
</para>
Modified: trunk/refman-4.1/news-3.22.xml
===================================================================
--- trunk/refman-4.1/news-3.22.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/news-3.22.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 6; 1436 bytes
@@ -950,8 +950,9 @@
<listitem>
<para>
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> didn't work in the
- Unix version because of a missing file.
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> didn't work in the Unix version because of a
+ missing file.
</para>
</listitem>
@@ -1616,7 +1617,8 @@
<listitem>
<para>
Fix problem with <literal>ORDER BY</literal> and <literal>LEFT
- JOIN</literal> and <literal role="jointype">const</literal> tables.
+ JOIN</literal> and <literal role="jointype">const</literal>
+ tables.
</para>
</listitem>
@@ -2200,9 +2202,9 @@
<listitem>
<para>
- Added optimization to remove <literal role="jointype">const</literal>
- reference tables from <literal>ORDER BY</literal> and
- <literal>GROUP BY</literal>.
+ Added optimization to remove
+ <literal role="jointype">const</literal> reference tables from
+ <literal>ORDER BY</literal> and <literal>GROUP BY</literal>.
</para>
</listitem>
Modified: trunk/refman-4.1/news-3.23.xml
===================================================================
--- trunk/refman-4.1/news-3.23.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/news-3.23.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 3, Lines Added: 6, Lines Deleted: 5; 1371 bytes
@@ -1676,7 +1676,8 @@
<listitem>
<para>
- Added options to make <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ Added options to make
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal> more secure.
</para>
</listitem>
@@ -1722,8 +1723,8 @@
<listitem>
<para>
- Fixed bug in complicated join with <literal role="jointype">const</literal>
- tables.
+ Fixed bug in complicated join with
+ <literal role="jointype">const</literal> tables.
</para>
</listitem>
@@ -8348,8 +8349,8 @@
<replaceable>key_part1</replaceable>=<replaceable>const4</replaceable>
AND
<replaceable>key_part2</replaceable>=<replaceable>const4</replaceable></literal>;
- indextype should be <literal role="jointype">range</literal> instead of
- <literal role="jointype">ref</literal>.
+ indextype should be <literal role="jointype">range</literal>
+ instead of <literal role="jointype">ref</literal>.
</para>
</listitem>
Modified: trunk/refman-4.1/news-4.0.xml
===================================================================
--- trunk/refman-4.1/news-4.0.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/news-4.0.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 6, Lines Added: 16, Lines Deleted: 14; 3360 bytes
@@ -1096,8 +1096,8 @@
language mode that could cause a server crash if the
<literal>FULLTEXT</literal> index was not used in a join
(<literal role="stmt">EXPLAIN</literal> did not show
- <literal role="jointype">fulltext</literal> join mode) and the search query
- matched no rows in the table (Bug #8522).
+ <literal role="jointype">fulltext</literal> join mode) and the
+ search query matched no rows in the table (Bug #8522).
</para>
</listitem>
@@ -3697,8 +3697,8 @@
<listitem>
<para>
Fixed an incorrect result from a query that uses only
- <literal role="jointype">const</literal> tables (such as one-row tables) and
- non-constant expression (such as
+ <literal role="jointype">const</literal> tables (such as
+ one-row tables) and non-constant expression (such as
<literal role="func">RAND()</literal>). (Bug #1271)
</para>
</listitem>
@@ -4797,8 +4797,9 @@
<literal role="stmt" condition="load-data">LOAD DATA
INFILE</literal> (this command is displayed only for
information, not to be run; it is later reworked to
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> with a different filename,
- for execution by <command>mysql</command>). (Bug #1096)
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> with a different filename, for execution by
+ <command>mysql</command>). (Bug #1096)
</para>
</listitem>
@@ -6284,9 +6285,9 @@
<listitem>
<para>
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> was not properly
- written to the binary log (hence not properly replicated).
- (Bug #82)
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> was not properly written to the binary log
+ (hence not properly replicated). (Bug #82)
</para>
</listitem>
@@ -6781,7 +6782,8 @@
Fixed bug in <literal>LEFT JOIN</literal> that caused zero
rows to be returned in the case the <literal>WHERE</literal>
condition was evaluated as <literal>FALSE</literal> after
- reading <literal role="jointype">const</literal> tables. (Unlikely condition).
+ reading <literal role="jointype">const</literal> tables.
+ (Unlikely condition).
</para>
</listitem>
@@ -9127,10 +9129,10 @@
<listitem>
<para>
- Fixed bug in complicated join with <literal role="jointype">const</literal>
- tables. This fix also improves performance a bit when
- referring to another table from a <literal role="jointype">const</literal>
- table.
+ Fixed bug in complicated join with
+ <literal role="jointype">const</literal> tables. This fix also
+ improves performance a bit when referring to another table
+ from a <literal role="jointype">const</literal> table.
</para>
</listitem>
Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/optimization.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 25, Lines Added: 110, Lines Deleted: 89; 18887 bytes
@@ -923,7 +923,8 @@
<para>
The table has only one row (= system table). This is a
- special case of the <literal role="jointype">const</literal> join type.
+ special case of the
+ <literal role="jointype">const</literal> join type.
</para>
</listitem>
@@ -952,15 +953,15 @@
the start of the query. Because there is only one row,
values from the column in this row can be regarded as
constants by the rest of the optimizer.
- <literal role="jointype">const</literal> tables are very fast because
- they are read only once.
+ <literal role="jointype">const</literal> tables are very
+ fast because they are read only once.
</para>
<para>
- <literal role="jointype">const</literal> is used when you compare all
- parts of a <literal>PRIMARY KEY</literal> or
- <literal>UNIQUE</literal> index to constant values. In
- the following queries,
+ <literal role="jointype">const</literal> is used when
+ you compare all parts of a <literal>PRIMARY
+ KEY</literal> or <literal>UNIQUE</literal> index to
+ constant values. In the following queries,
<replaceable>tbl_name</replaceable> can be used as a
<literal role="jointype">const</literal> table:
</para>
@@ -991,21 +992,23 @@
<para>
One row is read from this table for each combination of
rows from the previous tables. Other than the
- <literal role="jointype">system</literal> and <literal role="jointype">const</literal>
- types, this is the best possible join type. It is used
- when all parts of an index are used by the join and the
- index is a <literal>PRIMARY KEY</literal> or
+ <literal role="jointype">system</literal> and
+ <literal role="jointype">const</literal> types, this is
+ the best possible join type. It is used when all parts
+ of an index are used by the join and the index is a
+ <literal>PRIMARY KEY</literal> or
<literal>UNIQUE</literal> index.
</para>
<para>
- <literal role="jointype">eq_ref</literal> can be used for indexed
- columns that are compared using the <literal>=</literal>
- operator. The comparison value can be a constant or an
- expression that uses columns from tables that are read
- before this table. In the following examples, MySQL can
- use an <literal role="jointype">eq_ref</literal> join to process
- <replaceable>ref_table</replaceable>:
+ <literal role="jointype">eq_ref</literal> can be used
+ for indexed columns that are compared using the
+ <literal>=</literal> operator. The comparison value can
+ be a constant or an expression that uses columns from
+ tables that are read before this table. In the following
+ examples, MySQL can use an
+ <literal role="jointype">eq_ref</literal> join to
+ process <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1036,9 +1039,9 @@
<para>
All rows with matching index values are read from this
table for each combination of rows from the previous
- tables. <literal role="jointype">ref</literal> is used if the join uses
- only a leftmost prefix of the key or if the key is not a
- <literal>PRIMARY KEY</literal> or
+ tables. <literal role="jointype">ref</literal> is used
+ if the join uses only a leftmost prefix of the key or if
+ the key is not a <literal>PRIMARY KEY</literal> or
<literal>UNIQUE</literal> index (in other words, if the
join cannot select a single row based on the key value).
If the key that is used matches only a few rows, this is
@@ -1050,11 +1053,12 @@
</remark>
<para>
- <literal role="jointype">ref</literal> can be used for indexed columns
- that are compared using the <literal>=</literal> or
- <literal><=></literal> operator. In the following
- examples, MySQL can use a <literal role="jointype">ref</literal> join to
- process <replaceable>ref_table</replaceable>:
+ <literal role="jointype">ref</literal> can be used for
+ indexed columns that are compared using the
+ <literal>=</literal> or <literal><=></literal>
+ operator. In the following examples, MySQL can use a
+ <literal role="jointype">ref</literal> join to process
+ <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1106,13 +1110,15 @@
</para>
<para>
- This join type is like <literal role="jointype">ref</literal>, but with
- the addition that MySQL does an extra search for rows
- that contain <literal>NULL</literal> values. This join
- type optimization was added for MySQL 4.1.1 and is used
+ This join type is like
+ <literal role="jointype">ref</literal>, but with the
+ addition that MySQL does an extra search for rows that
+ contain <literal>NULL</literal> values. This join type
+ optimization was added for MySQL 4.1.1 and is used
mostly when resolving subqueries. In the following
- examples, MySQL can use a <literal role="jointype">ref_or_null</literal>
- join to process <replaceable>ref_table</replaceable>:
+ examples, MySQL can use a
+ <literal role="jointype">ref_or_null</literal> join to
+ process <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1141,7 +1147,8 @@
</para>
<para>
- This type replaces <literal role="jointype">ref</literal> for some
+ This type replaces
+ <literal role="jointype">ref</literal> for some
<literal>IN</literal> subqueries of the following form:
</para>
@@ -1150,9 +1157,9 @@
</programlisting>
<para>
- <literal role="jointype">unique_subquery</literal> is just an index
- lookup function that replaces the subquery completely
- for better efficiency.
+ <literal role="jointype">unique_subquery</literal> is
+ just an index lookup function that replaces the subquery
+ completely for better efficiency.
</para>
</listitem>
@@ -1173,9 +1180,10 @@
<para>
This join type is similar to
- <literal role="jointype">unique_subquery</literal>. It replaces
- <literal>IN</literal> subqueries, but it works for
- non-unique indexes in subqueries of the following form:
+ <literal role="jointype">unique_subquery</literal>. It
+ replaces <literal>IN</literal> subqueries, but it works
+ for non-unique indexes in subqueries of the following
+ form:
</para>
<programlisting>
@@ -1203,14 +1211,15 @@
an index to select the rows. The <literal>key</literal>
column in the output row indicates which index is used.
The <literal>key_len</literal> contains the longest key
- part that was used. The <literal role="jointype">ref</literal> column is
+ part that was used. The
+ <literal role="jointype">ref</literal> column is
<literal>NULL</literal> for this type.
</para>
<para>
- <literal role="jointype">range</literal> can be used when a key column
- is compared to a constant using any of the
- <literal role="op" condition="equal">=</literal>,
+ <literal role="jointype">range</literal> can be used
+ when a key column is compared to a constant using any of
+ the <literal role="op" condition="equal">=</literal>,
<literal role="op" condition="not-equal"><></literal>,
<literal role="op" condition="greater-than">></literal>,
<literal role="op" condition="greater-than-or-equal">>=</literal>,
@@ -1253,10 +1262,11 @@
</para>
<para>
- This join type is the same as <literal role="jointype_all">ALL</literal>,
- except that only the index tree is scanned. This usually
- is faster than <literal role="jointype_all">ALL</literal> because the index
- file usually is smaller than the data file.
+ This join type is the same as
+ <literal role="jointype_all">ALL</literal>, except that
+ only the index tree is scanned. This usually is faster
+ than <literal role="jointype_all">ALL</literal> because
+ the index file usually is smaller than the data file.
</para>
<para>
@@ -1286,7 +1296,8 @@
the table is the first table not marked
<literal role="jointype">const</literal>, and usually
<emphasis>very</emphasis> bad in all other cases.
- Normally, you can avoid <literal role="jointype_all">ALL</literal> by adding
+ Normally, you can avoid
+ <literal role="jointype_all">ALL</literal> by adding
indexes that allow row retrieval from the table based on
constant values or column values from earlier tables.
</para>
@@ -1401,9 +1412,10 @@
</para>
<para>
- The <literal role="jointype">ref</literal> column shows which columns or
- constants are compared to the index named in the
- <literal>key</literal> column to select rows from the table.
+ The <literal role="jointype">ref</literal> column shows
+ which columns or constants are compared to the index named
+ in the <literal>key</literal> column to select rows from the
+ table.
</para>
</listitem>
@@ -1453,9 +1465,11 @@
</para>
<para>
- MySQL has read all <literal role="jointype">const</literal> (and
- <literal role="jointype">system</literal>) tables and notice that the
- <literal>WHERE</literal> clause is always false.
+ MySQL has read all
+ <literal role="jointype">const</literal> (and
+ <literal role="jointype">system</literal>) tables and
+ notice that the <literal>WHERE</literal> clause is
+ always false.
</para>
</listitem>
@@ -1518,11 +1532,12 @@
indexes might be used after column values from preceding
tables are known. For each row combination in the
preceding tables, MySQL checks whether it is possible to
- use a <literal role="jointype">range</literal> access method to retrieve
- rows. The applicability criteria are as described in
- <xref linkend="range-optimization"/>, with the exception
- that all column values for the preceding table are known
- and considered to be constants.
+ use a <literal role="jointype">range</literal> access
+ method to retrieve rows. The applicability criteria are
+ as described in <xref linkend="range-optimization"/>,
+ with the exception that all column values for the
+ preceding table are known and considered to be
+ constants.
</para>
<para>
@@ -1633,7 +1648,8 @@
examine all rows from the table, you may have something
wrong in your query if the <literal>Extra</literal>
value is not <literal>Using where</literal> and the
- table join type is <literal role="jointype_all">ALL</literal> or
+ table join type is
+ <literal role="jointype_all">ALL</literal> or
<literal role="jointype">index</literal>.
</para>
</listitem>
@@ -1800,14 +1816,15 @@
</programlisting>
<para>
- Because <literal>type</literal> is <literal role="jointype_all">ALL</literal> for
- each table, this output indicates that MySQL is generating a
- Cartesian product of all the tables; that is, every combination
- of rows. This takes quite a long time, because the product of
- the number of rows in each table must be examined. For the case
- at hand, this product is 74 × 2135 × 74 × 3872
- = 45,268,558,720 rows. If the tables were bigger, you can only
- imagine how long it would take.
+ Because <literal>type</literal> is
+ <literal role="jointype_all">ALL</literal> for each table, this
+ output indicates that MySQL is generating a Cartesian product of
+ all the tables; that is, every combination of rows. This takes
+ quite a long time, because the product of the number of rows in
+ each table must be examined. For the case at hand, this product
+ is 74 × 2135 × 74 × 3872 = 45,268,558,720
+ rows. If the tables were bigger, you can only imagine how long
+ it would take.
</para>
<para>
@@ -2373,12 +2390,12 @@
<title>Range Optimization</title>
<para>
- The <literal role="jointype">range</literal> access method uses a single index
- to retrieve a subset of table rows that are contained within one
- or several index value intervals. It can be used for a
- single-part or multiple-part index. The following sections give
- a detailed description of how intervals are extracted from the
- <literal>WHERE</literal> clause.
+ The <literal role="jointype">range</literal> access method uses
+ a single index to retrieve a subset of table rows that are
+ contained within one or several index value intervals. It can be
+ used for a single-part or multiple-part index. The following
+ sections give a detailed description of how intervals are
+ extracted from the <literal>WHERE</literal> clause.
</para>
<section id="range-access-single-part">
@@ -2458,7 +2475,8 @@
<listitem>
<para>
A column of a <literal role="jointype">const</literal> or
- <literal role="jointype">system</literal> table from the same join
+ <literal role="jointype">system</literal> table from the
+ same join
</para>
</listitem>
@@ -2922,7 +2940,8 @@
<replaceable>col_name</replaceable> IS NULL</literal>, a form
that is common in resolved subqueries.
<literal role="stmt">EXPLAIN</literal> shows
- <literal role="jointype">ref_or_null</literal> when this optimization is used.
+ <literal role="jointype">ref_or_null</literal> when this
+ optimization is used.
</para>
<para>
@@ -2953,9 +2972,9 @@
</programlisting>
<para>
- <literal role="jointype">ref_or_null</literal> works by first doing a read on
- the reference key, and then a separate search for rows with a
- <literal>NULL</literal> key value.
+ <literal role="jointype">ref_or_null</literal> works by first
+ doing a read on the reference key, and then a separate search
+ for rows with a <literal>NULL</literal> key value.
</para>
<para>
@@ -3905,9 +3924,10 @@
<para>
The output from <literal role="stmt">EXPLAIN</literal> shows
- <literal role="jointype_all">ALL</literal> in the <literal>type</literal> column
- when MySQL uses a table scan to resolve a query. This usually
- happens under the following conditions:
+ <literal role="jointype_all">ALL</literal> in the
+ <literal>type</literal> column when MySQL uses a table scan to
+ resolve a query. This usually happens under the following
+ conditions:
</para>
<itemizedlist>
@@ -7326,9 +7346,9 @@
<replaceable>expr2</replaceable></literal> is not true when
<replaceable>expr1</replaceable> or
<replaceable>expr2</replaceable> (or both) are
- <literal>NULL</literal>. This affects <literal role="jointype">ref</literal>
- accesses for comparisons of the form
- <literal><replaceable>tbl_name.key</replaceable> =
+ <literal>NULL</literal>. This affects
+ <literal role="jointype">ref</literal> accesses for comparisons
+ of the form <literal><replaceable>tbl_name.key</replaceable> =
<replaceable>expr</replaceable></literal>: MySQL will not access
the table if the current value of
<replaceable>expr</replaceable> is <literal>NULL</literal>,
@@ -7370,8 +7390,9 @@
useful than it really is for joins that look for
non-<literal>NULL</literal> values. Consequently, the
<literal>nulls_equal</literal> method may cause the
- optimizer not to use the index for <literal role="jointype">ref</literal>
- accesses when it should.
+ optimizer not to use the index for
+ <literal role="jointype">ref</literal> accesses when it
+ should.
</para>
</listitem>
@@ -7393,8 +7414,8 @@
index for joins that look for non-<literal>NULL</literal>
values. Consequently, the <literal>nulls_unequal</literal>
method may cause the optimizer to use this index for
- <literal role="jointype">ref</literal> lookups when other methods may be
- better.
+ <literal role="jointype">ref</literal> lookups when other
+ methods may be better.
</para>
</listitem>
Modified: trunk/refman-4.1/programs-admin-util.xml
===================================================================
--- trunk/refman-4.1/programs-admin-util.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/programs-admin-util.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 2, Lines Added: 9, Lines Deleted: 6; 2147 bytes
@@ -4432,17 +4432,19 @@
reproduces the <literal role="stmt" condition="load-data">LOAD
DATA INFILE</literal> operation without the original data file.
<command>mysqlbinlog</command> copies the data to a temporary
- file and writes a <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- statement that refers to the file. The default location of the
- directory where these files are written is system-specific. To
- specify a directory explicitly, use the
+ file and writes a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statement that refers to the file. The default
+ location of the directory where these files are written is
+ system-specific. To specify a directory explicitly, use the
<option>--local-load</option> option.
</para>
<para>
Because <command>mysqlbinlog</command> converts
<literal role="stmt" condition="load-data">LOAD DATA
- INFILE</literal> statements to <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statements to
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal> statements (that is, it adds
<literal>LOCAL</literal>), both the client and the server that
you use to process the statements must be configured to allow
@@ -4465,7 +4467,8 @@
<warning>
<para>
- The temporary files created for <literal role="stmt" condition="load-data">LOAD DATA
+ The temporary files created for
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> statements are <emphasis>not</emphasis>
automatically deleted because they are needed until you
actually execute those statements. You should delete the
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/replication.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 2, Lines Added: 5, Lines Deleted: 3; 1171 bytes
@@ -1941,7 +1941,8 @@
is, <literal>LOAD DATA CONCURRENT INFILE</literal> is
replicated as <literal role="stmt" condition="load-data">LOAD
DATA INFILE</literal>, and <literal>LOAD DATA CONCURRENT LOCAL
- INFILE</literal> is replicated as <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> is replicated as
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal>. (Bug #34628)
</para>
</listitem>
@@ -2299,8 +2300,9 @@
<listitem>
<para>
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> is no longer skipped
- on the slave as it was in 3.23.
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> is no longer skipped on the slave as it was
+ in 3.23.
</para>
</listitem>
Modified: trunk/refman-4.1/sql-syntax-data-manipulation.xml
===================================================================
--- trunk/refman-4.1/sql-syntax-data-manipulation.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/sql-syntax-data-manipulation.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 4, Lines Added: 18, Lines Deleted: 14; 3384 bytes
@@ -2171,7 +2171,8 @@
<para>
If you are using a version of MySQL older than 3.23.25, you can
- use this technique only with <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ use this technique only with
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal>.
</para>
@@ -2184,7 +2185,8 @@
from a FIFO with <literal role="stmt" condition="load-data">LOAD
DATA INFILE</literal>. If you need to read from a FIFO (for
example, the output from <literal>gunzip</literal>), use
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> instead.
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> instead.
</para>
<para>
@@ -4261,18 +4263,19 @@
</indexterm>
<literal>STRAIGHT_JOIN</literal> does not apply to any table
- that the optimizer treats as a <literal role="jointype">const</literal> or
- <literal role="jointype">system</literal> table. Such a table produces a
- single row, is read during the optimization phase of query
- execution, and references to its columns are replaced with the
- appropriate column values before query execution proceeds.
- These tables will appear first in the query plan displayed by
- <literal role="stmt">EXPLAIN</literal>. See
+ that the optimizer treats as a
+ <literal role="jointype">const</literal> or
+ <literal role="jointype">system</literal> table. Such a table
+ produces a single row, is read during the optimization phase
+ of query execution, and references to its columns are replaced
+ with the appropriate column values before query execution
+ proceeds. These tables will appear first in the query plan
+ displayed by <literal role="stmt">EXPLAIN</literal>. See
<xref linkend="using-explain"/>. This exception may not apply
- to <literal role="jointype">const</literal> or <literal role="jointype">system</literal>
- tables that are used on the
- <literal>NULL</literal>-complemented side of an outer join
- (that is, the right-side table of a <literal>LEFT
+ to <literal role="jointype">const</literal> or
+ <literal role="jointype">system</literal> tables that are used
+ on the <literal>NULL</literal>-complemented side of an outer
+ join (that is, the right-side table of a <literal>LEFT
JOIN</literal> or the left-side table of a <literal>RIGHT
JOIN</literal>.
</para>
@@ -6432,7 +6435,8 @@
MySQL replaces subqueries of the following form with an
index-lookup function, which
<literal role="stmt">EXPLAIN</literal> describes as a
- special join type (<literal role="jointype">unique_subquery</literal> or
+ special join type
+ (<literal role="jointype">unique_subquery</literal> or
<literal role="jointype">index_subquery</literal>):
</para>
Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-4.1/storage-engines.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 5, Lines Deleted: 4; 1163 bytes
@@ -2129,10 +2129,11 @@
read buffers to find the next key. Only when one key buffer is
used up does the storage engine need to read the next key
block. This makes <literal>MERGE</literal> keys much slower on
- <literal role="jointype">eq_ref</literal> searches, but not much slower on
- <literal role="jointype">ref</literal> searches. See
- <xref linkend="explain"/>, for more information about
- <literal role="jointype">eq_ref</literal> and <literal role="jointype">ref</literal>.
+ <literal role="jointype">eq_ref</literal> searches, but not
+ much slower on <literal role="jointype">ref</literal>
+ searches. See <xref linkend="explain"/>, for more information
+ about <literal role="jointype">eq_ref</literal> and
+ <literal role="jointype">ref</literal>.
</para>
</listitem>
Modified: trunk/refman-5.0/apis-c.xml
===================================================================
--- trunk/refman-5.0/apis-c.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.0/apis-c.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 6, Lines Added: 24, Lines Deleted: 18; 4806 bytes
@@ -1157,13 +1157,14 @@
</row>
<row>
<entry><literal role="cfunc">mysql_set_local_infile_default()</literal></entry>
- <entry>Set the <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> handler callbacks to
- their default values</entry>
+ <entry>Set the <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> handler callbacks to their default values</entry>
</row>
<row>
<entry><literal role="cfunc">mysql_set_local_infile_handler()</literal></entry>
- <entry>Install application-specific <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- handler callbacks</entry>
+ <entry>Install application-specific
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> handler callbacks</entry>
</row>
<row>
<entry><literal role="cfunc">mysql_set_server_option()</literal></entry>
@@ -5729,7 +5730,8 @@
</row>
<row>
<entry><literal>disable-local-infile</literal></entry>
- <entry>Disable use of <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal>.</entry>
+ <entry>Disable use of <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal>.</entry>
</row>
<row>
<entry><literal>host=<replaceable>host_name</replaceable></literal></entry>
@@ -5748,7 +5750,8 @@
</row>
<row>
<entry><literal>local-infile[={0|1}]</literal></entry>
- <entry>If no argument or non-zero argument, enable use of <literal role="stmt" condition="load-data">LOAD DATA
+ <entry>If no argument or non-zero argument, enable use of
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal>; otherwise disable.</entry>
</row>
<row>
@@ -6279,7 +6282,8 @@
</row>
<row>
<entry><literal>CLIENT_LOCAL_FILES</literal></entry>
- <entry>Enable <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> handling.</entry>
+ <entry>Enable <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> handling.</entry>
</row>
<row>
<entry><literal>CLIENT_MULTI_RESULTS</literal></entry>
@@ -7482,12 +7486,12 @@
<para>
This function installs callbacks to be used during the execution
- of <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> statements. It
- enables application programs to exert control over local
- (client-side) data file reading. The arguments are the
- connection handler, a set of pointers to callback functions, and
- a pointer to a data area that the callbacks can use to share
- information.
+ of <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statements. It enables application programs to
+ exert control over local (client-side) data file reading. The
+ arguments are the connection handler, a set of pointers to
+ callback functions, and a pointer to a data area that the
+ callbacks can use to share information.
</para>
<para>
@@ -7586,13 +7590,15 @@
After calling
<literal role="cfunc">mysql_set_local_infile_handler()</literal>
in your C code and passing pointers to your callback functions,
- you can then issue a <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- statement (for example, by using
+ you can then issue a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statement (for example, by using
<literal role="cfunc">mysql_query()</literal>). The client
library automatically invokes your callbacks. The filename
- specified in <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> will be
- passed as the second parameter to the
- <literal>local_infile_init()</literal> callback.
+ specified in <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL INFILE</literal> will be passed as the second
+ parameter to the <literal>local_infile_init()</literal>
+ callback.
</para>
<para>
Modified: trunk/refman-5.0/dba-security-core.xml
===================================================================
--- trunk/refman-5.0/dba-security-core.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.0/dba-security-core.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 7, Lines Added: 32, Lines Deleted: 25; 5541 bytes
@@ -1001,7 +1001,8 @@
<section id="load-data-local">
- <title>Security Issues with <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal></title>
+ <title>Security Issues with <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL</literal></title>
<para>
The <literal role="stmt">LOAD DATA</literal> statement can load a
@@ -1033,7 +1034,8 @@
<listitem>
<para>
In a Web environment where the clients are connecting from a
- Web server, a user could use <literal role="stmt" condition="load-data">LOAD DATA
+ Web server, a user could use
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> to read any files that the Web server process
has read access to (assuming that a user could run any command
against the SQL server). In this environment, the client with
@@ -1046,7 +1048,8 @@
</itemizedlist>
<para>
- To deal with these problems, we changed how <literal role="stmt" condition="load-data">LOAD DATA
+ To deal with these problems, we changed how
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> is handled as of MySQL 3.23.49 and MySQL 4.0.2
(4.0.13 on Windows):
</para>
@@ -1066,8 +1069,9 @@
<para>
If you build MySQL from source but do not invoke
<command>configure</command> with the
- <option>--enable-local-infile</option> option, <literal role="stmt" condition="load-data">LOAD
- DATA LOCAL</literal> cannot be used by any client unless it is
+ <option>--enable-local-infile</option> option,
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> cannot be used by any client unless it is
written explicitly to invoke
<literal role="cfunc">mysql_options(...
MYSQL_OPT_LOCAL_INFILE, 0)</literal>. See
@@ -1077,8 +1081,9 @@
<listitem>
<para>
- You can disable all <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal>
- commands from the server side by starting
+ You can disable all
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> commands from the server side by starting
<command>mysqld</command> with the
<option>--local-infile=0</option> option.
</para>
@@ -1087,26 +1092,27 @@
<listitem>
<para>
For the <command>mysql</command> command-line client,
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> can be enabled by
- specifying the <option>--local-infile[=1]</option> option, or
- disabled with the <option>--local-infile=0</option> option.
- Similarly, for <command>mysqlimport</command>, the
- <option>--local</option> or <option>-L</option> option enables
- local data file loading. In any case, successful use of a
- local loading operation requires that the server is enabled to
- allow it.
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> can be enabled by specifying the
+ <option>--local-infile[=1]</option> option, or disabled with
+ the <option>--local-infile=0</option> option. Similarly, for
+ <command>mysqlimport</command>, the <option>--local</option>
+ or <option>-L</option> option enables local data file loading.
+ In any case, successful use of a local loading operation
+ requires that the server is enabled to allow it.
</para>
</listitem>
<listitem>
<para>
- If you use <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> in Perl scripts
- or other programs that read the <literal>[client]</literal>
- group from option files, you can add the
- <literal>local-infile=1</literal> option to that group.
- However, to keep this from causing problems for programs that
- do not understand <literal>local-infile</literal>, specify it
- using the <literal>loose-</literal> prefix:
+ If you use <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL</literal> in Perl scripts or other programs that
+ read the <literal>[client]</literal> group from option files,
+ you can add the <literal>local-infile=1</literal> option to
+ that group. However, to keep this from causing problems for
+ programs that do not understand
+ <literal>local-infile</literal>, specify it using the
+ <literal>loose-</literal> prefix:
</para>
<programlisting>
@@ -1117,9 +1123,10 @@
<listitem>
<para>
- If <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> is disabled,
- either in the server or the client, a client that attempts to
- issue such a statement receives the following error message:
+ If <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> is disabled, either in the server or the
+ client, a client that attempts to issue such a statement
+ receives the following error message:
</para>
<programlisting>
Modified: trunk/refman-5.0/mysql-cluster-management.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-management.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.0/mysql-cluster-management.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 3, Lines Deleted: 2; 882 bytes
@@ -4831,8 +4831,9 @@
<xref linkend="mysql-cluster-start-phases"/>.
(<replaceable>type</replaceable> is one of
<literal>initial</literal>,
- <literal role="jointype">system</literal>, <literal>node</literal>,
- <literal>initial node</literal>, or
+ <literal role="jointype">system</literal>,
+ <literal>node</literal>, <literal>initial
+ node</literal>, or
<literal><Unknown></literal>.)
</para>
Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.0/optimization.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 33, Lines Added: 133, Lines Deleted: 108; 23826 bytes
@@ -916,7 +916,8 @@
<para>
The table has only one row (= system table). This is a
- special case of the <literal role="jointype">const</literal> join type.
+ special case of the
+ <literal role="jointype">const</literal> join type.
</para>
</listitem>
@@ -945,15 +946,15 @@
the start of the query. Because there is only one row,
values from the column in this row can be regarded as
constants by the rest of the optimizer.
- <literal role="jointype">const</literal> tables are very fast because
- they are read only once.
+ <literal role="jointype">const</literal> tables are very
+ fast because they are read only once.
</para>
<para>
- <literal role="jointype">const</literal> is used when you compare all
- parts of a <literal>PRIMARY KEY</literal> or
- <literal>UNIQUE</literal> index to constant values. In
- the following queries,
+ <literal role="jointype">const</literal> is used when
+ you compare all parts of a <literal>PRIMARY
+ KEY</literal> or <literal>UNIQUE</literal> index to
+ constant values. In the following queries,
<replaceable>tbl_name</replaceable> can be used as a
<literal role="jointype">const</literal> table:
</para>
@@ -984,21 +985,23 @@
<para>
One row is read from this table for each combination of
rows from the previous tables. Other than the
- <literal role="jointype">system</literal> and <literal role="jointype">const</literal>
- types, this is the best possible join type. It is used
- when all parts of an index are used by the join and the
- index is a <literal>PRIMARY KEY</literal> or
+ <literal role="jointype">system</literal> and
+ <literal role="jointype">const</literal> types, this is
+ the best possible join type. It is used when all parts
+ of an index are used by the join and the index is a
+ <literal>PRIMARY KEY</literal> or
<literal>UNIQUE</literal> index.
</para>
<para>
- <literal role="jointype">eq_ref</literal> can be used for indexed
- columns that are compared using the <literal>=</literal>
- operator. The comparison value can be a constant or an
- expression that uses columns from tables that are read
- before this table. In the following examples, MySQL can
- use an <literal role="jointype">eq_ref</literal> join to process
- <replaceable>ref_table</replaceable>:
+ <literal role="jointype">eq_ref</literal> can be used
+ for indexed columns that are compared using the
+ <literal>=</literal> operator. The comparison value can
+ be a constant or an expression that uses columns from
+ tables that are read before this table. In the following
+ examples, MySQL can use an
+ <literal role="jointype">eq_ref</literal> join to
+ process <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1029,9 +1032,9 @@
<para>
All rows with matching index values are read from this
table for each combination of rows from the previous
- tables. <literal role="jointype">ref</literal> is used if the join uses
- only a leftmost prefix of the key or if the key is not a
- <literal>PRIMARY KEY</literal> or
+ tables. <literal role="jointype">ref</literal> is used
+ if the join uses only a leftmost prefix of the key or if
+ the key is not a <literal>PRIMARY KEY</literal> or
<literal>UNIQUE</literal> index (in other words, if the
join cannot select a single row based on the key value).
If the key that is used matches only a few rows, this is
@@ -1043,11 +1046,12 @@
</remark>
<para>
- <literal role="jointype">ref</literal> can be used for indexed columns
- that are compared using the <literal>=</literal> or
- <literal><=></literal> operator. In the following
- examples, MySQL can use a <literal role="jointype">ref</literal> join to
- process <replaceable>ref_table</replaceable>:
+ <literal role="jointype">ref</literal> can be used for
+ indexed columns that are compared using the
+ <literal>=</literal> or <literal><=></literal>
+ operator. In the following examples, MySQL can use a
+ <literal role="jointype">ref</literal> join to process
+ <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1099,13 +1103,14 @@
</para>
<para>
- This join type is like <literal role="jointype">ref</literal>, but with
- the addition that MySQL does an extra search for rows
- that contain <literal>NULL</literal> values. This join
- type optimization is used most often in resolving
- subqueries. In the following examples, MySQL can use a
- <literal role="jointype">ref_or_null</literal> join to process
- <replaceable>ref_table</replaceable>:
+ This join type is like
+ <literal role="jointype">ref</literal>, but with the
+ addition that MySQL does an extra search for rows that
+ contain <literal>NULL</literal> values. This join type
+ optimization is used most often in resolving subqueries.
+ In the following examples, MySQL can use a
+ <literal role="jointype">ref_or_null</literal> join to
+ process <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1160,7 +1165,8 @@
</para>
<para>
- This type replaces <literal role="jointype">ref</literal> for some
+ This type replaces
+ <literal role="jointype">ref</literal> for some
<literal>IN</literal> subqueries of the following form:
</para>
@@ -1169,9 +1175,9 @@
</programlisting>
<para>
- <literal role="jointype">unique_subquery</literal> is just an index
- lookup function that replaces the subquery completely
- for better efficiency.
+ <literal role="jointype">unique_subquery</literal> is
+ just an index lookup function that replaces the subquery
+ completely for better efficiency.
</para>
</listitem>
@@ -1192,9 +1198,10 @@
<para>
This join type is similar to
- <literal role="jointype">unique_subquery</literal>. It replaces
- <literal>IN</literal> subqueries, but it works for
- non-unique indexes in subqueries of the following form:
+ <literal role="jointype">unique_subquery</literal>. It
+ replaces <literal>IN</literal> subqueries, but it works
+ for non-unique indexes in subqueries of the following
+ form:
</para>
<programlisting>
@@ -1222,14 +1229,15 @@
an index to select the rows. The <literal>key</literal>
column in the output row indicates which index is used.
The <literal>key_len</literal> contains the longest key
- part that was used. The <literal role="jointype">ref</literal> column is
+ part that was used. The
+ <literal role="jointype">ref</literal> column is
<literal>NULL</literal> for this type.
</para>
<para>
- <literal role="jointype">range</literal> can be used when a key column
- is compared to a constant using any of the
- <literal role="op" condition="equal">=</literal>,
+ <literal role="jointype">range</literal> can be used
+ when a key column is compared to a constant using any of
+ the <literal role="op" condition="equal">=</literal>,
<literal role="op" condition="not-equal"><></literal>,
<literal role="op" condition="greater-than">></literal>,
<literal role="op" condition="greater-than-or-equal">>=</literal>,
@@ -1272,10 +1280,11 @@
</para>
<para>
- This join type is the same as <literal role="jointype_all">ALL</literal>,
- except that only the index tree is scanned. This usually
- is faster than <literal role="jointype_all">ALL</literal> because the index
- file usually is smaller than the data file.
+ This join type is the same as
+ <literal role="jointype_all">ALL</literal>, except that
+ only the index tree is scanned. This usually is faster
+ than <literal role="jointype_all">ALL</literal> because
+ the index file usually is smaller than the data file.
</para>
<para>
@@ -1305,7 +1314,8 @@
the table is the first table not marked
<literal role="jointype">const</literal>, and usually
<emphasis>very</emphasis> bad in all other cases.
- Normally, you can avoid <literal role="jointype_all">ALL</literal> by adding
+ Normally, you can avoid
+ <literal role="jointype_all">ALL</literal> by adding
indexes that allow row retrieval from the table based on
constant values or column values from earlier tables.
</para>
@@ -1420,9 +1430,10 @@
</para>
<para>
- The <literal role="jointype">ref</literal> column shows which columns or
- constants are compared to the index named in the
- <literal>key</literal> column to select rows from the table.
+ The <literal role="jointype">ref</literal> column shows
+ which columns or constants are compared to the index named
+ in the <literal>key</literal> column to select rows from the
+ table.
</para>
</listitem>
@@ -1484,9 +1495,11 @@
</para>
<para>
- MySQL has read all <literal role="jointype">const</literal> (and
- <literal role="jointype">system</literal>) tables and notice that the
- <literal>WHERE</literal> clause is always false.
+ MySQL has read all
+ <literal role="jointype">const</literal> (and
+ <literal role="jointype">system</literal>) tables and
+ notice that the <literal>WHERE</literal> clause is
+ always false.
</para>
</listitem>
@@ -1550,9 +1563,9 @@
tables are known. For each row combination in the
preceding tables, MySQL checks whether it is possible to
use a <literal role="jointype">range</literal> or
- <literal role="jointype">index_merge</literal> access method to retrieve
- rows. This is not very fast, but is faster than
- performing a join with no index at all. The
+ <literal role="jointype">index_merge</literal> access
+ method to retrieve rows. This is not very fast, but is
+ faster than performing a join with no index at all. The
applicability criteria are as described in
<xref linkend="range-optimization"/>, and
<xref linkend="index-merge-optimization"/>, with the
@@ -1646,8 +1659,8 @@
<para>
These indicate how index scans are merged for the
- <literal role="jointype">index_merge</literal> join type. See
- <xref linkend="index-merge-optimization"/>.
+ <literal role="jointype">index_merge</literal> join
+ type. See <xref linkend="index-merge-optimization"/>.
</para>
</listitem>
@@ -1677,7 +1690,8 @@
examine all rows from the table, you may have something
wrong in your query if the <literal>Extra</literal>
value is not <literal>Using where</literal> and the
- table join type is <literal role="jointype_all">ALL</literal> or
+ table join type is
+ <literal role="jointype_all">ALL</literal> or
<literal role="jointype">index</literal>.
</para>
</listitem>
@@ -1867,14 +1881,15 @@
</programlisting>
<para>
- Because <literal>type</literal> is <literal role="jointype_all">ALL</literal> for
- each table, this output indicates that MySQL is generating a
- Cartesian product of all the tables; that is, every combination
- of rows. This takes quite a long time, because the product of
- the number of rows in each table must be examined. For the case
- at hand, this product is 74 × 2135 × 74 × 3872
- = 45,268,558,720 rows. If the tables were bigger, you can only
- imagine how long it would take.
+ Because <literal>type</literal> is
+ <literal role="jointype_all">ALL</literal> for each table, this
+ output indicates that MySQL is generating a Cartesian product of
+ all the tables; that is, every combination of rows. This takes
+ quite a long time, because the product of the number of rows in
+ each table must be examined. For the case at hand, this product
+ is 74 × 2135 × 74 × 3872 = 45,268,558,720
+ rows. If the tables were bigger, you can only imagine how long
+ it would take.
</para>
<para>
@@ -2438,12 +2453,12 @@
<title>Range Optimization</title>
<para>
- The <literal role="jointype">range</literal> access method uses a single index
- to retrieve a subset of table rows that are contained within one
- or several index value intervals. It can be used for a
- single-part or multiple-part index. The following sections give
- a detailed description of how intervals are extracted from the
- <literal>WHERE</literal> clause.
+ The <literal role="jointype">range</literal> access method uses
+ a single index to retrieve a subset of table rows that are
+ contained within one or several index value intervals. It can be
+ used for a single-part or multiple-part index. The following
+ sections give a detailed description of how intervals are
+ extracted from the <literal>WHERE</literal> clause.
</para>
<section id="range-access-single-part">
@@ -2523,7 +2538,8 @@
<listitem>
<para>
A column of a <literal role="jointype">const</literal> or
- <literal role="jointype">system</literal> table from the same join
+ <literal role="jointype">system</literal> table from the
+ same join
</para>
</listitem>
@@ -2696,8 +2712,8 @@
<para>
Currently, MySQL does not support merging multiple ranges for
- the <literal role="jointype">range</literal> access method for spatial
- indexes. To work around this limitation, you can use a
+ the <literal role="jointype">range</literal> access method for
+ spatial indexes. To work around this limitation, you can use a
<literal>UNION</literal> with identical
<literal role="stmt">SELECT</literal> statements, except that
you put each spatial predicate in a different
@@ -2965,8 +2981,9 @@
<para>
The <firstterm>Index Merge</firstterm> method is used to
- retrieve rows with several <literal role="jointype">range</literal> scans and to
- merge their results into one. The merge can produce unions,
+ retrieve rows with several
+ <literal role="jointype">range</literal> scans and to merge
+ their results into one. The merge can produce unions,
intersections, or unions-of-intersections of its underlying
scans. This access method merges index scans from a single
table; it does not merge scans across multiple tables.
@@ -2984,7 +3001,8 @@
<para>
In <literal role="stmt">EXPLAIN</literal> output, the Index
- Merge method appears as <literal role="jointype">index_merge</literal> in the
+ Merge method appears as
+ <literal role="jointype">index_merge</literal> in the
<literal>type</literal> column. In this case, the
<literal>key</literal> column contains a list of indexes used,
and <literal>key_len</literal> contains a list of the longest
@@ -3579,7 +3597,8 @@
<replaceable>col_name</replaceable> IS NULL</literal>, a form
that is common in resolved subqueries.
<literal role="stmt">EXPLAIN</literal> shows
- <literal role="jointype">ref_or_null</literal> when this optimization is used.
+ <literal role="jointype">ref_or_null</literal> when this
+ optimization is used.
</para>
<para>
@@ -3610,9 +3629,9 @@
</programlisting>
<para>
- <literal role="jointype">ref_or_null</literal> works by first doing a read on
- the reference key, and then a separate search for rows with a
- <literal>NULL</literal> key value.
+ <literal role="jointype">ref_or_null</literal> works by first
+ doing a read on the reference key, and then a separate search
+ for rows with a <literal>NULL</literal> key value.
</para>
<para>
@@ -5203,11 +5222,12 @@
clause, a loose index scan reads as many keys as the number of
groups, which may be a much smaller number than that of all
keys. If the <literal>WHERE</literal> clause contains range
- predicates (see the discussion of the <literal role="jointype">range</literal>
- join type in <xref linkend="using-explain"/>), a loose index
- scan looks up the first key of each group that satisfies the
- range conditions, and again reads the least possible number of
- keys. This is possible under the following conditions:
+ predicates (see the discussion of the
+ <literal role="jointype">range</literal> join type in
+ <xref linkend="using-explain"/>), a loose index scan looks up
+ the first key of each group that satisfies the range
+ conditions, and again reads the least possible number of keys.
+ This is possible under the following conditions:
</para>
<itemizedlist>
@@ -5671,10 +5691,11 @@
<para>
The <literal role="jointype">unique_subquery</literal> and
- <literal role="jointype">index_subquery</literal> subqery-specific access
- methods also have or-null variants. However, they are not
- visible in <literal role="stmt">EXPLAIN</literal> output, so you
- must use <literal>EXPLAIN EXTENDED</literal> followed by
+ <literal role="jointype">index_subquery</literal>
+ subqery-specific access methods also have or-null variants.
+ However, they are not visible in
+ <literal role="stmt">EXPLAIN</literal> output, so you must use
+ <literal>EXPLAIN EXTENDED</literal> followed by
<literal role="stmt">SHOW WARNINGS</literal> (note the
<literal>checking NULL</literal> in the warning message):
</para>
@@ -5899,8 +5920,9 @@
<literal>trigcond(<replaceable>X</replaceable>=<replaceable>Y</replaceable>
[OR <replaceable>Y</replaceable> IS NULL])</literal> can be
used to construct <literal role="jointype">ref</literal>,
- <literal role="jointype">eq_ref</literal>, or <literal role="jointype">ref_or_null</literal>
- table accesses.
+ <literal role="jointype">eq_ref</literal>, or
+ <literal role="jointype">ref_or_null</literal> table
+ accesses.
</para>
</listitem>
@@ -5908,8 +5930,9 @@
<para>
Index lookup-based subquery execution engines:
<literal>trigcond(<replaceable>X</replaceable>=<replaceable>Y</replaceable>)</literal>
- can be used to construct <literal role="jointype">unique_subquery</literal>
- or <literal role="jointype">index_subquery</literal> accesses.
+ can be used to construct
+ <literal role="jointype">unique_subquery</literal> or
+ <literal role="jointype">index_subquery</literal> accesses.
</para>
</listitem>
@@ -6159,9 +6182,10 @@
<para>
The output from <literal role="stmt">EXPLAIN</literal> shows
- <literal role="jointype_all">ALL</literal> in the <literal>type</literal> column
- when MySQL uses a table scan to resolve a query. This usually
- happens under the following conditions:
+ <literal role="jointype_all">ALL</literal> in the
+ <literal>type</literal> column when MySQL uses a table scan to
+ resolve a query. This usually happens under the following
+ conditions:
</para>
<itemizedlist>
@@ -9606,9 +9630,9 @@
<replaceable>expr2</replaceable></literal> is not true when
<replaceable>expr1</replaceable> or
<replaceable>expr2</replaceable> (or both) are
- <literal>NULL</literal>. This affects <literal role="jointype">ref</literal>
- accesses for comparisons of the form
- <literal><replaceable>tbl_name.key</replaceable> =
+ <literal>NULL</literal>. This affects
+ <literal role="jointype">ref</literal> accesses for comparisons
+ of the form <literal><replaceable>tbl_name.key</replaceable> =
<replaceable>expr</replaceable></literal>: MySQL will not access
the table if the current value of
<replaceable>expr</replaceable> is <literal>NULL</literal>,
@@ -9650,8 +9674,9 @@
useful than it really is for joins that look for
non-<literal>NULL</literal> values. Consequently, the
<literal>nulls_equal</literal> method may cause the
- optimizer not to use the index for <literal role="jointype">ref</literal>
- accesses when it should.
+ optimizer not to use the index for
+ <literal role="jointype">ref</literal> accesses when it
+ should.
</para>
</listitem>
@@ -9673,8 +9698,8 @@
index for joins that look for non-<literal>NULL</literal>
values. Consequently, the <literal>nulls_unequal</literal>
method may cause the optimizer to use this index for
- <literal role="jointype">ref</literal> lookups when other methods may be
- better.
+ <literal role="jointype">ref</literal> lookups when other
+ methods may be better.
</para>
</listitem>
Modified: trunk/refman-5.0/programs-admin-util-core.xml
===================================================================
--- trunk/refman-5.0/programs-admin-util-core.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.0/programs-admin-util-core.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 2, Lines Added: 9, Lines Deleted: 6; 2160 bytes
@@ -4462,17 +4462,19 @@
reproduces a <literal role="stmt" condition="load-data">LOAD
DATA INFILE</literal> operation without the original data file.
<command>mysqlbinlog</command> copies the data to a temporary
- file and writes a <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- statement that refers to the file. The default location of the
- directory where these files are written is system-specific. To
- specify a directory explicitly, use the
+ file and writes a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statement that refers to the file. The default
+ location of the directory where these files are written is
+ system-specific. To specify a directory explicitly, use the
<option>--local-load</option> option.
</para>
<para>
Because <command>mysqlbinlog</command> converts
<literal role="stmt" condition="load-data">LOAD DATA
- INFILE</literal> statements to <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statements to
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal> statements (that is, it adds
<literal>LOCAL</literal>), both the client and the server that
you use to process the statements must be configured to allow
@@ -4495,7 +4497,8 @@
<warning>
<para>
- The temporary files created for <literal role="stmt" condition="load-data">LOAD DATA
+ The temporary files created for
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> statements are <emphasis>not</emphasis>
automatically deleted because they are needed until you
actually execute those statements. You should delete the
Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.0/replication-notes.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 723 bytes
@@ -649,7 +649,8 @@
INFILE</literal> is replicated as
<literal role="stmt" condition="load-data">LOAD DATA
INFILE</literal>, and <literal>LOAD DATA CONCURRENT LOCAL
- INFILE</literal> is replicated as <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> is replicated as
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal>. (Bug #34628)
</para>
Modified: trunk/refman-5.0/se-merge.xml
===================================================================
--- trunk/refman-5.0/se-merge.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.0/se-merge.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 3; 1057 bytes
@@ -488,9 +488,10 @@
buffers to find the next key. Only when one key buffer is used
up does the storage engine need to read the next key block. This
makes <literal>MERGE</literal> keys much slower on
- <literal role="jointype">eq_ref</literal> searches, but not much slower on
- <literal role="jointype">ref</literal> searches. See <xref linkend="explain"/>,
- for more information about <literal role="jointype">eq_ref</literal> and
+ <literal role="jointype">eq_ref</literal> searches, but not much
+ slower on <literal role="jointype">ref</literal> searches. See
+ <xref linkend="explain"/>, for more information about
+ <literal role="jointype">eq_ref</literal> and
<literal role="jointype">ref</literal>.
</para>
</listitem>
Modified: trunk/refman-5.0/sql-syntax-data-manipulation.xml
===================================================================
--- trunk/refman-5.0/sql-syntax-data-manipulation.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.0/sql-syntax-data-manipulation.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 2, Lines Added: 14, Lines Deleted: 12; 2617 bytes
@@ -4513,18 +4513,19 @@
</indexterm>
<literal>STRAIGHT_JOIN</literal> does not apply to any table
- that the optimizer treats as a <literal role="jointype">const</literal> or
- <literal role="jointype">system</literal> table. Such a table produces a
- single row, is read during the optimization phase of query
- execution, and references to its columns are replaced with the
- appropriate column values before query execution proceeds.
- These tables will appear first in the query plan displayed by
- <literal role="stmt">EXPLAIN</literal>. See
+ that the optimizer treats as a
+ <literal role="jointype">const</literal> or
+ <literal role="jointype">system</literal> table. Such a table
+ produces a single row, is read during the optimization phase
+ of query execution, and references to its columns are replaced
+ with the appropriate column values before query execution
+ proceeds. These tables will appear first in the query plan
+ displayed by <literal role="stmt">EXPLAIN</literal>. See
<xref linkend="using-explain"/>. This exception may not apply
- to <literal role="jointype">const</literal> or <literal role="jointype">system</literal>
- tables that are used on the
- <literal>NULL</literal>-complemented side of an outer join
- (that is, the right-side table of a <literal>LEFT
+ to <literal role="jointype">const</literal> or
+ <literal role="jointype">system</literal> tables that are used
+ on the <literal>NULL</literal>-complemented side of an outer
+ join (that is, the right-side table of a <literal>LEFT
JOIN</literal> or the left-side table of a <literal>RIGHT
JOIN</literal>.
</para>
@@ -7294,7 +7295,8 @@
MySQL replaces subqueries of the following form with an
index-lookup function, which
<literal role="stmt">EXPLAIN</literal> describes as a
- special join type (<literal role="jointype">unique_subquery</literal> or
+ special join type
+ (<literal role="jointype">unique_subquery</literal> or
<literal role="jointype">index_subquery</literal>):
</para>
Modified: trunk/refman-5.1/apis-c.xml
===================================================================
--- trunk/refman-5.1/apis-c.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.1/apis-c.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 6, Lines Added: 24, Lines Deleted: 18; 4806 bytes
@@ -1150,13 +1150,14 @@
</row>
<row>
<entry><literal role="cfunc">mysql_set_local_infile_default()</literal></entry>
- <entry>Set the <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> handler callbacks to
- their default values</entry>
+ <entry>Set the <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> handler callbacks to their default values</entry>
</row>
<row>
<entry><literal role="cfunc">mysql_set_local_infile_handler()</literal></entry>
- <entry>Install application-specific <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- handler callbacks</entry>
+ <entry>Install application-specific
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> handler callbacks</entry>
</row>
<row>
<entry><literal role="cfunc">mysql_set_server_option()</literal></entry>
@@ -5781,7 +5782,8 @@
</row>
<row>
<entry><literal>disable-local-infile</literal></entry>
- <entry>Disable use of <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal>.</entry>
+ <entry>Disable use of <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal>.</entry>
</row>
<row>
<entry><literal>host=<replaceable>host_name</replaceable></literal></entry>
@@ -5800,7 +5802,8 @@
</row>
<row>
<entry><literal>local-infile[={0|1}]</literal></entry>
- <entry>If no argument or non-zero argument, enable use of <literal role="stmt" condition="load-data">LOAD DATA
+ <entry>If no argument or non-zero argument, enable use of
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal>; otherwise disable.</entry>
</row>
<row>
@@ -6335,7 +6338,8 @@
</row>
<row>
<entry><literal>CLIENT_LOCAL_FILES</literal></entry>
- <entry>Enable <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> handling.</entry>
+ <entry>Enable <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> handling.</entry>
</row>
<row>
<entry><literal>CLIENT_MULTI_RESULTS</literal></entry>
@@ -7545,12 +7549,12 @@
<para>
This function installs callbacks to be used during the execution
- of <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> statements. It
- enables application programs to exert control over local
- (client-side) data file reading. The arguments are the
- connection handler, a set of pointers to callback functions, and
- a pointer to a data area that the callbacks can use to share
- information.
+ of <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statements. It enables application programs to
+ exert control over local (client-side) data file reading. The
+ arguments are the connection handler, a set of pointers to
+ callback functions, and a pointer to a data area that the
+ callbacks can use to share information.
</para>
<para>
@@ -7649,13 +7653,15 @@
After calling
<literal role="cfunc">mysql_set_local_infile_handler()</literal>
in your C code and passing pointers to your callback functions,
- you can then issue a <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- statement (for example, by using
+ you can then issue a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statement (for example, by using
<literal role="cfunc">mysql_query()</literal>). The client
library automatically invokes your callbacks. The filename
- specified in <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> will be
- passed as the second parameter to the
- <literal>local_infile_init()</literal> callback.
+ specified in <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL INFILE</literal> will be passed as the second
+ parameter to the <literal>local_infile_init()</literal>
+ callback.
</para>
<para>
Modified: trunk/refman-5.1/dba-security-core.xml
===================================================================
--- trunk/refman-5.1/dba-security-core.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.1/dba-security-core.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 7, Lines Added: 32, Lines Deleted: 25; 5541 bytes
@@ -1015,7 +1015,8 @@
<section id="load-data-local">
- <title>Security Issues with <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal></title>
+ <title>Security Issues with <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL</literal></title>
<para>
The <literal role="stmt">LOAD DATA</literal> statement can load a
@@ -1047,7 +1048,8 @@
<listitem>
<para>
In a Web environment where the clients are connecting from a
- Web server, a user could use <literal role="stmt" condition="load-data">LOAD DATA
+ Web server, a user could use
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> to read any files that the Web server process
has read access to (assuming that a user could run any command
against the SQL server). In this environment, the client with
@@ -1060,7 +1062,8 @@
</itemizedlist>
<para>
- To deal with these problems, we changed how <literal role="stmt" condition="load-data">LOAD DATA
+ To deal with these problems, we changed how
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> is handled as of MySQL 3.23.49 and MySQL 4.0.2
(4.0.13 on Windows):
</para>
@@ -1080,8 +1083,9 @@
<para>
If you build MySQL from source but do not invoke
<command>configure</command> with the
- <option>--enable-local-infile</option> option, <literal role="stmt" condition="load-data">LOAD
- DATA LOCAL</literal> cannot be used by any client unless it is
+ <option>--enable-local-infile</option> option,
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> cannot be used by any client unless it is
written explicitly to invoke
<literal role="cfunc">mysql_options(...
MYSQL_OPT_LOCAL_INFILE, 0)</literal>. See
@@ -1091,8 +1095,9 @@
<listitem>
<para>
- You can disable all <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal>
- commands from the server side by starting
+ You can disable all
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> commands from the server side by starting
<command>mysqld</command> with the
<option>--local-infile=0</option> option.
</para>
@@ -1101,26 +1106,27 @@
<listitem>
<para>
For the <command>mysql</command> command-line client,
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> can be enabled by
- specifying the <option>--local-infile[=1]</option> option, or
- disabled with the <option>--local-infile=0</option> option.
- Similarly, for <command>mysqlimport</command>, the
- <option>--local</option> or <option>-L</option> option enables
- local data file loading. In any case, successful use of a
- local loading operation requires that the server is enabled to
- allow it.
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> can be enabled by specifying the
+ <option>--local-infile[=1]</option> option, or disabled with
+ the <option>--local-infile=0</option> option. Similarly, for
+ <command>mysqlimport</command>, the <option>--local</option>
+ or <option>-L</option> option enables local data file loading.
+ In any case, successful use of a local loading operation
+ requires that the server is enabled to allow it.
</para>
</listitem>
<listitem>
<para>
- If you use <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> in Perl scripts
- or other programs that read the <literal>[client]</literal>
- group from option files, you can add the
- <literal>local-infile=1</literal> option to that group.
- However, to keep this from causing problems for programs that
- do not understand <literal>local-infile</literal>, specify it
- using the <literal>loose-</literal> prefix:
+ If you use <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL</literal> in Perl scripts or other programs that
+ read the <literal>[client]</literal> group from option files,
+ you can add the <literal>local-infile=1</literal> option to
+ that group. However, to keep this from causing problems for
+ programs that do not understand
+ <literal>local-infile</literal>, specify it using the
+ <literal>loose-</literal> prefix:
</para>
<programlisting>
@@ -1131,9 +1137,10 @@
<listitem>
<para>
- If <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> is disabled,
- either in the server or the client, a client that attempts to
- issue such a statement receives the following error message:
+ If <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> is disabled, either in the server or the
+ client, a client that attempts to issue such a statement
+ receives the following error message:
</para>
<programlisting>
Modified: trunk/refman-5.1/mysql-cluster-management.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-management.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.1/mysql-cluster-management.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 3, Lines Deleted: 2; 882 bytes
@@ -5202,8 +5202,9 @@
<xref linkend="mysql-cluster-start-phases"/>.
(<replaceable>type</replaceable> is one of
<literal>initial</literal>,
- <literal role="jointype">system</literal>, <literal>node</literal>,
- <literal>initial node</literal>, or
+ <literal role="jointype">system</literal>,
+ <literal>node</literal>, <literal>initial
+ node</literal>, or
<literal><Unknown></literal>.)
</para>
Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.1/optimization.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 34, Lines Added: 135, Lines Deleted: 109; 24379 bytes
@@ -963,7 +963,8 @@
<para>
The table has only one row (= system table). This is a
- special case of the <literal role="jointype">const</literal> join type.
+ special case of the
+ <literal role="jointype">const</literal> join type.
</para>
</listitem>
@@ -992,15 +993,15 @@
the start of the query. Because there is only one row,
values from the column in this row can be regarded as
constants by the rest of the optimizer.
- <literal role="jointype">const</literal> tables are very fast because
- they are read only once.
+ <literal role="jointype">const</literal> tables are very
+ fast because they are read only once.
</para>
<para>
- <literal role="jointype">const</literal> is used when you compare all
- parts of a <literal>PRIMARY KEY</literal> or
- <literal>UNIQUE</literal> index to constant values. In
- the following queries,
+ <literal role="jointype">const</literal> is used when
+ you compare all parts of a <literal>PRIMARY
+ KEY</literal> or <literal>UNIQUE</literal> index to
+ constant values. In the following queries,
<replaceable>tbl_name</replaceable> can be used as a
<literal role="jointype">const</literal> table:
</para>
@@ -1031,21 +1032,23 @@
<para>
One row is read from this table for each combination of
rows from the previous tables. Other than the
- <literal role="jointype">system</literal> and <literal role="jointype">const</literal>
- types, this is the best possible join type. It is used
- when all parts of an index are used by the join and the
- index is a <literal>PRIMARY KEY</literal> or
+ <literal role="jointype">system</literal> and
+ <literal role="jointype">const</literal> types, this is
+ the best possible join type. It is used when all parts
+ of an index are used by the join and the index is a
+ <literal>PRIMARY KEY</literal> or
<literal>UNIQUE</literal> index.
</para>
<para>
- <literal role="jointype">eq_ref</literal> can be used for indexed
- columns that are compared using the <literal>=</literal>
- operator. The comparison value can be a constant or an
- expression that uses columns from tables that are read
- before this table. In the following examples, MySQL can
- use an <literal role="jointype">eq_ref</literal> join to process
- <replaceable>ref_table</replaceable>:
+ <literal role="jointype">eq_ref</literal> can be used
+ for indexed columns that are compared using the
+ <literal>=</literal> operator. The comparison value can
+ be a constant or an expression that uses columns from
+ tables that are read before this table. In the following
+ examples, MySQL can use an
+ <literal role="jointype">eq_ref</literal> join to
+ process <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1076,9 +1079,9 @@
<para>
All rows with matching index values are read from this
table for each combination of rows from the previous
- tables. <literal role="jointype">ref</literal> is used if the join uses
- only a leftmost prefix of the key or if the key is not a
- <literal>PRIMARY KEY</literal> or
+ tables. <literal role="jointype">ref</literal> is used
+ if the join uses only a leftmost prefix of the key or if
+ the key is not a <literal>PRIMARY KEY</literal> or
<literal>UNIQUE</literal> index (in other words, if the
join cannot select a single row based on the key value).
If the key that is used matches only a few rows, this is
@@ -1090,11 +1093,12 @@
</remark>
<para>
- <literal role="jointype">ref</literal> can be used for indexed columns
- that are compared using the <literal>=</literal> or
- <literal><=></literal> operator. In the following
- examples, MySQL can use a <literal role="jointype">ref</literal> join to
- process <replaceable>ref_table</replaceable>:
+ <literal role="jointype">ref</literal> can be used for
+ indexed columns that are compared using the
+ <literal>=</literal> or <literal><=></literal>
+ operator. In the following examples, MySQL can use a
+ <literal role="jointype">ref</literal> join to process
+ <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1146,13 +1150,14 @@
</para>
<para>
- This join type is like <literal role="jointype">ref</literal>, but with
- the addition that MySQL does an extra search for rows
- that contain <literal>NULL</literal> values. This join
- type optimization is used most often in resolving
- subqueries. In the following examples, MySQL can use a
- <literal role="jointype">ref_or_null</literal> join to process
- <replaceable>ref_table</replaceable>:
+ This join type is like
+ <literal role="jointype">ref</literal>, but with the
+ addition that MySQL does an extra search for rows that
+ contain <literal>NULL</literal> values. This join type
+ optimization is used most often in resolving subqueries.
+ In the following examples, MySQL can use a
+ <literal role="jointype">ref_or_null</literal> join to
+ process <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1207,7 +1212,8 @@
</para>
<para>
- This type replaces <literal role="jointype">ref</literal> for some
+ This type replaces
+ <literal role="jointype">ref</literal> for some
<literal>IN</literal> subqueries of the following form:
</para>
@@ -1216,9 +1222,9 @@
</programlisting>
<para>
- <literal role="jointype">unique_subquery</literal> is just an index
- lookup function that replaces the subquery completely
- for better efficiency.
+ <literal role="jointype">unique_subquery</literal> is
+ just an index lookup function that replaces the subquery
+ completely for better efficiency.
</para>
</listitem>
@@ -1239,9 +1245,10 @@
<para>
This join type is similar to
- <literal role="jointype">unique_subquery</literal>. It replaces
- <literal>IN</literal> subqueries, but it works for
- non-unique indexes in subqueries of the following form:
+ <literal role="jointype">unique_subquery</literal>. It
+ replaces <literal>IN</literal> subqueries, but it works
+ for non-unique indexes in subqueries of the following
+ form:
</para>
<programlisting>
@@ -1269,14 +1276,15 @@
an index to select the rows. The <literal>key</literal>
column in the output row indicates which index is used.
The <literal>key_len</literal> contains the longest key
- part that was used. The <literal role="jointype">ref</literal> column is
+ part that was used. The
+ <literal role="jointype">ref</literal> column is
<literal>NULL</literal> for this type.
</para>
<para>
- <literal role="jointype">range</literal> can be used when a key column
- is compared to a constant using any of the
- <literal role="op" condition="equal">=</literal>,
+ <literal role="jointype">range</literal> can be used
+ when a key column is compared to a constant using any of
+ the <literal role="op" condition="equal">=</literal>,
<literal role="op" condition="not-equal"><></literal>,
<literal role="op" condition="greater-than">></literal>,
<literal role="op" condition="greater-than-or-equal">>=</literal>,
@@ -1319,10 +1327,11 @@
</para>
<para>
- This join type is the same as <literal role="jointype_all">ALL</literal>,
- except that only the index tree is scanned. This usually
- is faster than <literal role="jointype_all">ALL</literal> because the index
- file usually is smaller than the data file.
+ This join type is the same as
+ <literal role="jointype_all">ALL</literal>, except that
+ only the index tree is scanned. This usually is faster
+ than <literal role="jointype_all">ALL</literal> because
+ the index file usually is smaller than the data file.
</para>
<para>
@@ -1352,7 +1361,8 @@
the table is the first table not marked
<literal role="jointype">const</literal>, and usually
<emphasis>very</emphasis> bad in all other cases.
- Normally, you can avoid <literal role="jointype_all">ALL</literal> by adding
+ Normally, you can avoid
+ <literal role="jointype_all">ALL</literal> by adding
indexes that allow row retrieval from the table based on
constant values or column values from earlier tables.
</para>
@@ -1467,9 +1477,10 @@
</para>
<para>
- The <literal role="jointype">ref</literal> column shows which columns or
- constants are compared to the index named in the
- <literal>key</literal> column to select rows from the table.
+ The <literal role="jointype">ref</literal> column shows
+ which columns or constants are compared to the index named
+ in the <literal>key</literal> column to select rows from the
+ table.
</para>
</listitem>
@@ -1549,9 +1560,11 @@
</para>
<para>
- MySQL has read all <literal role="jointype">const</literal> (and
- <literal role="jointype">system</literal>) tables and notice that the
- <literal>WHERE</literal> clause is always false.
+ MySQL has read all
+ <literal role="jointype">const</literal> (and
+ <literal role="jointype">system</literal>) tables and
+ notice that the <literal>WHERE</literal> clause is
+ always false.
</para>
</listitem>
@@ -1615,9 +1628,9 @@
tables are known. For each row combination in the
preceding tables, MySQL checks whether it is possible to
use a <literal role="jointype">range</literal> or
- <literal role="jointype">index_merge</literal> access method to retrieve
- rows. This is not very fast, but is faster than
- performing a join with no index at all. The
+ <literal role="jointype">index_merge</literal> access
+ method to retrieve rows. This is not very fast, but is
+ faster than performing a join with no index at all. The
applicability criteria are as described in
<xref linkend="range-optimization"/>, and
<xref linkend="index-merge-optimization"/>, with the
@@ -1758,7 +1771,8 @@
user-defined clustered index, that index can be used
even when <literal>Using index</literal> is absent from
the <literal>Extra</literal> column. This is the case if
- <literal>type</literal> is <literal role="jointype">index</literal> and
+ <literal>type</literal> is
+ <literal role="jointype">index</literal> and
<literal>key</literal> is <literal>PRIMARY</literal>.
</para>
</listitem>
@@ -1803,8 +1817,8 @@
<para>
These indicate how index scans are merged for the
- <literal role="jointype">index_merge</literal> join type. See
- <xref linkend="index-merge-optimization"/>.
+ <literal role="jointype">index_merge</literal> join
+ type. See <xref linkend="index-merge-optimization"/>.
</para>
</listitem>
@@ -1834,7 +1848,8 @@
examine all rows from the table, you may have something
wrong in your query if the <literal>Extra</literal>
value is not <literal>Using where</literal> and the
- table join type is <literal role="jointype_all">ALL</literal> or
+ table join type is
+ <literal role="jointype_all">ALL</literal> or
<literal role="jointype">index</literal>.
</para>
</listitem>
@@ -2024,14 +2039,15 @@
</programlisting>
<para>
- Because <literal>type</literal> is <literal role="jointype_all">ALL</literal> for
- each table, this output indicates that MySQL is generating a
- Cartesian product of all the tables; that is, every combination
- of rows. This takes quite a long time, because the product of
- the number of rows in each table must be examined. For the case
- at hand, this product is 74 × 2135 × 74 × 3872
- = 45,268,558,720 rows. If the tables were bigger, you can only
- imagine how long it would take.
+ Because <literal>type</literal> is
+ <literal role="jointype_all">ALL</literal> for each table, this
+ output indicates that MySQL is generating a Cartesian product of
+ all the tables; that is, every combination of rows. This takes
+ quite a long time, because the product of the number of rows in
+ each table must be examined. For the case at hand, this product
+ is 74 × 2135 × 74 × 3872 = 45,268,558,720
+ rows. If the tables were bigger, you can only imagine how long
+ it would take.
</para>
<para>
@@ -2595,12 +2611,12 @@
<title>Range Optimization</title>
<para>
- The <literal role="jointype">range</literal> access method uses a single index
- to retrieve a subset of table rows that are contained within one
- or several index value intervals. It can be used for a
- single-part or multiple-part index. The following sections give
- a detailed description of how intervals are extracted from the
- <literal>WHERE</literal> clause.
+ The <literal role="jointype">range</literal> access method uses
+ a single index to retrieve a subset of table rows that are
+ contained within one or several index value intervals. It can be
+ used for a single-part or multiple-part index. The following
+ sections give a detailed description of how intervals are
+ extracted from the <literal>WHERE</literal> clause.
</para>
<section id="range-access-single-part">
@@ -2680,7 +2696,8 @@
<listitem>
<para>
A column of a <literal role="jointype">const</literal> or
- <literal role="jointype">system</literal> table from the same join
+ <literal role="jointype">system</literal> table from the
+ same join
</para>
</listitem>
@@ -2853,8 +2870,8 @@
<para>
Currently, MySQL does not support merging multiple ranges for
- the <literal role="jointype">range</literal> access method for spatial
- indexes. To work around this limitation, you can use a
+ the <literal role="jointype">range</literal> access method for
+ spatial indexes. To work around this limitation, you can use a
<literal>UNION</literal> with identical
<literal role="stmt">SELECT</literal> statements, except that
you put each spatial predicate in a different
@@ -3122,8 +3139,9 @@
<para>
The <firstterm>Index Merge</firstterm> method is used to
- retrieve rows with several <literal role="jointype">range</literal> scans and to
- merge their results into one. The merge can produce unions,
+ retrieve rows with several
+ <literal role="jointype">range</literal> scans and to merge
+ their results into one. The merge can produce unions,
intersections, or unions-of-intersections of its underlying
scans. This access method merges index scans from a single
table; it does not merge scans across multiple tables.
@@ -3131,7 +3149,8 @@
<para>
In <literal role="stmt">EXPLAIN</literal> output, the Index
- Merge method appears as <literal role="jointype">index_merge</literal> in the
+ Merge method appears as
+ <literal role="jointype">index_merge</literal> in the
<literal>type</literal> column. In this case, the
<literal>key</literal> column contains a list of indexes used,
and <literal>key_len</literal> contains a list of the longest
@@ -3726,7 +3745,8 @@
<replaceable>col_name</replaceable> IS NULL</literal>, a form
that is common in resolved subqueries.
<literal role="stmt">EXPLAIN</literal> shows
- <literal role="jointype">ref_or_null</literal> when this optimization is used.
+ <literal role="jointype">ref_or_null</literal> when this
+ optimization is used.
</para>
<para>
@@ -3757,9 +3777,9 @@
</programlisting>
<para>
- <literal role="jointype">ref_or_null</literal> works by first doing a read on
- the reference key, and then a separate search for rows with a
- <literal>NULL</literal> key value.
+ <literal role="jointype">ref_or_null</literal> works by first
+ doing a read on the reference key, and then a separate search
+ for rows with a <literal>NULL</literal> key value.
</para>
<para>
@@ -5339,11 +5359,12 @@
clause, a loose index scan reads as many keys as the number of
groups, which may be a much smaller number than that of all
keys. If the <literal>WHERE</literal> clause contains range
- predicates (see the discussion of the <literal role="jointype">range</literal>
- join type in <xref linkend="using-explain"/>), a loose index
- scan looks up the first key of each group that satisfies the
- range conditions, and again reads the least possible number of
- keys. This is possible under the following conditions:
+ predicates (see the discussion of the
+ <literal role="jointype">range</literal> join type in
+ <xref linkend="using-explain"/>), a loose index scan looks up
+ the first key of each group that satisfies the range
+ conditions, and again reads the least possible number of keys.
+ This is possible under the following conditions:
</para>
<itemizedlist>
@@ -5807,10 +5828,11 @@
<para>
The <literal role="jointype">unique_subquery</literal> and
- <literal role="jointype">index_subquery</literal> subquery-specific access
- methods also have or-null variants. However, they are not
- visible in <literal role="stmt">EXPLAIN</literal> output, so you
- must use <literal>EXPLAIN EXTENDED</literal> followed by
+ <literal role="jointype">index_subquery</literal>
+ subquery-specific access methods also have or-null variants.
+ However, they are not visible in
+ <literal role="stmt">EXPLAIN</literal> output, so you must use
+ <literal>EXPLAIN EXTENDED</literal> followed by
<literal role="stmt">SHOW WARNINGS</literal> (note the
<literal>checking NULL</literal> in the warning message):
</para>
@@ -6035,8 +6057,9 @@
<literal>trigcond(<replaceable>X</replaceable>=<replaceable>Y</replaceable>
[OR <replaceable>Y</replaceable> IS NULL])</literal> can be
used to construct <literal role="jointype">ref</literal>,
- <literal role="jointype">eq_ref</literal>, or <literal role="jointype">ref_or_null</literal>
- table accesses.
+ <literal role="jointype">eq_ref</literal>, or
+ <literal role="jointype">ref_or_null</literal> table
+ accesses.
</para>
</listitem>
@@ -6044,8 +6067,9 @@
<para>
Index lookup-based subquery execution engines:
<literal>trigcond(<replaceable>X</replaceable>=<replaceable>Y</replaceable>)</literal>
- can be used to construct <literal role="jointype">unique_subquery</literal>
- or <literal role="jointype">index_subquery</literal> accesses.
+ can be used to construct
+ <literal role="jointype">unique_subquery</literal> or
+ <literal role="jointype">index_subquery</literal> accesses.
</para>
</listitem>
@@ -6295,9 +6319,10 @@
<para>
The output from <literal role="stmt">EXPLAIN</literal> shows
- <literal role="jointype_all">ALL</literal> in the <literal>type</literal> column
- when MySQL uses a table scan to resolve a query. This usually
- happens under the following conditions:
+ <literal role="jointype_all">ALL</literal> in the
+ <literal>type</literal> column when MySQL uses a table scan to
+ resolve a query. This usually happens under the following
+ conditions:
</para>
<itemizedlist>
@@ -10442,9 +10467,9 @@
<replaceable>expr2</replaceable></literal> is not true when
<replaceable>expr1</replaceable> or
<replaceable>expr2</replaceable> (or both) are
- <literal>NULL</literal>. This affects <literal role="jointype">ref</literal>
- accesses for comparisons of the form
- <literal><replaceable>tbl_name.key</replaceable> =
+ <literal>NULL</literal>. This affects
+ <literal role="jointype">ref</literal> accesses for comparisons
+ of the form <literal><replaceable>tbl_name.key</replaceable> =
<replaceable>expr</replaceable></literal>: MySQL will not access
the table if the current value of
<replaceable>expr</replaceable> is <literal>NULL</literal>,
@@ -10486,8 +10511,9 @@
useful than it really is for joins that look for
non-<literal>NULL</literal> values. Consequently, the
<literal>nulls_equal</literal> method may cause the
- optimizer not to use the index for <literal role="jointype">ref</literal>
- accesses when it should.
+ optimizer not to use the index for
+ <literal role="jointype">ref</literal> accesses when it
+ should.
</para>
</listitem>
@@ -10509,8 +10535,8 @@
index for joins that look for non-<literal>NULL</literal>
values. Consequently, the <literal>nulls_unequal</literal>
method may cause the optimizer to use this index for
- <literal role="jointype">ref</literal> lookups when other methods may be
- better.
+ <literal role="jointype">ref</literal> lookups when other
+ methods may be better.
</para>
</listitem>
Modified: trunk/refman-5.1/programs-admin-util-core.xml
===================================================================
--- trunk/refman-5.1/programs-admin-util-core.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.1/programs-admin-util-core.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 2, Lines Added: 9, Lines Deleted: 6; 2160 bytes
@@ -4681,17 +4681,19 @@
reproduces a <literal role="stmt" condition="load-data">LOAD
DATA INFILE</literal> operation without the original data file.
<command>mysqlbinlog</command> copies the data to a temporary
- file and writes a <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- statement that refers to the file. The default location of the
- directory where these files are written is system-specific. To
- specify a directory explicitly, use the
+ file and writes a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statement that refers to the file. The default
+ location of the directory where these files are written is
+ system-specific. To specify a directory explicitly, use the
<option>--local-load</option> option.
</para>
<para>
Because <command>mysqlbinlog</command> converts
<literal role="stmt" condition="load-data">LOAD DATA
- INFILE</literal> statements to <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statements to
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal> statements (that is, it adds
<literal>LOCAL</literal>), both the client and the server that
you use to process the statements must be configured to allow
@@ -4714,7 +4716,8 @@
<warning>
<para>
- The temporary files created for <literal role="stmt" condition="load-data">LOAD DATA
+ The temporary files created for
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> statements are <emphasis>not</emphasis>
automatically deleted because they are needed until you
actually execute those statements. You should delete the
Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.1/replication-notes.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 836 bytes
@@ -1458,7 +1458,8 @@
INFILE</literal> is replicated as
<literal role="stmt" condition="load-data">LOAD DATA
INFILE</literal>, and <literal>LOAD DATA CONCURRENT LOCAL
- INFILE</literal> is replicated as <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> is replicated as
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal>. The <literal>CONCURRENT</literal> option
<emphasis>is</emphasis> replicated when using row-based
replication. (Bug #34628)
Modified: trunk/refman-5.1/se-merge.xml
===================================================================
--- trunk/refman-5.1/se-merge.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.1/se-merge.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 3; 1057 bytes
@@ -471,9 +471,10 @@
buffers to find the next key. Only when one key buffer is used
up does the storage engine need to read the next key block. This
makes <literal>MERGE</literal> keys much slower on
- <literal role="jointype">eq_ref</literal> searches, but not much slower on
- <literal role="jointype">ref</literal> searches. See <xref linkend="explain"/>,
- for more information about <literal role="jointype">eq_ref</literal> and
+ <literal role="jointype">eq_ref</literal> searches, but not much
+ slower on <literal role="jointype">ref</literal> searches. See
+ <xref linkend="explain"/>, for more information about
+ <literal role="jointype">eq_ref</literal> and
<literal role="jointype">ref</literal>.
</para>
</listitem>
Modified: trunk/refman-5.1/sql-syntax-data-manipulation.xml
===================================================================
--- trunk/refman-5.1/sql-syntax-data-manipulation.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-5.1/sql-syntax-data-manipulation.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 2, Lines Added: 14, Lines Deleted: 12; 2617 bytes
@@ -4558,18 +4558,19 @@
</indexterm>
<literal>STRAIGHT_JOIN</literal> does not apply to any table
- that the optimizer treats as a <literal role="jointype">const</literal> or
- <literal role="jointype">system</literal> table. Such a table produces a
- single row, is read during the optimization phase of query
- execution, and references to its columns are replaced with the
- appropriate column values before query execution proceeds.
- These tables will appear first in the query plan displayed by
- <literal role="stmt">EXPLAIN</literal>. See
+ that the optimizer treats as a
+ <literal role="jointype">const</literal> or
+ <literal role="jointype">system</literal> table. Such a table
+ produces a single row, is read during the optimization phase
+ of query execution, and references to its columns are replaced
+ with the appropriate column values before query execution
+ proceeds. These tables will appear first in the query plan
+ displayed by <literal role="stmt">EXPLAIN</literal>. See
<xref linkend="using-explain"/>. This exception may not apply
- to <literal role="jointype">const</literal> or <literal role="jointype">system</literal>
- tables that are used on the
- <literal>NULL</literal>-complemented side of an outer join
- (that is, the right-side table of a <literal>LEFT
+ to <literal role="jointype">const</literal> or
+ <literal role="jointype">system</literal> tables that are used
+ on the <literal>NULL</literal>-complemented side of an outer
+ join (that is, the right-side table of a <literal>LEFT
JOIN</literal> or the left-side table of a <literal>RIGHT
JOIN</literal>.
</para>
@@ -7514,7 +7515,8 @@
MySQL replaces subqueries of the following form with an
index-lookup function, which
<literal role="stmt">EXPLAIN</literal> describes as a
- special join type (<literal role="jointype">unique_subquery</literal> or
+ special join type
+ (<literal role="jointype">unique_subquery</literal> or
<literal role="jointype">index_subquery</literal>):
</para>
Modified: trunk/refman-6.0/apis-c.xml
===================================================================
--- trunk/refman-6.0/apis-c.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-6.0/apis-c.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 6, Lines Added: 24, Lines Deleted: 18; 4806 bytes
@@ -1134,13 +1134,14 @@
</row>
<row>
<entry><literal role="cfunc">mysql_set_local_infile_default()</literal></entry>
- <entry>Set the <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> handler callbacks to
- their default values</entry>
+ <entry>Set the <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> handler callbacks to their default values</entry>
</row>
<row>
<entry><literal role="cfunc">mysql_set_local_infile_handler()</literal></entry>
- <entry>Install application-specific <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- handler callbacks</entry>
+ <entry>Install application-specific
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> handler callbacks</entry>
</row>
<row>
<entry><literal role="cfunc">mysql_set_server_option()</literal></entry>
@@ -5718,7 +5719,8 @@
</row>
<row>
<entry><literal>disable-local-infile</literal></entry>
- <entry>Disable use of <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal>.</entry>
+ <entry>Disable use of <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal>.</entry>
</row>
<row>
<entry><literal>host=<replaceable>host_name</replaceable></literal></entry>
@@ -5737,7 +5739,8 @@
</row>
<row>
<entry><literal>local-infile[={0|1}]</literal></entry>
- <entry>If no argument or non-zero argument, enable use of <literal role="stmt" condition="load-data">LOAD DATA
+ <entry>If no argument or non-zero argument, enable use of
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal>; otherwise disable.</entry>
</row>
<row>
@@ -6272,7 +6275,8 @@
</row>
<row>
<entry><literal>CLIENT_LOCAL_FILES</literal></entry>
- <entry>Enable <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> handling.</entry>
+ <entry>Enable <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> handling.</entry>
</row>
<row>
<entry><literal>CLIENT_MULTI_RESULTS</literal></entry>
@@ -7500,12 +7504,12 @@
<para>
This function installs callbacks to be used during the execution
- of <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> statements. It
- enables application programs to exert control over local
- (client-side) data file reading. The arguments are the
- connection handler, a set of pointers to callback functions, and
- a pointer to a data area that the callbacks can use to share
- information.
+ of <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statements. It enables application programs to
+ exert control over local (client-side) data file reading. The
+ arguments are the connection handler, a set of pointers to
+ callback functions, and a pointer to a data area that the
+ callbacks can use to share information.
</para>
<para>
@@ -7604,13 +7608,15 @@
After calling
<literal role="cfunc">mysql_set_local_infile_handler()</literal>
in your C code and passing pointers to your callback functions,
- you can then issue a <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- statement (for example, by using
+ you can then issue a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statement (for example, by using
<literal role="cfunc">mysql_query()</literal>). The client
library automatically invokes your callbacks. The filename
- specified in <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> will be
- passed as the second parameter to the
- <literal>local_infile_init()</literal> callback.
+ specified in <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL INFILE</literal> will be passed as the second
+ parameter to the <literal>local_infile_init()</literal>
+ callback.
</para>
<para>
Modified: trunk/refman-6.0/dba-security-core.xml
===================================================================
--- trunk/refman-6.0/dba-security-core.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-6.0/dba-security-core.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 7, Lines Added: 32, Lines Deleted: 25; 5541 bytes
@@ -1010,7 +1010,8 @@
<section id="load-data-local">
- <title>Security Issues with <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal></title>
+ <title>Security Issues with <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL</literal></title>
<para>
The <literal role="stmt">LOAD DATA</literal> statement can load a
@@ -1042,7 +1043,8 @@
<listitem>
<para>
In a Web environment where the clients are connecting from a
- Web server, a user could use <literal role="stmt" condition="load-data">LOAD DATA
+ Web server, a user could use
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> to read any files that the Web server process
has read access to (assuming that a user could run any command
against the SQL server). In this environment, the client with
@@ -1055,7 +1057,8 @@
</itemizedlist>
<para>
- To deal with these problems, we changed how <literal role="stmt" condition="load-data">LOAD DATA
+ To deal with these problems, we changed how
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> is handled as of MySQL 3.23.49 and MySQL 4.0.2
(4.0.13 on Windows):
</para>
@@ -1075,8 +1078,9 @@
<para>
If you build MySQL from source but do not invoke
<command>configure</command> with the
- <option>--enable-local-infile</option> option, <literal role="stmt" condition="load-data">LOAD
- DATA LOCAL</literal> cannot be used by any client unless it is
+ <option>--enable-local-infile</option> option,
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> cannot be used by any client unless it is
written explicitly to invoke
<literal role="cfunc">mysql_options(...
MYSQL_OPT_LOCAL_INFILE, 0)</literal>. See
@@ -1086,8 +1090,9 @@
<listitem>
<para>
- You can disable all <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal>
- commands from the server side by starting
+ You can disable all
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> commands from the server side by starting
<command>mysqld</command> with the
<option>--local-infile=0</option> option.
</para>
@@ -1096,26 +1101,27 @@
<listitem>
<para>
For the <command>mysql</command> command-line client,
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> can be enabled by
- specifying the <option>--local-infile[=1]</option> option, or
- disabled with the <option>--local-infile=0</option> option.
- Similarly, for <command>mysqlimport</command>, the
- <option>--local</option> or <option>-L</option> option enables
- local data file loading. In any case, successful use of a
- local loading operation requires that the server is enabled to
- allow it.
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL</literal> can be enabled by specifying the
+ <option>--local-infile[=1]</option> option, or disabled with
+ the <option>--local-infile=0</option> option. Similarly, for
+ <command>mysqlimport</command>, the <option>--local</option>
+ or <option>-L</option> option enables local data file loading.
+ In any case, successful use of a local loading operation
+ requires that the server is enabled to allow it.
</para>
</listitem>
<listitem>
<para>
- If you use <literal role="stmt" condition="load-data">LOAD DATA LOCAL</literal> in Perl scripts
- or other programs that read the <literal>[client]</literal>
- group from option files, you can add the
- <literal>local-infile=1</literal> option to that group.
- However, to keep this from causing problems for programs that
- do not understand <literal>local-infile</literal>, specify it
- using the <literal>loose-</literal> prefix:
+ If you use <literal role="stmt" condition="load-data">LOAD
+ DATA LOCAL</literal> in Perl scripts or other programs that
+ read the <literal>[client]</literal> group from option files,
+ you can add the <literal>local-infile=1</literal> option to
+ that group. However, to keep this from causing problems for
+ programs that do not understand
+ <literal>local-infile</literal>, specify it using the
+ <literal>loose-</literal> prefix:
</para>
<programlisting>
@@ -1126,9 +1132,10 @@
<listitem>
<para>
- If <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> is disabled,
- either in the server or the client, a client that attempts to
- issue such a statement receives the following error message:
+ If <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> is disabled, either in the server or the
+ client, a client that attempts to issue such a statement
+ receives the following error message:
</para>
<programlisting>
Modified: trunk/refman-6.0/optimization.xml
===================================================================
--- trunk/refman-6.0/optimization.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-6.0/optimization.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 35, Lines Added: 145, Lines Deleted: 117; 25710 bytes
@@ -962,7 +962,8 @@
<para>
The table has only one row (= system table). This is a
- special case of the <literal role="jointype">const</literal> join type.
+ special case of the
+ <literal role="jointype">const</literal> join type.
</para>
</listitem>
@@ -991,15 +992,15 @@
the start of the query. Because there is only one row,
values from the column in this row can be regarded as
constants by the rest of the optimizer.
- <literal role="jointype">const</literal> tables are very fast because
- they are read only once.
+ <literal role="jointype">const</literal> tables are very
+ fast because they are read only once.
</para>
<para>
- <literal role="jointype">const</literal> is used when you compare all
- parts of a <literal>PRIMARY KEY</literal> or
- <literal>UNIQUE</literal> index to constant values. In
- the following queries,
+ <literal role="jointype">const</literal> is used when
+ you compare all parts of a <literal>PRIMARY
+ KEY</literal> or <literal>UNIQUE</literal> index to
+ constant values. In the following queries,
<replaceable>tbl_name</replaceable> can be used as a
<literal role="jointype">const</literal> table:
</para>
@@ -1030,21 +1031,23 @@
<para>
One row is read from this table for each combination of
rows from the previous tables. Other than the
- <literal role="jointype">system</literal> and <literal role="jointype">const</literal>
- types, this is the best possible join type. It is used
- when all parts of an index are used by the join and the
- index is a <literal>PRIMARY KEY</literal> or
+ <literal role="jointype">system</literal> and
+ <literal role="jointype">const</literal> types, this is
+ the best possible join type. It is used when all parts
+ of an index are used by the join and the index is a
+ <literal>PRIMARY KEY</literal> or
<literal>UNIQUE</literal> index.
</para>
<para>
- <literal role="jointype">eq_ref</literal> can be used for indexed
- columns that are compared using the <literal>=</literal>
- operator. The comparison value can be a constant or an
- expression that uses columns from tables that are read
- before this table. In the following examples, MySQL can
- use an <literal role="jointype">eq_ref</literal> join to process
- <replaceable>ref_table</replaceable>:
+ <literal role="jointype">eq_ref</literal> can be used
+ for indexed columns that are compared using the
+ <literal>=</literal> operator. The comparison value can
+ be a constant or an expression that uses columns from
+ tables that are read before this table. In the following
+ examples, MySQL can use an
+ <literal role="jointype">eq_ref</literal> join to
+ process <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1075,9 +1078,9 @@
<para>
All rows with matching index values are read from this
table for each combination of rows from the previous
- tables. <literal role="jointype">ref</literal> is used if the join uses
- only a leftmost prefix of the key or if the key is not a
- <literal>PRIMARY KEY</literal> or
+ tables. <literal role="jointype">ref</literal> is used
+ if the join uses only a leftmost prefix of the key or if
+ the key is not a <literal>PRIMARY KEY</literal> or
<literal>UNIQUE</literal> index (in other words, if the
join cannot select a single row based on the key value).
If the key that is used matches only a few rows, this is
@@ -1089,11 +1092,12 @@
</remark>
<para>
- <literal role="jointype">ref</literal> can be used for indexed columns
- that are compared using the <literal>=</literal> or
- <literal><=></literal> operator. In the following
- examples, MySQL can use a <literal role="jointype">ref</literal> join to
- process <replaceable>ref_table</replaceable>:
+ <literal role="jointype">ref</literal> can be used for
+ indexed columns that are compared using the
+ <literal>=</literal> or <literal><=></literal>
+ operator. In the following examples, MySQL can use a
+ <literal role="jointype">ref</literal> join to process
+ <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1145,13 +1149,14 @@
</para>
<para>
- This join type is like <literal role="jointype">ref</literal>, but with
- the addition that MySQL does an extra search for rows
- that contain <literal>NULL</literal> values. This join
- type optimization is used most often in resolving
- subqueries. In the following examples, MySQL can use a
- <literal role="jointype">ref_or_null</literal> join to process
- <replaceable>ref_table</replaceable>:
+ This join type is like
+ <literal role="jointype">ref</literal>, but with the
+ addition that MySQL does an extra search for rows that
+ contain <literal>NULL</literal> values. This join type
+ optimization is used most often in resolving subqueries.
+ In the following examples, MySQL can use a
+ <literal role="jointype">ref_or_null</literal> join to
+ process <replaceable>ref_table</replaceable>:
</para>
<programlisting>
@@ -1206,7 +1211,8 @@
</para>
<para>
- This type replaces <literal role="jointype">ref</literal> for some
+ This type replaces
+ <literal role="jointype">ref</literal> for some
<literal>IN</literal> subqueries of the following form:
</para>
@@ -1215,9 +1221,9 @@
</programlisting>
<para>
- <literal role="jointype">unique_subquery</literal> is just an index
- lookup function that replaces the subquery completely
- for better efficiency.
+ <literal role="jointype">unique_subquery</literal> is
+ just an index lookup function that replaces the subquery
+ completely for better efficiency.
</para>
</listitem>
@@ -1238,9 +1244,10 @@
<para>
This join type is similar to
- <literal role="jointype">unique_subquery</literal>. It replaces
- <literal>IN</literal> subqueries, but it works for
- non-unique indexes in subqueries of the following form:
+ <literal role="jointype">unique_subquery</literal>. It
+ replaces <literal>IN</literal> subqueries, but it works
+ for non-unique indexes in subqueries of the following
+ form:
</para>
<programlisting>
@@ -1268,14 +1275,15 @@
an index to select the rows. The <literal>key</literal>
column in the output row indicates which index is used.
The <literal>key_len</literal> contains the longest key
- part that was used. The <literal role="jointype">ref</literal> column is
+ part that was used. The
+ <literal role="jointype">ref</literal> column is
<literal>NULL</literal> for this type.
</para>
<para>
- <literal role="jointype">range</literal> can be used when a key column
- is compared to a constant using any of the
- <literal role="op" condition="equal">=</literal>,
+ <literal role="jointype">range</literal> can be used
+ when a key column is compared to a constant using any of
+ the <literal role="op" condition="equal">=</literal>,
<literal role="op" condition="not-equal"><></literal>,
<literal role="op" condition="greater-than">></literal>,
<literal role="op" condition="greater-than-or-equal">>=</literal>,
@@ -1318,10 +1326,11 @@
</para>
<para>
- This join type is the same as <literal role="jointype_all">ALL</literal>,
- except that only the index tree is scanned. This usually
- is faster than <literal role="jointype_all">ALL</literal> because the index
- file usually is smaller than the data file.
+ This join type is the same as
+ <literal role="jointype_all">ALL</literal>, except that
+ only the index tree is scanned. This usually is faster
+ than <literal role="jointype_all">ALL</literal> because
+ the index file usually is smaller than the data file.
</para>
<para>
@@ -1351,7 +1360,8 @@
the table is the first table not marked
<literal role="jointype">const</literal>, and usually
<emphasis>very</emphasis> bad in all other cases.
- Normally, you can avoid <literal role="jointype_all">ALL</literal> by adding
+ Normally, you can avoid
+ <literal role="jointype_all">ALL</literal> by adding
indexes that allow row retrieval from the table based on
constant values or column values from earlier tables.
</para>
@@ -1466,9 +1476,10 @@
</para>
<para>
- The <literal role="jointype">ref</literal> column shows which columns or
- constants are compared to the index named in the
- <literal>key</literal> column to select rows from the table.
+ The <literal role="jointype">ref</literal> column shows
+ which columns or constants are compared to the index named
+ in the <literal>key</literal> column to select rows from the
+ table.
</para>
</listitem>
@@ -1547,9 +1558,11 @@
</para>
<para>
- MySQL has read all <literal role="jointype">const</literal> (and
- <literal role="jointype">system</literal>) tables and notice that the
- <literal>WHERE</literal> clause is always false.
+ MySQL has read all
+ <literal role="jointype">const</literal> (and
+ <literal role="jointype">system</literal>) tables and
+ notice that the <literal>WHERE</literal> clause is
+ always false.
</para>
</listitem>
@@ -1613,9 +1626,9 @@
tables are known. For each row combination in the
preceding tables, MySQL checks whether it is possible to
use a <literal role="jointype">range</literal> or
- <literal role="jointype">index_merge</literal> access method to retrieve
- rows. This is not very fast, but is faster than
- performing a join with no index at all. The
+ <literal role="jointype">index_merge</literal> access
+ method to retrieve rows. This is not very fast, but is
+ faster than performing a join with no index at all. The
applicability criteria are as described in
<xref linkend="range-optimization"/>, and
<xref linkend="index-merge-optimization"/>, with the
@@ -1756,7 +1769,8 @@
user-defined clustered index, that index can be used
even when <literal>Using index</literal> is absent from
the <literal>Extra</literal> column. This is the case if
- <literal>type</literal> is <literal role="jointype">index</literal> and
+ <literal>type</literal> is
+ <literal role="jointype">index</literal> and
<literal>key</literal> is <literal>PRIMARY</literal>.
</para>
</listitem>
@@ -1827,8 +1841,8 @@
<para>
These indicate how index scans are merged for the
- <literal role="jointype">index_merge</literal> join type. See
- <xref linkend="index-merge-optimization"/>.
+ <literal role="jointype">index_merge</literal> join
+ type. See <xref linkend="index-merge-optimization"/>.
</para>
</listitem>
@@ -1858,7 +1872,8 @@
examine all rows from the table, you may have something
wrong in your query if the <literal>Extra</literal>
value is not <literal>Using where</literal> and the
- table join type is <literal role="jointype_all">ALL</literal> or
+ table join type is
+ <literal role="jointype_all">ALL</literal> or
<literal role="jointype">index</literal>.
</para>
</listitem>
@@ -2025,14 +2040,15 @@
</programlisting>
<para>
- Because <literal>type</literal> is <literal role="jointype_all">ALL</literal> for
- each table, this output indicates that MySQL is generating a
- Cartesian product of all the tables; that is, every combination
- of rows. This takes quite a long time, because the product of
- the number of rows in each table must be examined. For the case
- at hand, this product is 74 × 2135 × 74 × 3872
- = 45,268,558,720 rows. If the tables were bigger, you can only
- imagine how long it would take.
+ Because <literal>type</literal> is
+ <literal role="jointype_all">ALL</literal> for each table, this
+ output indicates that MySQL is generating a Cartesian product of
+ all the tables; that is, every combination of rows. This takes
+ quite a long time, because the product of the number of rows in
+ each table must be examined. For the case at hand, this product
+ is 74 × 2135 × 74 × 3872 = 45,268,558,720
+ rows. If the tables were bigger, you can only imagine how long
+ it would take.
</para>
<para>
@@ -2596,12 +2612,12 @@
<title>Range Optimization</title>
<para>
- The <literal role="jointype">range</literal> access method uses a single index
- to retrieve a subset of table rows that are contained within one
- or several index value intervals. It can be used for a
- single-part or multiple-part index. The following sections give
- a detailed description of how intervals are extracted from the
- <literal>WHERE</literal> clause.
+ The <literal role="jointype">range</literal> access method uses
+ a single index to retrieve a subset of table rows that are
+ contained within one or several index value intervals. It can be
+ used for a single-part or multiple-part index. The following
+ sections give a detailed description of how intervals are
+ extracted from the <literal>WHERE</literal> clause.
</para>
<section id="range-access-single-part">
@@ -2681,7 +2697,8 @@
<listitem>
<para>
A column of a <literal role="jointype">const</literal> or
- <literal role="jointype">system</literal> table from the same join
+ <literal role="jointype">system</literal> table from the
+ same join
</para>
</listitem>
@@ -2854,8 +2871,8 @@
<para>
Currently, MySQL does not support merging multiple ranges for
- the <literal role="jointype">range</literal> access method for spatial
- indexes. To work around this limitation, you can use a
+ the <literal role="jointype">range</literal> access method for
+ spatial indexes. To work around this limitation, you can use a
<literal>UNION</literal> with identical
<literal role="stmt">SELECT</literal> statements, except that
you put each spatial predicate in a different
@@ -3123,8 +3140,9 @@
<para>
The <firstterm>Index Merge</firstterm> method is used to
- retrieve rows with several <literal role="jointype">range</literal> scans and to
- merge their results into one. The merge can produce unions,
+ retrieve rows with several
+ <literal role="jointype">range</literal> scans and to merge
+ their results into one. The merge can produce unions,
intersections, or unions-of-intersections of its underlying
scans. This access method merges index scans from a single
table; it does not merge scans across multiple tables.
@@ -3132,7 +3150,8 @@
<para>
In <literal role="stmt">EXPLAIN</literal> output, the Index
- Merge method appears as <literal role="jointype">index_merge</literal> in the
+ Merge method appears as
+ <literal role="jointype">index_merge</literal> in the
<literal>type</literal> column. In this case, the
<literal>key</literal> column contains a list of indexes used,
and <literal>key_len</literal> contains a list of the longest
@@ -3695,14 +3714,16 @@
<para>
Index Condition Pushdown optimization is used for the
- <literal role="jointype">range</literal>, <literal role="jointype">ref</literal>,
- <literal role="jointype">eq_ref</literal>, and <literal role="jointype">ref_or_null</literal>
- access methods when there is a need to access full table rows.
- The optimization is that the server tries to use index
- information to defer (<quote>push down</quote>) reading of full
- table rows unless it is known to be necessary. This is done by
- performing early tests on index tuples first. This strategy can
- be used for <literal>MyISAM</literal> tables.
+ <literal role="jointype">range</literal>,
+ <literal role="jointype">ref</literal>,
+ <literal role="jointype">eq_ref</literal>, and
+ <literal role="jointype">ref_or_null</literal> access methods
+ when there is a need to access full table rows. The optimization
+ is that the server tries to use index information to defer
+ (<quote>push down</quote>) reading of full table rows unless it
+ is known to be necessary. This is done by performing early tests
+ on index tuples first. This strategy can be used for
+ <literal>MyISAM</literal> tables.
</para>
<para>
@@ -4073,7 +4094,8 @@
<replaceable>col_name</replaceable> IS NULL</literal>, a form
that is common in resolved subqueries.
<literal role="stmt">EXPLAIN</literal> shows
- <literal role="jointype">ref_or_null</literal> when this optimization is used.
+ <literal role="jointype">ref_or_null</literal> when this
+ optimization is used.
</para>
<para>
@@ -4104,9 +4126,9 @@
</programlisting>
<para>
- <literal role="jointype">ref_or_null</literal> works by first doing a read on
- the reference key, and then a separate search for rows with a
- <literal>NULL</literal> key value.
+ <literal role="jointype">ref_or_null</literal> works by first
+ doing a read on the reference key, and then a separate search
+ for rows with a <literal>NULL</literal> key value.
</para>
<para>
@@ -5686,11 +5708,12 @@
clause, a loose index scan reads as many keys as the number of
groups, which may be a much smaller number than that of all
keys. If the <literal>WHERE</literal> clause contains range
- predicates (see the discussion of the <literal role="jointype">range</literal>
- join type in <xref linkend="using-explain"/>), a loose index
- scan looks up the first key of each group that satisfies the
- range conditions, and again reads the least possible number of
- keys. This is possible under the following conditions:
+ predicates (see the discussion of the
+ <literal role="jointype">range</literal> join type in
+ <xref linkend="using-explain"/>), a loose index scan looks up
+ the first key of each group that satisfies the range
+ conditions, and again reads the least possible number of keys.
+ This is possible under the following conditions:
</para>
<itemizedlist>
@@ -6154,10 +6177,11 @@
<para>
The <literal role="jointype">unique_subquery</literal> and
- <literal role="jointype">index_subquery</literal> subqery-specific access
- methods also have or-null variants. However, they are not
- visible in <literal role="stmt">EXPLAIN</literal> output, so you
- must use <literal>EXPLAIN EXTENDED</literal> followed by
+ <literal role="jointype">index_subquery</literal>
+ subqery-specific access methods also have or-null variants.
+ However, they are not visible in
+ <literal role="stmt">EXPLAIN</literal> output, so you must use
+ <literal>EXPLAIN EXTENDED</literal> followed by
<literal role="stmt">SHOW WARNINGS</literal> (note the
<literal>checking NULL</literal> in the warning message):
</para>
@@ -6377,8 +6401,9 @@
<literal>trigcond(<replaceable>X</replaceable>=<replaceable>Y</replaceable>
[OR <replaceable>Y</replaceable> IS NULL])</literal> can be
used to construct <literal role="jointype">ref</literal>,
- <literal role="jointype">eq_ref</literal>, or <literal role="jointype">ref_or_null</literal>
- table accesses.
+ <literal role="jointype">eq_ref</literal>, or
+ <literal role="jointype">ref_or_null</literal> table
+ accesses.
</para>
</listitem>
@@ -6386,8 +6411,9 @@
<para>
Index lookup-based subquery execution engines:
<literal>trigcond(<replaceable>X</replaceable>=<replaceable>Y</replaceable>)</literal>
- can be used to construct <literal role="jointype">unique_subquery</literal>
- or <literal role="jointype">index_subquery</literal> accesses.
+ can be used to construct
+ <literal role="jointype">unique_subquery</literal> or
+ <literal role="jointype">index_subquery</literal> accesses.
</para>
</listitem>
@@ -6637,9 +6663,10 @@
<para>
The output from <literal role="stmt">EXPLAIN</literal> shows
- <literal role="jointype_all">ALL</literal> in the <literal>type</literal> column
- when MySQL uses a table scan to resolve a query. This usually
- happens under the following conditions:
+ <literal role="jointype_all">ALL</literal> in the
+ <literal>type</literal> column when MySQL uses a table scan to
+ resolve a query. This usually happens under the following
+ conditions:
</para>
<itemizedlist>
@@ -10788,9 +10815,9 @@
<replaceable>expr2</replaceable></literal> is not true when
<replaceable>expr1</replaceable> or
<replaceable>expr2</replaceable> (or both) are
- <literal>NULL</literal>. This affects <literal role="jointype">ref</literal>
- accesses for comparisons of the form
- <literal><replaceable>tbl_name.key</replaceable> =
+ <literal>NULL</literal>. This affects
+ <literal role="jointype">ref</literal> accesses for comparisons
+ of the form <literal><replaceable>tbl_name.key</replaceable> =
<replaceable>expr</replaceable></literal>: MySQL will not access
the table if the current value of
<replaceable>expr</replaceable> is <literal>NULL</literal>,
@@ -10832,8 +10859,9 @@
useful than it really is for joins that look for
non-<literal>NULL</literal> values. Consequently, the
<literal>nulls_equal</literal> method may cause the
- optimizer not to use the index for <literal role="jointype">ref</literal>
- accesses when it should.
+ optimizer not to use the index for
+ <literal role="jointype">ref</literal> accesses when it
+ should.
</para>
</listitem>
@@ -10855,8 +10883,8 @@
index for joins that look for non-<literal>NULL</literal>
values. Consequently, the <literal>nulls_unequal</literal>
method may cause the optimizer to use this index for
- <literal role="jointype">ref</literal> lookups when other methods may be
- better.
+ <literal role="jointype">ref</literal> lookups when other
+ methods may be better.
</para>
</listitem>
Modified: trunk/refman-6.0/programs-admin-util-core.xml
===================================================================
--- trunk/refman-6.0/programs-admin-util-core.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-6.0/programs-admin-util-core.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 2, Lines Added: 9, Lines Deleted: 6; 2160 bytes
@@ -4677,17 +4677,19 @@
reproduces a <literal role="stmt" condition="load-data">LOAD
DATA INFILE</literal> operation without the original data file.
<command>mysqlbinlog</command> copies the data to a temporary
- file and writes a <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
- statement that refers to the file. The default location of the
- directory where these files are written is system-specific. To
- specify a directory explicitly, use the
+ file and writes a
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statement that refers to the file. The default
+ location of the directory where these files are written is
+ system-specific. To specify a directory explicitly, use the
<option>--local-load</option> option.
</para>
<para>
Because <command>mysqlbinlog</command> converts
<literal role="stmt" condition="load-data">LOAD DATA
- INFILE</literal> statements to <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> statements to
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal> statements (that is, it adds
<literal>LOCAL</literal>), both the client and the server that
you use to process the statements must be configured to allow
@@ -4710,7 +4712,8 @@
<warning>
<para>
- The temporary files created for <literal role="stmt" condition="load-data">LOAD DATA
+ The temporary files created for
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL</literal> statements are <emphasis>not</emphasis>
automatically deleted because they are needed until you
actually execute those statements. You should delete the
Modified: trunk/refman-6.0/replication-notes.xml
===================================================================
--- trunk/refman-6.0/replication-notes.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-6.0/replication-notes.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 836 bytes
@@ -1444,7 +1444,8 @@
INFILE</literal> is replicated as
<literal role="stmt" condition="load-data">LOAD DATA
INFILE</literal>, and <literal>LOAD DATA CONCURRENT LOCAL
- INFILE</literal> is replicated as <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal> is replicated as
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
INFILE</literal>. The <literal>CONCURRENT</literal> option
<emphasis>is</emphasis> replicated when using row-based
replication. (Bug #34628)
Modified: trunk/refman-6.0/se-merge.xml
===================================================================
--- trunk/refman-6.0/se-merge.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-6.0/se-merge.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 4, Lines Deleted: 3; 1057 bytes
@@ -469,9 +469,10 @@
buffers to find the next key. Only when one key buffer is used
up does the storage engine need to read the next key block. This
makes <literal>MERGE</literal> keys much slower on
- <literal role="jointype">eq_ref</literal> searches, but not much slower on
- <literal role="jointype">ref</literal> searches. See <xref linkend="explain"/>,
- for more information about <literal role="jointype">eq_ref</literal> and
+ <literal role="jointype">eq_ref</literal> searches, but not much
+ slower on <literal role="jointype">ref</literal> searches. See
+ <xref linkend="explain"/>, for more information about
+ <literal role="jointype">eq_ref</literal> and
<literal role="jointype">ref</literal>.
</para>
</listitem>
Modified: trunk/refman-6.0/sql-syntax-data-manipulation.xml
===================================================================
--- trunk/refman-6.0/sql-syntax-data-manipulation.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-6.0/sql-syntax-data-manipulation.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 2, Lines Added: 14, Lines Deleted: 12; 2617 bytes
@@ -5143,18 +5143,19 @@
</indexterm>
<literal>STRAIGHT_JOIN</literal> does not apply to any table
- that the optimizer treats as a <literal role="jointype">const</literal> or
- <literal role="jointype">system</literal> table. Such a table produces a
- single row, is read during the optimization phase of query
- execution, and references to its columns are replaced with the
- appropriate column values before query execution proceeds.
- These tables will appear first in the query plan displayed by
- <literal role="stmt">EXPLAIN</literal>. See
+ that the optimizer treats as a
+ <literal role="jointype">const</literal> or
+ <literal role="jointype">system</literal> table. Such a table
+ produces a single row, is read during the optimization phase
+ of query execution, and references to its columns are replaced
+ with the appropriate column values before query execution
+ proceeds. These tables will appear first in the query plan
+ displayed by <literal role="stmt">EXPLAIN</literal>. See
<xref linkend="using-explain"/>. This exception may not apply
- to <literal role="jointype">const</literal> or <literal role="jointype">system</literal>
- tables that are used on the
- <literal>NULL</literal>-complemented side of an outer join
- (that is, the right-side table of a <literal>LEFT
+ to <literal role="jointype">const</literal> or
+ <literal role="jointype">system</literal> tables that are used
+ on the <literal>NULL</literal>-complemented side of an outer
+ join (that is, the right-side table of a <literal>LEFT
JOIN</literal> or the left-side table of a <literal>RIGHT
JOIN</literal>.
</para>
@@ -8105,7 +8106,8 @@
MySQL replaces subqueries of the following form with an
index-lookup function, which
<literal role="stmt">EXPLAIN</literal> describes as a
- special join type (<literal role="jointype">unique_subquery</literal> or
+ special join type
+ (<literal role="jointype">unique_subquery</literal> or
<literal role="jointype">index_subquery</literal>):
</para>
Modified: trunk/refman-common/connector-j.xml
===================================================================
--- trunk/refman-common/connector-j.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-common/connector-j.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 2, Lines Added: 13, Lines Deleted: 9; 2573 bytes
@@ -1703,20 +1703,23 @@
<function>setLocalInfileInputStream()</function> sets an
<literal>InputStream</literal> instance that will be
used to send data to the MySQL server for a
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> statement
- rather than a <literal>FileInputStream</literal> or
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL INFILE</literal> statement rather than a
+ <literal>FileInputStream</literal> or
<literal>URLInputStream</literal> that represents the
path given as an argument to the statement.
</para>
<para>
This stream will be read to completion upon execution of
- a <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal> statement,
- and will automatically be closed by the driver, so it
- needs to be reset before each call to
- <literal>execute*()</literal> that would cause the MySQL
- server to request data to fulfill the request for
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>.
+ a <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL INFILE</literal> statement, and will automatically
+ be closed by the driver, so it needs to be reset before
+ each call to <literal>execute*()</literal> that would
+ cause the MySQL server to request data to fulfill the
+ request for
+ <literal role="stmt" condition="load-data">LOAD DATA
+ LOCAL INFILE</literal>.
</para>
<para>
@@ -1731,7 +1734,8 @@
<para>
<function>getLocalInfileInputStream()</function> returns
the <literal>InputStream</literal> instance that will be
- used to send data in response to a <literal role="stmt" condition="load-data">LOAD DATA
+ used to send data in response to a
+ <literal role="stmt" condition="load-data">LOAD DATA
LOCAL INFILE</literal> statement.
</para>
Modified: trunk/refman-common/connector-net.xml
===================================================================
--- trunk/refman-common/connector-net.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-common/connector-net.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 689 bytes
@@ -13776,8 +13776,8 @@
<listitem>
<para>
- <literal role="jointype">index</literal>: The zero-based index
- of the parameter.
+ <literal role="jointype">index</literal>: The
+ zero-based index of the parameter.
</para>
</listitem>
Modified: trunk/refman-common/credits.xml
===================================================================
--- trunk/refman-common/credits.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-common/credits.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 547 bytes
@@ -268,7 +268,8 @@
<listitem>
<para>
- <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal>
</para>
</listitem>
Modified: trunk/refman-common/news-cnet-core.xml
===================================================================
--- trunk/refman-common/news-cnet-core.xml 2009-01-13 19:47:58 UTC (rev 13145)
+++ trunk/refman-common/news-cnet-core.xml 2009-01-13 19:48:09 UTC (rev 13146)
Changed blocks: 1, Lines Added: 3, Lines Deleted: 1; 592 bytes
@@ -445,7 +445,9 @@
<listitem>
<para>
- Added test case for <literal role="stmt" condition="load-data">LOAD DATA LOCAL INFILE</literal>.
+ Added test case for
+ <literal role="stmt" condition="load-data">LOAD DATA LOCAL
+ INFILE</literal>.
</para>
</listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r13146 - in trunk: . dynamic-docs/changelog refman-4.1 refman-5.0 refman-5.1 refman-6.0 refman-common | paul.dubois | 13 Jan |
