オリジナル版：http://dev.mysql.com/doc/refman/5.6/en/news-5-6-8.html
MySQL 5.6.8(リリース候補)は世界でもっともポピュラーなオープンソースデータベースの新バージョンです。
このリリースの新機能はリリース候補品質です。他の試作版と同様に、製品レベルのシステムあるいは、重要なデータを持つシステムにインストールする場合は慎重にしてください。
5.6.8はMySQL 5.5の全機能を含んでおり、5.6の開発マイルストーンリリースです。MySQL 5.6の新機能の概要については、以下の"MySQL 5.6の何が新しくなったのか"を参照してください。
http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html
新しいサーバにMySQL 5.6.8をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。
http://dev.mysql.com/doc/refman/5.6/en/installing.html
以前のMySQLリリースからアップグレードするには、以下のアップグレードについての注意事項を参照してください。
http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html
MySQL 5.6.8 RCから以前のリリースへのダウングレードはサポートされていませんのでご注意下さい
MySQL Server 5.6.8は、ダウンロード・ページの「開発版リリース」からソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。
http://dev.mysql.com/downloads/
すべてのミラーサイトが現在、最新であるとは限らないことに注意してください。あるミラーサイトでこのバージョンを見つけることができない場合は、再度確認を行うか、あるいは別のダウンロード・サイトを選択してください。
MySQL 5.6向けのプラットフォームリストに注目してください：
- x86(32ビット)とx86_64上のApple Mac OS X 10.6と10.7
(OS X 10.5はサポート対象からはずされました)
- x86(32ビット)とx86_64上のDebian 6
(Debian 5はサポート対象からはずされました)
- x86(32ビット)とx86_64上のRedHat Enterprise / Oracle Linux 5, 6
(RHEL/OL 4はサポート対象からはずされました)
- x86_64上のSuSE Enterprise Linux 11
(SLES 10はサポート対象からはずされました)
- x86(32ビット)とx86_64上のgeneric Linux (kernel 2.6)
- x86_64上のFreeBSD 9
(FreeBSD 7 and 8はサポート対象からはずされました)
- Sparc (64 bit)、x86 (32ビット)、x86_64上のOracle Solaris 10, 11
- x86(32ビット)とx86_64上のWindows Vista, 7, 2008
(Windows XPと2003はサポート対象からはずされました)
これは5.1と5.5のサポートされるプラットフォームのリストに影響するものではありません
Linuxディストリビューション固有のパッケージは固有のフォーマット(RPM、もしくはdeb)で提供され、加えて一般的なtar.gzパッケージがこれらのディストリビューションに適合します。
RedHatに互換性のあるCentOSやFedoraに関してはRedHatと一般的なパッケージの両方で動作します。
オペレーティングシステムのより新しいバージョンを使用するのであれば、バイナリ互換性アプローチ（より古いバージョンのためにビルドされたアプリケーションのサポート）によってMySQL 5.6の使用が保障されるはずです。
WindowsパッケージはWindows Installerのための新しいインストーラ経由、（非インストーラ）ZIPパッケージで利用することができます。以前のMSIパッケージはもはや利用できず、すべてのMySQL製品でWindows向けの統一されたインストーラが利用されるという点に注意してください。
5.6.8の全ての「バグフィックス」のリストはオンラインでも閲覧できます
http://dev.mysql.com/doc/refman/5.6/en/news-5-6-9.html
もしプロダクションレベルのシステムでMySQLを稼動させるならば、MySQL製品、バックアップ、モニタリング、モデリング、開発、管理ツールを含むMySQL Enterprise Editionに注目してください。MySQLのパフォーマンス、セキュリティ、稼働時間を高いレベルで達成します。
http://mysql.com/products/enterprise/
Changes in MySQL 5.6.8 (2012-Nov-7)
Installation Notes
* On Unix platforms, mysql_install_db supports a new option,
--random-passwords, that provides for more secure MySQL
installation. Invoking mysql_install_db with this option
causes it to perform the following actions in addition to its
normal operation:
+ Create a random password, assign it to the initial root
accounts, and set the "password expired" flag for those
accounts.
+ Write the initial password file to the .mysql.secret file
in the directory named by the $HOME environment variable.
Depending on operating system, using a command such as
sudo may cause the value of $HOME to refer to the home
directory of the root system user.
+ Remove the anonymous-user accounts.
As a result of these actions, it is necessary after
installation to start the server, connect as root using the
password written to the .mysql.secret file, and assign a new
root password. Until this is done, root cannot do anything
else. This must be done for each root account you intend to
use. To change the password, you can use the SET PASSWORD
statement (for example, with the mysql client). You can also
use mysqladmin or mysql_secure_installation.
For new RPM install operations (not upgrades),
mysql_install_db is invoked with the --random-passwords
option. (Install operations using RPMs for Unbreakabkle Linux
Network are unaffected and do not use this option.)
For installations using a binary .tar.gz distribution, you can
invoke mysql_install_db with the --random-passwords option
manually. This is recommended for any installation,
particularly for sites with sensitive data.
This new option is not yet reflected in the "man" pages which are
contained in the 5.6.8-rc packages, but the online documentation
is current:
http://dev.mysql.com/doc/refman/5.6/en/mysql-install-db.html
* mysql_install_db on Unix platforms will now create a new default
configuration file 'my.cnf' from a template that comes with the
package. This will be used by default when the server is started.
If the 'my.cnf' file already exists, it is assumed to be in use
and will not be overwritten.
The config file template and the created default file replace
the example files that came with earlier releases.
Functionality Added or Changed
* InnoDB: The InnoDB transportable tablespace feature was
enhanced to allow ALTER TABLE ... IMPORT TABLESPACE to succeed
in some cases where the corresponding .cfg file was not
available. This enhancement allows recovery of data even in
some cases where the system tablespace
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_sys
tem_tablespace) is corrupted or deleted. (Bug #14589582, Bug
#66715)
* The number of atomic operations performed by the Performance
Schema was reduced. (Bug #14658739)
* ALTER USER now can be used as a prepared statement. (Bug
#66874, Bug #14646014)
* On Windows, many MySQL executables depend on the libeay32.dll
and ssleay32.dll SSL libraries at runtime. To ensure that the
proper versions of these libraries are found, the install
process copies them into the same directory as the
executables.
* The SHOW AUTHORS and SHOW CONTRIBUTORS statements have been
removed.
Bugs Fixed
* Important Change: Replication: When running the slave with the
--slave-skip-errors option, successive skipped events (errors
logged as warnings) were found to contain information from
previous warnings, which caused an excessive amount of
redundant information to be written to the error log. This
problem could occur when using row-based or mixed-format
binary logging.
The fix for this issue is to clear these warnings prior to
processing the next skipped event. In addition, the skipped
events are now handled in the same way regardless of the value
of binlog_format, and a skipped error always causes a warning
to be written to the error log, as long as the value of the
log_warnings system variable is greater than 1. (Bug
#12776842)
* Important Change: The server system variables profiling,
have_profiling, and profiling_history_size are now deprecated,
and are subject to removal in a future release of the MySQL
Server. (Bug #14658683)
* InnoDB: When a CREATE INDEX operation failed for an InnoDB
FULLTEXT index due to a duplicate key error, some allocated
memory was not freed. (Bug #14759111)
* InnoDB: An online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_onl
ine_ddl) operation to create a unique index could fail to
detect duplicate index values, when the duplicate values were
caused by DML
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_dml
) operations while the index was being created. (Bug
#14733674)
* InnoDB: During a brief time window while creating an InnoDB
unique index, MySQL could print a spurious warning message:
WARNING: CANNOT FIND INDEX ?index_name IN INNODB INDEX TRANSLATION TA
BLE
The cause was that MySQL started enforcing the uniqueness
constraint before the existence of the index was fully
registered. The fix suppresses the incorrect message during
this final stage of index creation. (Bug #14735988)
* InnoDB: When using the transportable tablespace
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_tra
nsportable_tablespace) feature, the ALTER TABLE ... IMPORT
TABLESPACE statement could crash if the InnoDB table being
flushed contained a FULLTEXT index. With this fix, the table
data can be imported, although you must drop and re-create the
FULLTEXT index after the import operation. (Bug #14712962, Bug
#67081)
* InnoDB: If an InnoDB table containing a FULLTEXT index was
being modified by a TRUNCATE TABLE statement and on online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_onl
ine_ddl) operation simultaneously, the server could end up
with inconsistent internal locks or could crash. (Bug
#14676329)
* InnoDB: If the server crashed while executing TRUNCATE TABLE
for an InnoDB table containing a FULLTEXT index, further
errors could occur during crash recovery
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_cra
sh_recovery), preventing the server from restarting. (Bug
#14676345)
* InnoDB: If the MySQL server crashed while XA
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_xa)
transactions were in PREPARED state, inconsistent data could
be produced during crash recovery
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_cra
sh_recovery) if the query cache was enabled. The fix allows
MySQL to disable the query cache during crash recovery if
required. (Bug #14658648)
* InnoDB: MySQL could crash while creating an InnoDB table if
the disk became full at a specific moment: after the .frm file
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_frm
_file) was created but before the corresponding .ibd file
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_ibd
_file) was created. (Bug #14645935)
* InnoDB: If the server crashed at the moment specific point
when a change buffer
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_cha
nge_buffer) entry was being merged into a buffer pool page,
the transaction log and the change buffer were left in an
inconsistent state. After a restart, MySQL could crash after
reading the corresponding secondary index page. The problem
was more likely to occur in MySQL 5.5 or later, where the
original insert buffering
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_ins
ert_buffering) mechanism was generalized to cover other
operations. (Bug #14636528, Bug #66819, Bug #58571, Bug
#61104, Bug #65443)
* InnoDB: With the innodb_file_per_table setting enabled, a DROP
TABLE operation could cause a crash, due to a race condition
that depended on the timing of pending I/O requests. (Bug
#14594600, Bug #66718)
* InnoDB: If a crash occurred during a CREATE TABLE operation,
the InnoDB data dictionary
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_dat
a_dictionary) could be left in an inconsistent state, causing
a crash if the partially created table was accessed later.
(Bug #14601290)
* InnoDB: On startup, MySQL would not start if there was a
mismatch between the value of the innodb_log_file_size
configuration option and the actual size of the ib_logfile*
files that make up the redo log
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_red
o_log). This behavior required manually removing the redo log
files after changing the value of innodb_log_file_size. The
fix causes MySQL to write all dirty pages
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_dir
ty_page) to disk and re-create the redo log files during
startup if it detects a size mismatch. (Bug #14596550)
* InnoDB: If an online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_onl
ine_ddl) operation failed due to a duplicate key error, caused
by DML
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_dml
) changes being made concurrently to the table, the server
could crash with an assertion error. (Bug #14591797)
* InnoDB: If a FULLTEXT index was dropped from an InnoDB table,
and the server crashed later for an unrelated reason, an
additional error could occur while attempting to access
nonexistent FULLTEXT data structures. (Bug #14586855)
* InnoDB: A query against an InnoDB table with a FULLTEXT index
could crash, if the AGAINST clause contained a character
sequence that was encoded incorrectly for the character set of
the table. (Bug #14588091)
* InnoDB: The server could crash with a confusing message if it
ran out of space for temporary files during index creation.
InnoDB: Assertion failure in thread thread_num in file mtr0mtr.cc lin
e 306
InnoDB: Failing assertion: mtr->state == 12231
(Bug #14586256)
* InnoDB: An ALTER TABLE on an InnoDB table that dropped the
primary key and then re-created it with columns in a different
order could cause an error. The issue affected tables where
the swapped columns referenced each other in a single-table
foreign key
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_for
eign_key) relationship. The data dictionary could be left in
an inconsistent state, where the table was listed in SHOW
TABLES output but could not be queried or dropped. For
example, if the table was declared with primary key columns
(c1,c2) and a foreign key with c1 REFERENCES c2:
ALTER TABLE t2 DROP PRIMARY KEY, ADD PRIMARY KEY (c2, c1);
ERROR 1030 (HY000): Got error 38 from storage engine
(Bug #14548753)
* InnoDB: Table names containing non-ASCII characters were
displayed incorrectly when the
MYSQL.INNODB_TABLE_STATS.TABLE_NAME column was queried. (Bug
#14404879)
* InnoDB: A race condition could cause a crash during an online
CREATE INDEX statement for an InnoDB table. This bug only
affected very small tables. It required a DML
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_dml
) operation to be in progress for the table, affecting the
primary key
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_pri
mary_key) columns, at the same time the CREATE INDEX statement
was issued. (Bug #14117641)
* InnoDB: The server could crash with an assertion error during
operations on tables with ROW_FORMAT=COMPRESSED. (Bug
#14001972)
* InnoDB: In rare circumstances, during operations on an InnoDB
table containing foreign keys
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_for
eign_key), pages in the buffer pool
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_buf
fer_pool) could be evicted but not written to disk, leading to
data inconsistency. (Bug #13688491)
* InnoDB: In rare circumstances, MySQL could apply InnoDB undo
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_und
o) records out of order during a ROLLBACK
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_rol
lback) of an operation that modified a BLOB column. This issue
could cause an assertion error in debug builds:
!bpage->file_page_was_freed
(Bug #13249921)
* Partitioning: The server now skips pruning of tables (see
Partition Pruning
(http://dev.mysql.com/doc/refman/5.6/en/partitioning-pruning.h
tml)) that use a storage engine which handles its own
partitioning internally. The server now also explicitly
rejects attempts to use explicit partitioning for such tables.
(Bug #14672885)
* Partitioning: When used with a table having multiple columns
in its primary key, but partitioned by KEY using a column that
was not part of the primary key as the partitioning column, a
query using an aggregate function and DISTINCT such as SELECT
SUM(DISTINCT pk_column_1) FROM table WHERE pk_column_2 =
constant was not handled correctly. (Bug #14495351)
* Replication: When using a multithreaded slave, if all worker
threads were kept busy, it was possible for cleanup of an
internal MTS circular buffer to fail, resulting in a full
buffer and failure of the slave. (Bug #14710881)
* Replication: When invoked while while gtid_mode was set to
OFF, the SQL_THREAD_WAIT_AFTER_GTIDS() function waited
indefinitely, unless a timeout was specified. In the latter
case, the function could return incorrect values. Now, when
gtid_mode is OFF, SQL_THREAD_WAIT_AFTER_GTIDS() always returns
NULL, as expected. (Bug #14640065)
* Replication: Executing FLUSH LOGS in parallel with COMMIT
could cause the server to hang. (Bug #14640486)
* Replication: Partially-failed GRANT and REVOKE statements were
not always handled the same way on the master and the slave.
We now log an incident event whenever an error occurs, even if
it is only a partial error, with a message stating that manual
reconciliation is required. (Bug #14598585)
* Replication: Backtick (`) characters were not always handled
correctly in internally generated SQL statements, which could
sometimes lead to errors on the slave. (Bug #14548159)
* Replication: There existed a gap in time between the appending
of the current GTID to the server's list of logged GTIDs and
the commit of the transaction by the storage engine. On slow
platforms, or when using profiling, this could cause SELECT
SQL_THREAD_WAIT_AFTER_GTIDS(gtid) to return before the data
actually reached the database.
Now the current GTID is appended to the logged GTIDs following
the commit, which removes this gap and so eliminates a
possible source of inconsistency. (Bug #14116526)
* Replication: The error shown when a relay log file was missing
from the relay log index file informed the user only that the
log file was not found, but did not specify the exact reason.
Now in such cases, the error message returned is Could not
find target log file mentioned in relay log info in the index
file 'index_file_name' during relay log initialization. (Bug
#11758505)
* Replication: Following an insert into a nontransactional table
that failed due to insufficient disk space, the server did not
properly clean up all pending events, leading to an assert or
possibly to other errors. (Bug #11750014)
* Patches for materialized semi-joins caused failures of the
query plan interface used by NDBCLUSTER. (Bug #14704659)
* With the optimizer tracing enabled, the
INFORMATION_SCHEMA.OPTIMIZER_TRACE table can be queried to
find tracing information about the last statements. However,
for queries for which the results were retrieved from the
query cache, this information was not available. (Bug
#14665052)
* USE dbname could fail with Unknown database when dbname
contained multiple backtick (`) characters. (Bug #14645196)
* Outer joins could execute inefficiently and return incorrect
results if joins were pushed down to the storage engine. (Bug
#14644936)
* In debug builds, the server could crash because db_suicide()
failed to handle SIGABRT signals. (Bug #14649493)
* Attempts to insert, update, delete from, or lock unknown
Performance Schema tables failed with an
ER_TABLEACCESS_DENIED_ERROR error rather than
ER_NO_SUCH_TABLE. (Bug #14633008)
* An incomplete result could be stored in the query cache when a
query failed with an error (providing that the query cache was
enabled, and was set to a nonzero size). This fix ensures that
it is no longer possible for queries that finish with an error
to be cached. (Bug #14621700)
References: This bug was introduced by Bug #40264.
* The server could crash when registering tables in the query
cache for queries that selected from views. (Bug #14619935)
* Index condition pushdown in conjunction with descending index
range scan could return incorrect results if there were
multiple ranges in the range scan. (Bug #14604223)
* EXPLAIN DELETE ... WHERE impossible_condition could function
incorrectly when it was used in a stored routine. (Bug
#14601802)
References: This bug was introduced by Bug #11752097.
* The configure.pl script that converts GNU configure options to
CMake equivalents generated erroneous output for the
--with-client-ldflags and --with-mysqld-ldflags options. It
now ignores those options. (Bug #14593123)
* The server printed excessive Got error 159 when reading table
messages to the error log when one transaction attempted to
access a table that had been modified by another. (Bug
#14579877)
* The optimizer could choose an incorrect execution plan for
updates to InnoDB tables based on indexes that use column
prefixes. (Bug #14578060)
* A query with a subquery and ORDER BY and LIMIT clauses
returned fewer rows than expected when executed using
semi-join materialization. (Bug #14580874)
* Materialization of a subquery in the FROM clause could return
the wrong number of rows if the subquery included a LIMIT
clause. (Bug #14576727)
* In-source builds modified the source file
sql/share/dictionary.txt. (Bug #14562699)
* A query with a subquery in the JOIN ... ON clause with an
outer reference to a field that was out of scope could cause
the server to crash. (Bug #14498914)
* On Windows, mysql_plugin could not find my_print_defaults.
(Bug #14471052)
* When used in GRANT statements, quoted user name or host name
values containing leading or trailing spaces caused privileges
to be assigned incorrectly until a FLUSH PRIVILEGES statement
was issued.
Now, as a result of this fix, quoted name and host identifiers
used in a GRANT statement are automatically trimmed of any
leading and trailing spaces, before privileges are assigned.
(Bug #14328259)
* On Mac OS X, the version_compile_machine system variable did
not include the value 64 for server binaries compiled on a
64-bit system. (Bug #13859866)
* Access to INFORMATION_SCHEMA tables through a view could leak
memory. (Bug #13734987)
* On Microsoft Windows with CMake 2.6, the build process would
not stop if the create_initial_db step failed. (Bug #13713525)
* The test in mysqld_safe for the presence of the --plugin_dir
option and assignment of a default value to it were performed
before the actual argument parsing took place. (Bug #13548161)
* The number of connection errors from a given host as counted
by the server was periodically reset, with the result that
max_connect_errors was never reached and invalid hosts were
never blocked from trying to connect. (Bug #11753779)
References: See also Bug #38247, Bug #43006, Bug #45584, Bug
#45606.
* A cached query result was not empty at the end of statement
execution as expected. This could occur when executing queries
(with the query cache enabled and set to a nonzero size) where
the result was not sent to the client such as those executed
by the Event Scheduler, or when executing stored routines
containing queries while the server was running in bootstrap
mode. (Bug #11755580, Bug #14609893)
* The Range checked for each record optimization is now used for
conditions with outer query references. (Bug #11750963)
* Metadata locking resulted in excessive contention in read-only
workloads involving InnoDB tables and a low number of
connections.
Now the set of metadata locks can be partitioned into separate
hashes to permit connections accessing different objects to
use different locking hashes and reduce contention. The new
metadata_locks_hash_instances system variable can be used to
specify the number of hashes. (Bug #66473, Bug #14569140)
* ST_Contains() and ST_Within() incorrectly reported that a
polygon did not contain itself. ST_Equals() incorrectly
returned 0 for polygons that differed only in shifted
vertices. (Bug #64653, Bug #13864679)
* ST_Difference() could incorrectly produce empty polygons in
the result. (Bug #64649, Bug #13865773)
* For some queries involving ORDER BY, the optimizer chose the
wrong index for accessing the table. (Bug #45969, Bug
#11754370, Bug #14338686)
* In debug builds, vio_read() printed errno rather than
socket_error to the debug trace. (Bug #28775, Bug #11746795)