オリジナル版：http://dev.mysql.com/doc/refman/5.5/en/news-5-5-30.html
MySQL 5.5.30は世界でもっともポピュラーなオープンソースデータベースの5.5のプロダクトリリースの新しいバージョンです。MySQL 5.5.29はプロダクションシステムでの使用をお勧めします。
MySQL 5.5は最新のマルチCPUやマルチコアハードウェアやオペレーティングシステムの利点を生かし、MySQLデータベースのパフォーマンスとスケーラビリ ティを改善するための影響の大きい変更をいくつか含んでいます。現在ではInnoDBがMySQLデータベースのデフォルトのストレージエンジンであり、 ACIDトランザクション、参照整合性、クラッシュリカバリをデフォルトで提供しています。
MySQL 5.5は以下の多くの新しい強化も含んでいます：
- Windowsにおける特有の機能と改善を利用した著しいパフォーマンス向上 - 新しい準同期レプリケーションとレプリケーションハートビートによるより高いレベルの可用性 - 改善されたインデックスとテーブルパーティショニング、SIGNAL/RESIGNALサポート、そして新しいPERFORMANCE_SCHEMAに含まれる強化された診断法による改善されたユーザビリティ
MySQL 5.5の新機能のより完全な概観については、以下のリソースを参照下さい。
MySQL 5.5 GA、Tomas Ulinのインタビュー:
http://dev.mysql.com/tech-resources/interviews/thomas-ulin-mysql-55.html
ドキュメント:
http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html
ホワイトペーパー: MySQL 5.5の新機能
http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html
製品レベルのシステムでMySQLを稼動させているならば、MySQL製品、バックアップ、モニタリング、モデリング、開発、管理ツールの包括的なセット を含むMySQLパフォーマンス、セキュリティ、アップタイムの高いレベルを実現するMySQL Enterprise Editionの製品詳細に注目してください。
http://mysql.com/products/enterprise/
新しいサーバへMySQL 5.5.30をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。
http://dev.mysql.com/doc/refman/5.5/en/installing.html
前回のMySQLリリースからアップグレードするには、以下のアップグレードについての注意事項を参照してください。
http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html
MySQL Server 5.5.30は、http://dev.mysql.com/downloads/とミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。
次の節では、MySQL 5.5の以前のバージョンからのMySQLソースコードの変更を記載しています。これはオンラインでも閲覧できます。
http://dev.mysql.com/doc/refman/5.5/en/news-5-5-30.html
Changes in MySQL 5.5.30 (5 Feb, 2013)
Known limitations of this release:
On Microsoft Windows, when using the MySQL Installer to install
MySQL Server 5.5.30 on a host with an existing MySQL Server of a
different version (such as 5.6.10), that also has a different
license (community versus commercial), you must first update the
license type of the existing MySQL Server. Otherwise, MySQL
Installer will remove MySQL Server(s) with different licenses from
the one you chose with MySQL Server 5.5.30.
On Microsoft Windows 8, updating a community release to a
commercial release requires you to manually restart the MySQL
service after the update.
Functionality Added or Changed
* InnoDB: The innodb_print_all_deadlocks configuration option
from MySQL 5.6 was backported to MySQL 5.5. This option
records each deadlock
(http://dev.mysql.com/doc/refman/5.5/en/glos_deadlock.html)
condition in the MySQL error log, allowing easier
troubleshooting if frequent deadlocks point to application
coding issues. (Bug #14515889)
* In RPM packages built for Unbreakable Linux Network,
libmysqld.so now has a version number. (Bug #15972480)
Bugs Fixed
* InnoDB; Performance: Some data structures related to undo
logging could be initialized unnecessarily during a query,
although they were only needed under specific conditions. (Bug
#14676084)
* InnoDB; Performance: Optimized read operations for compressed
(http://dev.mysql.com/doc/refman/5.5/en/glos_compression.html)
tables by skipping redundant tests. The check for whether any
related changes needed to be merged from the insert buffer
(http://dev.mysql.com/doc/refman/5.5/en/glos_insert_buffer.htm
l) was being called more often than necessary. (Bug #14329288,
Bug #65886)
* InnoDB; Performance: Immediately after a table was created,
queries against it would not use loose index scans
(http://dev.mysql.com/doc/refman/5.5/en/loose-index-scan.html)
. The issue went away following an ALTER TABLE on the table.
The fix improves the accuracy of the index statistics
(http://dev.mysql.com/doc/refman/5.5/en/glos_index_statistics.
html) gathered when the table is first created, and prevents
the query plan from being changed by the ALTER TABLE
statement. (Bug #14200010)
* InnoDB; Partitioning: 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: On systems that cannot handle unaligned memory access,
depending on the stack frame alignment, a SIGBUS error could
occur during startup. This issue was observed on Solaris
64-bit systems. (Bug #16021177)
* InnoDB: The status variable
Innodb_buffer_pool_read_ahead_evicted could show an inaccurate
value, higher than expected, because some pages in the buffer
pool
(http://dev.mysql.com/doc/refman/5.5/en/glos_buffer_pool.html)
were incorrectly considered as being brought in by read-ahead
(http://dev.mysql.com/doc/refman/5.5/en/glos_read_ahead.html)
requests. (Bug #15859402, Bug #67476)
* InnoDB: Creating an index on a CHAR column could fail for a
table with a character set with varying length, such as UTF-8,
if the table was created with the ROW_FORMAT=REDUNDANT clause.
(Bug #15874001)
* InnoDB: The server could halt with an assertion error while
creating an index:
InnoDB: Assertion failure in thread thread_num in file row0merge.cc
line 465
This issue affected tables with a combination of
ROW_FORMAT=REDUNDANT off-page columns
(http://dev.mysql.com/doc/refman/5.5/en/glos_off_page_column.h
tml), and an index on a column prefix
(http://dev.mysql.com/doc/refman/5.5/en/glos_column_prefix.htm
l). (Bug #14753402)
* InnoDB: If the server crashed at a precise moment during an
ALTER TABLE operation that rebuilt the clustered index
(http://dev.mysql.com/doc/refman/5.5/en/glos_clustered_index.h
tml) for an InnoDB table, the original table could be
inaccessible afterward. An example of such an operation is
ALTER TABLE ... ADD PRIMARY KEY The fix preserves the original
table if the server halts during this operation. You might
still need to rename the .ibd file manually to restore the
original table contents: in MySQL 5.6 and higher, rename from
#sql-ib$new_table_id.ibd to table_name.ibd within the database
directory; prior to MySQL 5.6, the temporary file to rename is
table_name#1 or #2. (Bug #14669848)
* InnoDB: An error at the filesystem level, such as too many
open files, could cause an unhandled error during an ALTER
TABLE operation. The error could be accompanied by Valgrind
warnings, and by this assertion message:
Assertion `! is_set()' failed.
mysqld got signal 6 ;
(Bug #14628410, Bug #16000909)
* InnoDB: A RENAME TABLE statement could stall for several
minutes before timing out. This issue could occurred for a
table using compression
(http://dev.mysql.com/doc/refman/5.5/en/glos_compression.html)
, with change buffering
(http://dev.mysql.com/doc/refman/5.5/en/glos_change_buffering.
html) enabled. (Bug #14556349)
* InnoDB: During shutdown, with the innodb_purge_threads
configuration option set greater than 1, the server could halt
prematurely with this error:
mysqld got signal 11
A workaround was to increase innodb_log_file_size and set
innodb_purge_threads=1. The fix was backported to MySQL 5.5
and 5.1, although those versions do not have the
innodb_purge_threads configuration option so the error was
unlikely to occur. (Bug #14234028)
* InnoDB: If the value of innodb_force_recovery was less than 6,
opening a corrupted table might loop forever if a corrupted
page was read when calculating statistics for the table.
Information about the corrupted page was written repeatedly to
the error log, possibly causing a disk space issue. The fix
causes the server to halt after a fixed number of failed
attempts to read the page. To troubleshoot such a corruption
issue, set innodb_force_recovery=6 and restart. (Bug
#14147491, Bug #65469)
* InnoDB: The value of the innodb_version variable was not
updated consistently for all server releases for the InnoDB
Plugin in MySQL 5.1, and the integrated InnoDB component in
MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server
development cycles are fully integrated and synchronized, now
the value returned by the innodb_version variable is the same
as for the version variable. (Bug #13463493, Bug #63435)
* Partitioning: Concurrent ALTER TABLE ... REBUILD PARTITION
operations could interfere with one another, even when not
running against the same table, because they both used global
memory for storage. Now each partition rebuild operation
stores intermediate data in memory that is local to that
process. (Bug #14589559, Bug #66645)
* Partitioning: Inserting any number of rows into an ARCHIVE
table that used more than 1000 partitions and then attempting
to drop the table caused the MySQL Server to fail. (Bug
#13819630, Bug #64580)
* Replication: After dropping a column from the slave's version
of a table, then altering the same column of this table on the
master (so that a type conversion would have been required had
the column not been droppped on the slave), inserts into this
table caused replication to fail. (Bug #15888454)
* Replication: When a binary log is replayed on a server (for
example, by executing a command like mysqlbinlog binlog.000001
| mysql), it sets a pseudo-slave mode on the client connection
used, so that the server can read binlog and apply binary log
events correctly. However, the pseudo-slave mode was not
disabled after the binary log dump was read, which caused
unexpected filtering rules to be applied to SQL statements
subsequently executed on the same connection. (Bug #15891524)
* Replication: When using statement-based replication, and where
the master and the slave used table schemas having different
AUTO_INCREMENT columns, inserts generating AUTO_INCREMENT
values logged for a given table on the master could be applied
to the wrong table on the slave. (Bug #12669186)
* Replication: Repeated execution of CHANGE MASTER TO statements
using invalid MASTER_LOG_POS values could lead to errors and
possibly a crash on the slave. Now in such cases, the
statement fails with a clear error message. (Bug #11764602,
Bug #57454)
* Replication: If the disk becomes full while writing to the
binary log, the server hangs until space is freed up manually.
It was possible after this was done for the MySQL server to
fail, due to an internal status value being set when not
needed. Now in such cases, rather than trying to set this
status, a warning is written in the error log instead. (Bug
#11753923, Bug #45449)
* Microsoft Windows: Dynamic file names (with colons) are no
longer allowed. Static file names using the Alternate Data
Stream (ADS) NTFS functionality of Microsoft Windows may
continue to be used. (Bug #11761752)
* Directory name manipulation could result in stack overflow on
Mac OS X and Windows. (Bug #16066243)
* Joins of exactly 32 tables and containing a HAVING clause
returned an empty result. (Bug #15972635)
* A buffer-handling problem in yaSSL was fixed. (Bug #15965288)
* A mysys library string-formatting routine could mishandle
width specifiers. (Bug #15960005)
* In certain cases, UpdateXML() could return NULL incorrectly.
(Bug #15948580)
References: See also Bug #13007062.
* Metadata locking and table definition cache routines did not
always check length of names passed to them. (Bug #15954872)
* XA START had a race condition that could cause a server crash.
(Bug #14729757)
* Enabling the query cache during high client contention could
cause the server to exit. (Bug #14727815)
* There was a performance regression for queries using SELECT
... INTO user variables and a WHERE condition on one or more
of the variables in the INTO list. (Bug #14664077)
References: This bug was introduced by Bug #12408412.
* The server sometimes failed to respect
MAX_CONNECTIONS_PER_HOUR limits on user connections. (Bug
#14627287)
* Output generated with mysqldump --routines could produce
syntax errors when reloaded. (Bug #14463669)
* With the thread pool plugin installed, a workload consisting
of concurrent KILL statements and ping queries caused the
server to exit. (Bug #14458232, Bug #14458002)
* 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)
* Passing an unknown time zone specification to CONVERT_TZ()
resulted in a memory leak. (Bug #12347040)
* 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)
* For MEMORY tables with HASH indexes, DELETE sometimes failed
to delete all applicable rows. (Bug #51763, Bug #11759445)
* The mysql client could mishandle the delimiter command if it
occurred on a line during which mysql was looking for the end
of a quoted string. (Bug #64135, Bug #13639125)
* mysqld_safe used the nonportable -e test construct. (Bug
#67976, Bug #16046140)
* Configuring the server with
performance_schema_events_waits_history_size=0 and
performance_schema_events_waits_history_long_size=0 could
cause a Performance Schema segmentation fault. (Bug #68008,
Bug #16060864)
* DECIMAL multiplication operations could produce significant
inaccuracy. (Bug #45860, Bug #11754279)
* For subqueries executing using a filesort, the optimizer could
produce an incorrect result containing wrong rows. (Bug
#66845, Bug #14636211)
References: See also Bug #12667154.
* UNION type conversion could incorrectly turn unsigned values
into signed values. (Bug #49003, Bug #11757005)
* During the startup process, mysqld could incorrectly remove
the PID file of an already running mysqld. (Bug #23790, Bug
#11746142)
References: See also Bug #14726272.