Author: paul
Date: 2006-03-22 19:01:41 +0100 (Wed, 22 Mar 2006)
New Revision: 1644
Log:
r8880@frost: paul | 2006-03-22 12:01:22 -0600
Fold in proof corrections.
Modified:
trunk/
trunk/refman-4.1/optimization.xml
trunk/refman-5.0/optimization.xml
trunk/refman-5.1/optimization.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:8875
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:4044
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:8880
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:4044
Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml 2006-03-22 17:44:21 UTC (rev 1643)
+++ trunk/refman-4.1/optimization.xml 2006-03-22 18:01:41 UTC (rev 1644)
@@ -359,8 +359,8 @@
<para>
This system worked well and we had no problems handling the data
- with quite modest Sun Ultra SPARCstation hardware (2x200MHz).
- Eventually the system was migrated to Linux.
+ with quite modest Sun Ultra SPARCstation hardware
+ (2×200MHz). Eventually the system was migrated to Linux.
</para>
</section>
@@ -1760,7 +1760,7 @@
pointer is usually four bytes. For a 500,000-row table with an
index length of three bytes (the size of
<literal>MEDIUMINT</literal>), the formula indicates
- <literal>log(500,000)/log(1024/3*2/(3+4)) + 1</literal> =
+ <literal>log(500,000)/log(1024/3×2/(3+4)) + 1</literal> =
<literal>4</literal> seeks.
</para>
@@ -1848,8 +1848,8 @@
(assuming that you want to sort on index 1). This is a good
way to make queries faster if you have a unique index from
which you want to read all rows in order according to the
- index. Note that the first time you sort a large table this
- way, it may take a long time.
+ index. The first time you sort a large table this way, it
+ may take a long time.
</para>
</listitem>
@@ -3487,7 +3487,8 @@
This can be useful for checking the validity of a query.
When using one of the MySQL APIs, it can also be employed
for obtaining the types of the result columns. (This trick
- does not work in the MySQL Monitor, which merely displays
+ does not work in the MySQL Monitor (the
+ <command>mysql</command> program), which merely displays
<literal>Empty set</literal> in such cases; you should
instead use <literal>SHOW COLUMNS</literal> or
<literal>DESCRIBE</literal> for this purpose.)
@@ -3832,13 +3833,15 @@
<listitem>
<para>
To speed up <literal>INSERT</literal> operations that are
- performed with multiple statements, lock your tables:
+ performed with multiple statements for non-transactional
+ tables, lock your tables:
</para>
<programlisting>
LOCK TABLES a WRITE;
INSERT INTO a VALUES (1,23),(2,34),(4,33);
INSERT INTO a VALUES (8,26),(6,29);
+...
UNLOCK TABLES;
</programlisting>
@@ -3853,10 +3856,10 @@
</para>
<para>
- For transactional tables, you should use <literal>START
- TRANSACTION</literal> and <literal>COMMIT</literal> instead
- of <literal>LOCK TABLES</literal> to obtain faster
- insertions.
+ To obtain faster insertions, for transactional tables, you
+ should use <literal>START TRANSACTION</literal> and
+ <literal>COMMIT</literal> instead of <literal>LOCK
+ TABLES</literal>.
</para>
<para>
@@ -4718,7 +4721,8 @@
<literal>GET_LOCK()</literal> and
<literal>RELEASE_LOCK()</literal> in MySQL. These are
advisory locks, so they work only in well-behaved
- applications.
+ applications. (See
+ <xref linkend="miscellaneous-functions"/>.)
</para>
</listitem>
@@ -4901,7 +4905,8 @@
with <literal>SELECT</literal>, you might want to consider
switching to <literal>MyISAM</literal> tables, which support
concurrent <literal>SELECT</literal> and
- <literal>INSERT</literal> statements.
+ <literal>INSERT</literal> statements. (See
+ <xref linkend="concurrent-inserts"/>.)
</para>
</listitem>
@@ -5002,8 +5007,8 @@
<para>
Under circumstances where concurrent inserts can be used, there
is seldom any need to use the <literal>DELAYED</literal>
- modifier for <literal>INSERT</literal> statements.
- See <xref linkend="insert-delayed"/>.
+ modifier for <literal>INSERT</literal> statements. See
+ <xref linkend="insert-delayed"/>.
</para>
<para>
@@ -5402,8 +5407,8 @@
<programlisting>
CREATE TABLE test (
- id INT NOT NULL,
- last_name CHAR(30) NOT NULL,
+ id INT NOT NULL,
+ last_name CHAR(30) NOT NULL,
first_name CHAR(30) NOT NULL,
PRIMARY KEY (id),
INDEX name (last_name,first_name)
@@ -5843,8 +5848,8 @@
<para>
To minimize disk I/O, the <literal>MyISAM</literal> storage
- engine employs a strategy that is used by many database
- management systems. It exploits a cache mechanism to keep the
+ engine exploits a strategy that is used by many database
+ management systems. It employs a cache mechanism to keep the
most frequently accessed table blocks in memory:
</para>
@@ -6096,7 +6101,7 @@
<programlisting>
mysql> <userinput>SET GLOBAL key_buffer_size = 0;</userinput>
-mysql> <userinput>show variables like 'key_buffer_size';</userinput>
+mysql> <userinput>SHOW VARIABLES LIKE 'key_buffer_size';</userinput>
+-----------------+---------+
| Variable_name | Value |
+-----------------+---------+
@@ -6216,7 +6221,7 @@
key_buffer_size = 4G
hot_cache.key_buffer_size = 2G
cold_cache.key_buffer_size = 2G
-init_file=/path/to/data-directory/mysqld_init.sql
+init_file=/<replaceable>path</replaceable>/<replaceable>to</replaceable>/<replaceable>data-directory</replaceable>/mysqld_init.sql
</programlisting>
<para>
@@ -6440,8 +6445,8 @@
server destroys the cache's old structure and creates a new
one based on the new values. If the cache contains any dirty
blocks, the server saves them to disk before destroying and
- re-creating the cache. Restructuring does not occur if you set
- other key cache parameters.
+ re-creating the cache. Restructuring does not occur if you
+ change other key cache parameters.
</para>
<para>
@@ -6552,7 +6557,7 @@
For <literal>=</literal> comparisons, it does not matter how
many <literal>NULL</literal> values are in the table. For
optimization purposes, the relevant value is the average size of
- the non-<literal>NULL</literal> values groups. However, MySQL
+ the non-<literal>NULL</literal> value groups. However, MySQL
does not currently allow that average size to be collected or
used.
</para>
@@ -6671,34 +6676,44 @@
<literal>myisam_stats_method</literal>:
</para>
- <para>
- You can force table statistics to be collected explicitly, as
- just described. However, MySQL may also collect statistics
- automatically. For example, if during the course of executing
- statements for a table, some of those statements modify the
- table, MySQL may collect statistics. (This may occur for bulk
- inserts or deletes, or some <literal>ALTER TABLE</literal>
- statements, for example.) If this happens, the statistics are
- collected using whatever value
- <literal>myisam_stats_method</literal> has at the time. Thus, if
- you collect statistics using one method, but
- <literal>myisam_stats_method</literal> is set to the other
- method when a table's statistics are collected automatically
- later, the other method will be used.
- </para>
+ <itemizedlist>
- <para>
- There is no way to tell which method was used to generate
- statistics for a given <literal>MyISAM</literal> table.
- </para>
+ <listitem>
+ <para>
+ You can force table statistics to be collected explicitly,
+ as just described. However, MySQL may also collect
+ statistics automatically. For example, if during the course
+ of executing statements for a table, some of those
+ statements modify the table, MySQL may collect statistics.
+ (This may occur for bulk inserts or deletes, or some
+ <literal>ALTER TABLE</literal> statements, for example.) If
+ this happens, the statistics are collected using whatever
+ value <literal>myisam_stats_method</literal> has at the
+ time. Thus, if you collect statistics using one method, but
+ <literal>myisam_stats_method</literal> is set to the other
+ method when a table's statistics are collected automatically
+ later, the other method will be used.
+ </para>
+ </listitem>
- <para>
- <literal>myisam_stats_method</literal> applies only to
- <literal>MyISAM</literal> tables. Other storage engines have
- only one method for collecting table statistics. Usually it is
- closer to the <literal>nulls_equal</literal> method.
- </para>
+ <listitem>
+ <para>
+ There is no way to tell which method was used to generate
+ statistics for a given <literal>MyISAM</literal> table.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>myisam_stats_method</literal> applies only to
+ <literal>MyISAM</literal> tables. Other storage engines have
+ only one method for collecting table statistics. Usually it
+ is closer to the <literal>nulls_equal</literal> method.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
</section>
<section id="table-cache">
@@ -6806,7 +6821,7 @@
two file descriptors for each unique open table. You can
increase the number of file descriptors available to MySQL using
the <option>--open-files-limit</option> startup option to
- <command>mysqld_safe</command>. See
+ <command>mysqld</command>. See
<xref linkend="not-enough-file-handles"/>.
</para>
@@ -7162,7 +7177,7 @@
</programlisting>
<para>
- If there is a <command>mysqld</command> server currently
+ For a <command>mysqld</command> server that is currently
running, you can see the current values of its system variables
by connecting to it and issuing this statement:
</para>
@@ -7191,7 +7206,7 @@
</programlisting>
<para>
- For a full description for all system and status variables, see
+ For a full description of all system and status variables, see
<xref linkend="server-system-variables"/>, and
<xref linkend="server-status-variables"/>.
</para>
@@ -8353,7 +8368,7 @@
<listitem>
<para>
<literal>ALTER</literal> statements on
- <literal>tbl2</literal> also fail.
+ <literal>tbl2</literal> fail.
</para>
</listitem>
@@ -8404,7 +8419,7 @@
</para>
<para>
- On Windows, you create a symbolic link to a MySQL database by
+ On Windows, create a symbolic link to a MySQL database by
creating a file in the data directory that contains the path
to the destination directory. The file should be named
<filename><replaceable>db_name</replaceable>.sym</filename>,
Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml 2006-03-22 17:44:21 UTC (rev 1643)
+++ trunk/refman-5.0/optimization.xml 2006-03-22 18:01:41 UTC (rev 1644)
@@ -359,8 +359,8 @@
<para>
This system worked well and we had no problems handling the data
- with quite modest Sun Ultra SPARCstation hardware (2x200MHz).
- Eventually the system was migrated to Linux.
+ with quite modest Sun Ultra SPARCstation hardware
+ (2×200MHz). Eventually the system was migrated to Linux.
</para>
</section>
@@ -1598,7 +1598,7 @@
<para>
Condition pushdown, <literal>Using where with pushed
condition</literal>, and
- <option>engine-condition-pushdown</option> were all
+ <option>engine_condition_pushdown</option> were all
introduced in MySQL 5.0 Cluster.
</para>
</listitem>
@@ -1927,7 +1927,7 @@
pointer is usually four bytes. For a 500,000-row table with an
index length of three bytes (the size of
<literal>MEDIUMINT</literal>), the formula indicates
- <literal>log(500,000)/log(1024/3*2/(3+4)) + 1</literal> =
+ <literal>log(500,000)/log(1024/3×2/(3+4)) + 1</literal> =
<literal>4</literal> seeks.
</para>
@@ -2016,8 +2016,8 @@
(assuming that you want to sort on index 1). This is a good
way to make queries faster if you have a unique index from
which you want to read all rows in order according to the
- index. Note that the first time you sort a large table this
- way, it may take a long time.
+ index. The first time you sort a large table this way, it
+ may take a long time.
</para>
</listitem>
@@ -3535,21 +3535,21 @@
<listitem>
<para>
Table <literal>t1</literal> contains rows
- <literal>{1}</literal>, <literal>{2}</literal>
+ <literal>(1)</literal>, <literal>(2)</literal>
</para>
</listitem>
<listitem>
<para>
Table <literal>t2</literal> contains row
- <literal>{1,101}</literal>
+ <literal>(1,101)</literal>
</para>
</listitem>
<listitem>
<para>
Table <literal>t3</literal> contains row
- <literal>{101}</literal>
+ <literal>(101)</literal>
</para>
</listitem>
@@ -3557,10 +3557,10 @@
<para>
In this case, the first expression returns a result set
- including the rows <literal>{1,1,101,101}</literal>,
- <literal>{2,NULL,NULL,NULL}</literal>, whereas the second
- expression returns the rows <literal>{1,1,101,101}</literal>,
- <literal>{2,NULL,NULL,101}</literal>:
+ including the rows <literal>(1,1,101,101)</literal>,
+ <literal>(2,NULL,NULL,NULL)</literal>, whereas the second
+ expression returns the rows <literal>(1,1,101,101)</literal>,
+ <literal>(2,NULL,NULL,101)</literal>:
</para>
<programlisting>
@@ -3989,7 +3989,7 @@
For a query with outer joins, the <literal>WHERE</literal>
condition is to be checked only after it has been found that the
current row from the outer table has a match in the inner
- tables. Thus, the optimization with pushing condition out of the
+ tables. Thus, the optimization of pushing conditions out of the
inner nested loops cannot be applied directly to queries with
outer joins. Here we have to introduce conditional pushed-down
predicates guarded by the flags that are turned on when a match
@@ -4073,7 +4073,7 @@
<programlisting>
(T1, ...) RIGHT JOIN (T2,...) ON P(T1,...,T2,...) =
-(T2, ...) LEFT JOIN (T1,...) ON P(T1,...,T2,...).
+(T2, ...) LEFT JOIN (T1,...) ON P(T1,...,T2,...)
</programlisting>
<para>
@@ -4326,9 +4326,8 @@
<para>
the <literal>WHERE</literal> condition is not null-rejected for
the embedded outer join, but the join condition of the embedding
- outer join <literal>T2.A=T1.A</literal> AND
- <literal>T3.C=T1.C</literal> is null-rejected. So the query can
- be converted to:
+ outer join <literal>T2.A=T1.A AND T3.C=T1.C</literal> is
+ null-rejected. So the query can be converted to:
</para>
<programlisting>
@@ -4945,7 +4944,8 @@
This can be useful for checking the validity of a query.
When using one of the MySQL APIs, it can also be employed
for obtaining the types of the result columns. (This trick
- does not work in the MySQL Monitor, which merely displays
+ does not work in the MySQL Monitor (the
+ <command>mysql</command> program), which merely displays
<literal>Empty set</literal> in such cases; you should
instead use <literal>SHOW COLUMNS</literal> or
<literal>DESCRIBE</literal> for this purpose.)
@@ -5290,13 +5290,15 @@
<listitem>
<para>
To speed up <literal>INSERT</literal> operations that are
- performed with multiple statements, lock your tables:
+ performed with multiple statements for non-transactional
+ tables, lock your tables:
</para>
<programlisting>
LOCK TABLES a WRITE;
INSERT INTO a VALUES (1,23),(2,34),(4,33);
INSERT INTO a VALUES (8,26),(6,29);
+...
UNLOCK TABLES;
</programlisting>
@@ -5311,10 +5313,10 @@
</para>
<para>
- For transactional tables, you should use <literal>START
- TRANSACTION</literal> and <literal>COMMIT</literal> instead
- of <literal>LOCK TABLES</literal> to obtain faster
- insertions.
+ To obtain faster insertions, for transactional tables, you
+ should use <literal>START TRANSACTION</literal> and
+ <literal>COMMIT</literal> instead of <literal>LOCK
+ TABLES</literal>.
</para>
<para>
@@ -6174,7 +6176,8 @@
<literal>GET_LOCK()</literal> and
<literal>RELEASE_LOCK()</literal> in MySQL. These are
advisory locks, so they work only in well-behaved
- applications.
+ applications. (See
+ <xref linkend="miscellaneous-functions"/>.)
</para>
</listitem>
@@ -6356,7 +6359,8 @@
with <literal>SELECT</literal>, you might want to consider
switching to <literal>MyISAM</literal> tables, which support
concurrent <literal>SELECT</literal> and
- <literal>INSERT</literal> statements.
+ <literal>INSERT</literal> statements. (See
+ <xref linkend="concurrent-inserts"/>.)
</para>
</listitem>
@@ -6457,8 +6461,8 @@
<para>
Under circumstances where concurrent inserts can be used, there
is seldom any need to use the <literal>DELAYED</literal>
- modifier for <literal>INSERT</literal> statements.
- See <xref linkend="insert-delayed"/>.
+ modifier for <literal>INSERT</literal> statements. See
+ <xref linkend="insert-delayed"/>.
</para>
<para>
@@ -6895,8 +6899,8 @@
<programlisting>
CREATE TABLE test (
- id INT NOT NULL,
- last_name CHAR(30) NOT NULL,
+ id INT NOT NULL,
+ last_name CHAR(30) NOT NULL,
first_name CHAR(30) NOT NULL,
PRIMARY KEY (id),
INDEX name (last_name,first_name)
@@ -7334,8 +7338,8 @@
<para>
To minimize disk I/O, the <literal>MyISAM</literal> storage
- engine employs a strategy that is used by many database
- management systems. It exploits a cache mechanism to keep the
+ engine exploits a strategy that is used by many database
+ management systems. It employs a cache mechanism to keep the
most frequently accessed table blocks in memory:
</para>
@@ -7558,7 +7562,7 @@
<programlisting>
mysql> <userinput>SET GLOBAL key_buffer_size = 0;</userinput>
-mysql> <userinput>show variables like 'key_buffer_size';</userinput>
+mysql> <userinput>SHOW VARIABLES LIKE 'key_buffer_size';</userinput>
+-----------------+---------+
| Variable_name | Value |
+-----------------+---------+
@@ -7678,7 +7682,7 @@
key_buffer_size = 4G
hot_cache.key_buffer_size = 2G
cold_cache.key_buffer_size = 2G
-init_file=/path/to/data-directory/mysqld_init.sql
+init_file=/<replaceable>path</replaceable>/<replaceable>to</replaceable>/<replaceable>data-directory</replaceable>/mysqld_init.sql
</programlisting>
<para>
@@ -7901,8 +7905,8 @@
server destroys the cache's old structure and creates a new
one based on the new values. If the cache contains any dirty
blocks, the server saves them to disk before destroying and
- re-creating the cache. Restructuring does not occur if you set
- other key cache parameters.
+ re-creating the cache. Restructuring does not occur if you
+ change other key cache parameters.
</para>
<para>
@@ -8013,7 +8017,7 @@
For <literal>=</literal> comparisons, it does not matter how
many <literal>NULL</literal> values are in the table. For
optimization purposes, the relevant value is the average size of
- the non-<literal>NULL</literal> values groups. However, MySQL
+ the non-<literal>NULL</literal> value groups. However, MySQL
does not currently allow that average size to be collected or
used.
</para>
@@ -8132,34 +8136,44 @@
<literal>myisam_stats_method</literal>:
</para>
- <para>
- You can force table statistics to be collected explicitly, as
- just described. However, MySQL may also collect statistics
- automatically. For example, if during the course of executing
- statements for a table, some of those statements modify the
- table, MySQL may collect statistics. (This may occur for bulk
- inserts or deletes, or some <literal>ALTER TABLE</literal>
- statements, for example.) If this happens, the statistics are
- collected using whatever value
- <literal>myisam_stats_method</literal> has at the time. Thus, if
- you collect statistics using one method, but
- <literal>myisam_stats_method</literal> is set to the other
- method when a table's statistics are collected automatically
- later, the other method will be used.
- </para>
+ <itemizedlist>
- <para>
- There is no way to tell which method was used to generate
- statistics for a given <literal>MyISAM</literal> table.
- </para>
+ <listitem>
+ <para>
+ You can force table statistics to be collected explicitly,
+ as just described. However, MySQL may also collect
+ statistics automatically. For example, if during the course
+ of executing statements for a table, some of those
+ statements modify the table, MySQL may collect statistics.
+ (This may occur for bulk inserts or deletes, or some
+ <literal>ALTER TABLE</literal> statements, for example.) If
+ this happens, the statistics are collected using whatever
+ value <literal>myisam_stats_method</literal> has at the
+ time. Thus, if you collect statistics using one method, but
+ <literal>myisam_stats_method</literal> is set to the other
+ method when a table's statistics are collected automatically
+ later, the other method will be used.
+ </para>
+ </listitem>
- <para>
- <literal>myisam_stats_method</literal> applies only to
- <literal>MyISAM</literal> tables. Other storage engines have
- only one method for collecting table statistics. Usually it is
- closer to the <literal>nulls_equal</literal> method.
- </para>
+ <listitem>
+ <para>
+ There is no way to tell which method was used to generate
+ statistics for a given <literal>MyISAM</literal> table.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>myisam_stats_method</literal> applies only to
+ <literal>MyISAM</literal> tables. Other storage engines have
+ only one method for collecting table statistics. Usually it
+ is closer to the <literal>nulls_equal</literal> method.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
</section>
<section id="table-cache">
@@ -8267,7 +8281,7 @@
two file descriptors for each unique open table. You can
increase the number of file descriptors available to MySQL using
the <option>--open-files-limit</option> startup option to
- <command>mysqld_safe</command>. See
+ <command>mysqld</command>. See
<xref linkend="not-enough-file-handles"/>.
</para>
@@ -8694,7 +8708,7 @@
</programlisting>
<para>
- If there is a <command>mysqld</command> server currently
+ For a <command>mysqld</command> server that is currently
running, you can see the current values of its system variables
by connecting to it and issuing this statement:
</para>
@@ -8723,7 +8737,7 @@
</programlisting>
<para>
- For a full description for all system and status variables, see
+ For a full description of all system and status variables, see
<xref linkend="server-system-variables"/>, and
<xref linkend="server-status-variables"/>.
</para>
@@ -8884,7 +8898,7 @@
possible plans investigated by the MySQL optimizer grows
exponentially with the number of tables referenced in a query.
For small numbers of tables (typically less than 7−10)
- this is not a problem. However, when bigger queries are
+ this is not a problem. However, when larger queries are
submitted, the time spent in query optimization may easily
become the major bottleneck in the server's performance.
</para>
@@ -8937,7 +8951,7 @@
<literal>optimizer_search_depth</literal> is close to the
number of tables in the query. At the same time, if compiled
with <literal>optimizer_search_depth</literal> equal to 3 or
- 4, the compiler may compile in less than a minute for the
+ 4, the optimizer may compile in less than a minute for the
same query. If you are unsure of what a reasonable value is
for <literal>optimizer_search_depth</literal>, this variable
can be set to 0 to tell the optimizer to determine the value
@@ -9896,7 +9910,7 @@
<listitem>
<para>
<literal>ALTER</literal> statements on
- <literal>tbl2</literal> also fail.
+ <literal>tbl2</literal> fail.
</para>
</listitem>
@@ -9935,7 +9949,7 @@
</para>
<para>
- On Windows, you create a symbolic link to a MySQL database by
+ On Windows, create a symbolic link to a MySQL database by
creating a file in the data directory that contains the path
to the destination directory. The file should be named
<filename><replaceable>db_name</replaceable>.sym</filename>,
Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml 2006-03-22 17:44:21 UTC (rev 1643)
+++ trunk/refman-5.1/optimization.xml 2006-03-22 18:01:41 UTC (rev 1644)
@@ -359,8 +359,8 @@
<para>
This system worked well and we had no problems handling the data
- with quite modest Sun Ultra SPARCstation hardware (2x200MHz).
- Eventually the system was migrated to Linux.
+ with quite modest Sun Ultra SPARCstation hardware
+ (2×200MHz). Eventually the system was migrated to Linux.
</para>
</section>
@@ -1958,7 +1958,7 @@
pointer is usually four bytes. For a 500,000-row table with an
index length of three bytes (the size of
<literal>MEDIUMINT</literal>), the formula indicates
- <literal>log(500,000)/log(1024/3*2/(3+4)) + 1</literal> =
+ <literal>log(500,000)/log(1024/3×2/(3+4)) + 1</literal> =
<literal>4</literal> seeks.
</para>
@@ -2047,8 +2047,8 @@
(assuming that you want to sort on index 1). This is a good
way to make queries faster if you have a unique index from
which you want to read all rows in order according to the
- index. Note that the first time you sort a large table this
- way, it may take a long time.
+ index. The first time you sort a large table this way, it
+ may take a long time.
</para>
</listitem>
@@ -3551,21 +3551,21 @@
<listitem>
<para>
Table <literal>t1</literal> contains rows
- <literal>{1}</literal>, <literal>{2}</literal>
+ <literal>(1)</literal>, <literal>(2)</literal>
</para>
</listitem>
<listitem>
<para>
Table <literal>t2</literal> contains row
- <literal>{1,101}</literal>
+ <literal>(1,101)</literal>
</para>
</listitem>
<listitem>
<para>
Table <literal>t3</literal> contains row
- <literal>{101}</literal>
+ <literal>(101)</literal>
</para>
</listitem>
@@ -3573,10 +3573,10 @@
<para>
In this case, the first expression returns a result set
- including the rows <literal>{1,1,101,101}</literal>,
- <literal>{2,NULL,NULL,NULL}</literal>, whereas the second
- expression returns the rows <literal>{1,1,101,101}</literal>,
- <literal>{2,NULL,NULL,101}</literal>:
+ including the rows <literal>(1,1,101,101)</literal>,
+ <literal>(2,NULL,NULL,NULL)</literal>, whereas the second
+ expression returns the rows <literal>(1,1,101,101)</literal>,
+ <literal>(2,NULL,NULL,101)</literal>:
</para>
<programlisting>
@@ -4005,7 +4005,7 @@
For a query with outer joins, the <literal>WHERE</literal>
condition is to be checked only after it has been found that the
current row from the outer table has a match in the inner
- tables. Thus, the optimization with pushing condition out of the
+ tables. Thus, the optimization of pushing conditions out of the
inner nested loops cannot be applied directly to queries with
outer joins. Here we have to introduce conditional pushed-down
predicates guarded by the flags that are turned on when a match
@@ -4089,7 +4089,7 @@
<programlisting>
(T1, ...) RIGHT JOIN (T2,...) ON P(T1,...,T2,...) =
-(T2, ...) LEFT JOIN (T1,...) ON P(T1,...,T2,...).
+(T2, ...) LEFT JOIN (T1,...) ON P(T1,...,T2,...)
</programlisting>
<para>
@@ -4342,9 +4342,8 @@
<para>
the <literal>WHERE</literal> condition is not null-rejected for
the embedded outer join, but the join condition of the embedding
- outer join <literal>T2.A=T1.A</literal> AND
- <literal>T3.C=T1.C</literal> is null-rejected. So the query can
- be converted to:
+ outer join <literal>T2.A=T1.A AND T3.C=T1.C</literal> is
+ null-rejected. So the query can be converted to:
</para>
<programlisting>
@@ -4954,7 +4953,8 @@
This can be useful for checking the validity of a query.
When using one of the MySQL APIs, it can also be employed
for obtaining the types of the result columns. (This trick
- does not work in the MySQL Monitor, which merely displays
+ does not work in the MySQL Monitor (the
+ <command>mysql</command> program), which merely displays
<literal>Empty set</literal> in such cases; you should
instead use <literal>SHOW COLUMNS</literal> or
<literal>DESCRIBE</literal> for this purpose.)
@@ -5299,13 +5299,15 @@
<listitem>
<para>
To speed up <literal>INSERT</literal> operations that are
- performed with multiple statements, lock your tables:
+ performed with multiple statements for non-transactional
+ tables, lock your tables:
</para>
<programlisting>
LOCK TABLES a WRITE;
INSERT INTO a VALUES (1,23),(2,34),(4,33);
INSERT INTO a VALUES (8,26),(6,29);
+...
UNLOCK TABLES;
</programlisting>
@@ -5320,10 +5322,10 @@
</para>
<para>
- For transactional tables, you should use <literal>START
- TRANSACTION</literal> and <literal>COMMIT</literal> instead
- of <literal>LOCK TABLES</literal> to obtain faster
- insertions.
+ To obtain faster insertions, for transactional tables, you
+ should use <literal>START TRANSACTION</literal> and
+ <literal>COMMIT</literal> instead of <literal>LOCK
+ TABLES</literal>.
</para>
<para>
@@ -6182,7 +6184,8 @@
<literal>GET_LOCK()</literal> and
<literal>RELEASE_LOCK()</literal> in MySQL. These are
advisory locks, so they work only in well-behaved
- applications.
+ applications. (See
+ <xref linkend="miscellaneous-functions"/>.)
</para>
</listitem>
@@ -6364,7 +6367,8 @@
with <literal>SELECT</literal>, you might want to consider
switching to <literal>MyISAM</literal> tables, which support
concurrent <literal>SELECT</literal> and
- <literal>INSERT</literal> statements.
+ <literal>INSERT</literal> statements. (See
+ <xref linkend="concurrent-inserts"/>.)
</para>
</listitem>
@@ -6465,8 +6469,8 @@
<para>
Under circumstances where concurrent inserts can be used, there
is seldom any need to use the <literal>DELAYED</literal>
- modifier for <literal>INSERT</literal> statements.
- See <xref linkend="insert-delayed"/>.
+ modifier for <literal>INSERT</literal> statements. See
+ <xref linkend="insert-delayed"/>.
</para>
<para>
@@ -6903,8 +6907,8 @@
<programlisting>
CREATE TABLE test (
- id INT NOT NULL,
- last_name CHAR(30) NOT NULL,
+ id INT NOT NULL,
+ last_name CHAR(30) NOT NULL,
first_name CHAR(30) NOT NULL,
PRIMARY KEY (id),
INDEX name (last_name,first_name)
@@ -7342,8 +7346,8 @@
<para>
To minimize disk I/O, the <literal>MyISAM</literal> storage
- engine employs a strategy that is used by many database
- management systems. It exploits a cache mechanism to keep the
+ engine exploits a strategy that is used by many database
+ management systems. It employs a cache mechanism to keep the
most frequently accessed table blocks in memory:
</para>
@@ -7565,7 +7569,7 @@
<programlisting>
mysql> <userinput>SET GLOBAL key_buffer_size = 0;</userinput>
-mysql> <userinput>show variables like 'key_buffer_size';</userinput>
+mysql> <userinput>SHOW VARIABLES LIKE 'key_buffer_size';</userinput>
+-----------------+---------+
| Variable_name | Value |
+-----------------+---------+
@@ -7685,7 +7689,7 @@
key_buffer_size = 4G
hot_cache.key_buffer_size = 2G
cold_cache.key_buffer_size = 2G
-init_file=/path/to/data-directory/mysqld_init.sql
+init_file=/<replaceable>path</replaceable>/<replaceable>to</replaceable>/<replaceable>data-directory</replaceable>/mysqld_init.sql
</programlisting>
<para>
@@ -7908,8 +7912,8 @@
server destroys the cache's old structure and creates a new
one based on the new values. If the cache contains any dirty
blocks, the server saves them to disk before destroying and
- re-creating the cache. Restructuring does not occur if you set
- other key cache parameters.
+ re-creating the cache. Restructuring does not occur if you
+ change other key cache parameters.
</para>
<para>
@@ -8020,7 +8024,7 @@
For <literal>=</literal> comparisons, it does not matter how
many <literal>NULL</literal> values are in the table. For
optimization purposes, the relevant value is the average size of
- the non-<literal>NULL</literal> values groups. However, MySQL
+ the non-<literal>NULL</literal> value groups. However, MySQL
does not currently allow that average size to be collected or
used.
</para>
@@ -8139,34 +8143,44 @@
<literal>myisam_stats_method</literal>:
</para>
- <para>
- You can force table statistics to be collected explicitly, as
- just described. However, MySQL may also collect statistics
- automatically. For example, if during the course of executing
- statements for a table, some of those statements modify the
- table, MySQL may collect statistics. (This may occur for bulk
- inserts or deletes, or some <literal>ALTER TABLE</literal>
- statements, for example.) If this happens, the statistics are
- collected using whatever value
- <literal>myisam_stats_method</literal> has at the time. Thus, if
- you collect statistics using one method, but
- <literal>myisam_stats_method</literal> is set to the other
- method when a table's statistics are collected automatically
- later, the other method will be used.
- </para>
+ <itemizedlist>
- <para>
- There is no way to tell which method was used to generate
- statistics for a given <literal>MyISAM</literal> table.
- </para>
+ <listitem>
+ <para>
+ You can force table statistics to be collected explicitly,
+ as just described. However, MySQL may also collect
+ statistics automatically. For example, if during the course
+ of executing statements for a table, some of those
+ statements modify the table, MySQL may collect statistics.
+ (This may occur for bulk inserts or deletes, or some
+ <literal>ALTER TABLE</literal> statements, for example.) If
+ this happens, the statistics are collected using whatever
+ value <literal>myisam_stats_method</literal> has at the
+ time. Thus, if you collect statistics using one method, but
+ <literal>myisam_stats_method</literal> is set to the other
+ method when a table's statistics are collected automatically
+ later, the other method will be used.
+ </para>
+ </listitem>
- <para>
- <literal>myisam_stats_method</literal> applies only to
- <literal>MyISAM</literal> tables. Other storage engines have
- only one method for collecting table statistics. Usually it is
- closer to the <literal>nulls_equal</literal> method.
- </para>
+ <listitem>
+ <para>
+ There is no way to tell which method was used to generate
+ statistics for a given <literal>MyISAM</literal> table.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>myisam_stats_method</literal> applies only to
+ <literal>MyISAM</literal> tables. Other storage engines have
+ only one method for collecting table statistics. Usually it
+ is closer to the <literal>nulls_equal</literal> method.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
</section>
<section id="table-cache">
@@ -8274,7 +8288,7 @@
needs two file descriptors for each unique open table. You can
increase the number of file descriptors available to MySQL using
the <option>--open-files-limit</option> startup option to
- <command>mysqld_safe</command>. See
+ <command>mysqld</command>. See
<xref linkend="not-enough-file-handles"/>.
</para>
@@ -8836,7 +8850,7 @@
</programlisting>
<para>
- If there is a <command>mysqld</command> server currently
+ For a <command>mysqld</command> server that is currently
running, you can see the current values of its system variables
by connecting to it and issuing this statement:
</para>
@@ -8865,7 +8879,7 @@
</programlisting>
<para>
- For a full description for all system and status variables, see
+ For a full description of all system and status variables, see
<xref linkend="server-system-variables"/>, and
<xref linkend="server-status-variables"/>.
</para>
@@ -9026,7 +9040,7 @@
possible plans investigated by the MySQL optimizer grows
exponentially with the number of tables referenced in a query.
For small numbers of tables (typically less than 7−10)
- this is not a problem. However, when bigger queries are
+ this is not a problem. However, when larger queries are
submitted, the time spent in query optimization may easily
become the major bottleneck in the server's performance.
</para>
@@ -9079,7 +9093,7 @@
<literal>optimizer_search_depth</literal> is close to the
number of tables in the query. At the same time, if compiled
with <literal>optimizer_search_depth</literal> equal to 3 or
- 4, the compiler may compile in less than a minute for the
+ 4, the optimizer may compile in less than a minute for the
same query. If you are unsure of what a reasonable value is
for <literal>optimizer_search_depth</literal>, this variable
can be set to 0 to tell the optimizer to determine the value
@@ -10039,7 +10053,7 @@
<listitem>
<para>
<literal>ALTER</literal> statements on
- <literal>tbl2</literal> also fail.
+ <literal>tbl2</literal> fail.
</para>
</listitem>
@@ -10078,7 +10092,7 @@
</para>
<para>
- On Windows, you create a symbolic link to a MySQL database by
+ On Windows, create a symbolic link to a MySQL database by
creating a file in the data directory that contains the path
to the destination directory. The file should be named
<filename><replaceable>db_name</replaceable>.sym</filename>,
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1644 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 22 Mar |
