オリジナル版：http://dev.mysql.com/doc/refman/5.6/en/news-5-6-9.html
MySQL 5.6.9(リリース候補)は世界でもっともポピュラーなオープンソースデータベースの新バージョンです。
このリリースの新機能はリリース候補品質です。他の試作版と同様に、製品レベルのシステムあるいは、重要なデータを持つシステムにインストールする場合は慎重にしてください。
5.6.9は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.9をインストールする情報として、以下の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.9 RCから以前のリリースへのダウングレードはサポートされていませんのでご注意下さい
MySQL Server 5.6.9は、ダウンロード・ページの「開発版リリース」からソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。
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.9の全ての「バグフィックス」のリストはオンラインでも閲覧できます
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.9 (2012-Dec-11)
Installation Notes
* The --random-passwords option for mysql_install_db is now
used for MySQL install operations (not upgrades) which are
done using Solaris PKG packages.
Functionality Added or Changed
* Incompatible Change: Replication: A number of variable and
other names relating to GTID-based replication have been
changed, with a view to making these names more appropriate
and meaningful. The old names are no longer supported.
The features so renamed are shown in the following list:
+ The --disable-gtid-unsafe-statements server option has
been renamed --enforce-gtid-consistency; the
disable_gtid_unsafe_statements system variable has been
renamed enforce_gtid_consistency.
+ The gtid_done server system variable has been renamed
gtid_executed.
The gtid_lost server system variable has been renamed
gtid_purged; in addition, this variable is no longer
read-only.
+ The SQL_THREAD_WAIT_AFTER_GTIDS() function has been
renamed WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS().
For more information, see Replication with Global Transaction
Identifiers
(http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html
), and Global Transaction ID Options and Variables
(http://dev.mysql.com/doc/refman/5.6/en/replication-options-gt
ids.html). (Bug #14775984)
* Windows Vista, Windows Server 2008, and newer support native
symlinking using the mklink command. This makes the MySQL
Server implementation of database symbolic links using .sym
files redundant, so that mechanism is now deprecated and will
be removed in a future MySQL release. See Using Symbolic Links
for Databases on Windows
(http://dev.mysql.com/doc/refman/5.6/en/symbolic-links.html#wi
ndows-symbolic-links).
Bugs Fixed
* Performance: InnoDB: The timing values for low-level InnoDB
read operations were adjusted for better performance with fast
storage devices, such as SSD
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_ssd
). This enhancement primarily affects read operations for BLOB
columns in compressed
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_com
pression) tables. (Bug #13702112, Bug #64258)
* Incompatible Change: The THREAD_ID column in Performance
Schema tables was widened from INT to BIGINT to accommodate
64-bit values.
If you upgrade to this release of MySQL from an earlier
version, you must run mysql_upgrade (and restart the server)
to incorporate this change to the performance_schema database.
(Bug #14664453)
* Incompatible Change: Connection ID (thread ID) values greater
than 32 bits can occur on some systems (such as busy or
long-running 64-bit systems), causing these problems:
+ Connection IDs written to the general query log and slow
query log were incorrect. This was true for logging to
both files and tables.
+ The CONNECTION_ID() function could return a value with a
data type too small for values larger than 32 bits.
+ The mysql_thread_id() and mysql_kill() C API functions
did not handle ID values larger than 32 bits. This could
result in killing the wrong thread; for example, if you
invoked mysql_kill(mysql_thread_id()).
Connection IDs now are permitted to be 64-bit values when the
server supports them (when built with 64-bit data types),
which has these effects:
+ Connection IDs are logged correctly to the general query
log and slow query log.
Note
This change involves a modification to the log tables, so
after upgrading to this release, you must run
mysql_upgrade and restart the server.
+ CONNECTION_ID() returns a data type appropriate for
values larger than 32 bits.
+ mysql_thread_id() is unchanged; the client/server
protocal has only 4 bytes for the ID value. This function
returns an incorrect (truncated) value for connection IDs
larger than 32 bits and should be avoided.
mysql_kill() still cannot handle values larger than 32
bits, but to guard against killing the wrong thread now
returns an error in these cases:
o If given an ID larger than 32 bits, mysql_kill()
returns a CR_INVALID_CONN_HANDLE error.
o After the server's internal thread ID counter
reaches a value larger than 32 bits, it returns an
ER_DATA_OUT_OF_RANGE error for any mysql_kill()
invocation and mysql_kill() fails.
To avoid problems with mysql_thread_id() and
mysql_kill(), do not use them. To get the connection ID,
execute a SELECT CONNECTION_ID() query and retrieve the
result. To kill a thread, execute a KILL statement.
(Bug #19806, Bug #11745768, Bug #65715, Bug #14236124, Bug
#44728, Bug #11753308)
* Important Change: InnoDB: A DML
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_dml
) statement using the index merge access method could lock
many rows from the table, even when those rows were not part
of the final result set. This fix reduces the excessive
locking
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_loc
king) by releasing the locks of unmatched rows. This
optimization affects only transactions with isolation level
equal to or less strict than READ COMMITTED; it does not apply
to transactions using REPEATABLE READ or SERIALIZABLE
isolation level. (Bug #14226171)
* Important Change: Replication: Because running the server with
GTIDs enabled prevented changes to nontransactional tables,
programs such as mysql_upgrade and mysql_install_db were
unable to operate on system tables that used the MyISAM
storage engine and therefore could not function correctly.
Now, when running with --enforce-gtid-consistency (required
whenever --gtid-mode=ON), the server allows single statements
on nontransactional tables. (Bug #14722659)
* Important Change: Replication: Formerly, the value of the
Seconds_Behind_Master column in the output of SHOW SLAVE
STATUS was always set to NULL whenever the SQL thread or the
I/O thread was stopped. Now, this column is set to NULL only
if the SQL thread is not running, or if the I/O thread is not
running following a check to determine whether or not the SQL
thread has processed all of the relay log. (If the SQL thread
has finished processing and the I/O thread is running,
Seconds_Behind_Master is 0.) (Bug #12946333)
* Partitioning: InnoDB: Previously, when attempting to optimize
one or more partitions of a partitioned table that used a
storage engine that does not support partition-level OPTIMIZE,
such as InnoDB, MySQL reported Table does not support
optimize, doing recreate + analyze instead, then re-created
the entire table, but did not actually analyze it. Now in such
cases, the warning message is, Table does not support optimize
on partitions. All partitions will be rebuilt and analyzed. In
addition, the entire table is analyzed after first being
rebuilt. (Bug #11751825)
* InnoDB: An online DDL operation for an InnoDB table
incorrectly reported an empty value ('') instead of the
correct key value when it reported a duplicate key error for a
unique index using an index prefix. (Bug #14729221)
* InnoDB: InnoDB tables with FULLTEXT indexes could allocate
memory for thread handles that was never released, possibly
leading to resource issues on Windows systems. (Bug #14759163)
* InnoDB: During an online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_onl
ine_ddl) operation that copies the table, the secondary index
(http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_sec
ondary_index) of the table could become corrupted. (Bug
#14753701)
* InnoDB: If an ALTER TABLE statement failed while attempting to
create a FULLTEXT index for an InnoDB table, the server could
halt with an assertion error while dropping the incomplete
index. (Bug #14504174)
* Replication: If a table to be replicated had a FULLTEXT index,
this index was not ruled out when selecting the type of scan
to be used in finding the next row, even though it cannot be
used to find the correct one. The row applier subsequently
tried unsuccessfully to employ an index scan, causing
replication to fail. Now in such cases, indexes which do not
provide for sequential access (such as FULLTEXT) are not
considered when determining whether to use a table, index, or
hash scan for this purpose. (Bug #14843764)
* Replication: When using the GTID-aware master-slave protocol,
the slave I/O thread used the wrong position. When using
GTIDs, the position is not normally used, but as a special
case, the position was used in addition to the GTID when the
slave reconnected to the same master (even though this was not
necessary). This problem is fixed by making the GTID-aware
master-slave protocol not use positions at all any longer.
(Bug #14828028)
* Replication: Given a stored routine R in which the
GTID_SUBTRACT() function was invoked: Once GTID_SUBTRACT()
returned NULL when called inside R, it continued to return
NULL every time it was called within R, for the remainder of
the client session. (Bug #14838575)
* Replication: MySQL Enterprise Backup, mysqldump, and
mysqlhotcopy could not be used with a GTID-enabled MySQL
Server, because they were unable to restore the server's GTID
state and so could not restore from any point in the binary
log other than the very beginning.
As part of the fix for this problem, the gtid_purged system
variable (formerly named gtid_lost) is no longer read-only;
now it is possible to add GTIDs to it when gtid_executed
(formerly gtid_done) is empty. (Bug #14787808)
* Replication: Restarting replication after the first binary log
file was purged resulted in the error Got fatal error 1236
from master when reading data from binary log: 'The slave is
connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1,
but the master has purged binary logs containing GTIDs that
the slave requires.' This led GTID-based replication to fail.
(Bug #14756691)
* Invalid memory reads could occur for queries that selected
from a zero-length table name. (Bug #14780820)
* With LOCK TABLES in effect, CREATE TABLE IF NOT EXISTS ...
LIKE could raise an assertion. (Bug #14788976)
* An assertion was raised if ALTER TABLE was used to rename a
column to same name as an existing column while also
reordering the renamed column using AFTER or FIRST. (Bug
#14756089)
* An assertion could be raised if semi-join materialization was
used to evaluate a NOT IN subquery. (Bug #14751858)
* For some continuation handler nestings, continuation could
occur at the wrong location. (Bug #14724836)
* SHOW PROCESSLIST output was not sorted in Id order. (Bug
#14771006)
* For UPDATE statements, EXPLAIN showed the total key length in
the key_len column rather than the length of the used key
parts. (Bug #14682438)
* Starting the server with --bind-address and then setting
host_cache_size to 0 could result in the server stopping for
certain kinds of client connections. (Bug #14689561)
* With index condition pushdown enabled, the optimizer could
produce incorrect results for derived tables. (Bug #14640176)
* The optimizer could incorrectly use a nonspatial index to
optimize spatial operations, causing an assertion to be
raised. (Bug #14600994)
* CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had
a corrupt key (.MYI) file. Now the server produces an error.
(Bug #13556441)
* CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had
a corrupt key (.MYI) file. Now the server produces an error.
(Bug #13556107, Bug #13556000)
* For dumps of the mysql database, mysqldump skipped the event
table unless the --events option was given. To skip this table
if that is desired, use the --ignore-table option instead (Bug
#55587, Bug #11762933)
* mysqld_safe ignored the value of the UMASK environment
variable, leading to behavior different from mysqld with
respect to the access mode of created files. Now mysqld_safe
(and mysqld_multi) attempt to approximate the same behavior as
mysqld. (Bug #57406, Bug #11764559)
* LAST_INSERT_ID(expr) did not work for expr values greater than
the largest signed BIGINT value. (Bug #20964, Bug #11745891)