オリジナル版：http://dev.mysql.com/doc/refman/5.5/en/news-5-5-15.html
MySQL 5.5.15は世界でもっともポピュラーなオープンソースデータベースの5.5のプロダクトリリースの新しいバージョンです。MySQL 5.5.15はプロダクションシステムでの使用をお勧めします。
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.14をインストールする情報として、以下の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は、http://dev.mysql.com/downloads/とミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。
すべてのミラーサイトが現在、最新であるとは限らないことに注意してください。
あるミラーサイトでこのバージョンを見つけることができない場合は、再度確認を行うか、あるいは別のダウンロード・サイトを選択してください。
バグレポート、バグ修正、パッチ等の情報をお待ちしております。
http://forge.mysql.com/wiki/Contributing
次の節では、MySQL 5.5の以前のバージョンからのMySQLソースコードの変更を記載しています。これはオンラインでも閲覧できます。
http://dev.mysql.com/doc/refman/5.5/en/news-5-5-13.html
D.1.2. Changes in MySQL 5.5.15 (28 July 2011)
Functionality Added or Changed
* The undocumented --all option for perror is deprecated and
will be removed in MySQL 5.6.
Bugs Fixed
* InnoDB Storage Engine: A failed CREATE INDEX operation for an
InnoDB table could result in some memory being allocated but
not freed. This memory leak could affect tables created with
the ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED setting. (Bug
#12699505)
* Partitioning: Auto-increment columns of partitioned tables
were checked even when they were not being written to. In
debug builds, this could lead to a server crash. (Bug
#11765667, Bug #58655)
* Partitioning: The UNIX_TIMESTAMP() function was not treated as
a monotonic function for purposes of partition pruning. (Bug
#11746819, Bug #28928)
* Compiling the server with maintainer mode enabled failed for
gcc 4.6 or higher. (Bug #12727287)
* The option-parsing code for empty strings leaked memory. (Bug
#12589928)
* Previously, an inappropriate error message was produced if a
multiple-table update for an InnoDB table with a clustered
primary key would update a table through multiple aliases, and
perform an update that may physically move the row in at least
one of these aliases. Now the error message is: Primary
key/partition key update is not permitted since the table is
updated both as 'tbl_name1' and 'tbl_name2' (Bug #11882110)
See also Bug #11764529.
* Replication: If a LOAD DATA INFILE statement---replicated
using statement-based replication---featured a SET clause, the
name-value pairs were regenerated using a method
(Item::print()) intended primarily for generating output for
statements such as EXPLAIN EXTENDED, and which cannot be
relied on to return valid SQL. This could in certain cases
lead to a crash on the slave.
To fix this problem, the server now names each value in its
original, user-supplied form, and uses that to create LOAD
DATA INFILE statements for statement-based replication. (Bug
#60580, Bug #11902767)
See also Bug #34283, Bug #11752526, Bug #43746.
* ALTER TABLE {MODIFY|CHANGE} ... FIRST did nothing except
rename columns if the old and new versions of the table had
exactly the same structure with respect to column data types.
As a result, the mapping of column name to column data was
incorrect. The same thing happened for ALTER TABLE DROP COLUMN
... ADD COLUMN statements intended to produce a new version of
the table with exactly the same structure as the old version.
(Bug #61493, Bug #12652385)
* Incorrect handling of metadata locking for FLUSH TABLES WITH
READ LOCK for statements requiring prelocking caused two
problems:
+ Execution of any data-changing statement that required
prelocking (that is, involved a stored function or
trigger) as part of a transaction slowed down somewhat
all subsequent statements in the transaction. Performance
in a transaction that periodically involved such
statements gradually degraded over time.
+ Execution of any data-changing statement that required
prelocking as part of a transaction prevented a
concurrent FLUSH TABLES WITH READ LOCK from proceeding
until the end of the transaction rather than at the end
of the particular statement.
(Bug #61401, Bug #12641342)
* The fractional part of the "Queries per second" value could be
displayed incorrectly in MySQL status output (for example, in
the output from mysqladmin status or the mysql STATUS
command). (Bug #61205, Bug #12565712)
* LOAD DATA INFILE incorrectly parsed relative data file path
names that ascended more than three levels in the file system
and as a consequence was unable to find the file. (Bug #60987,
Bug #12403662)
* For unknown users, the native password plugin reported
incorrectly that no password had been specified even when it
had. (Bug #59792, Bug #11766641)
* For MyISAM tables, attempts to insert incorrect data into an
indexed GEOMETRY column could result in table corruption. (Bug
#57323, Bug #11764487)
* In debug builds, Field_new_decimal::store_value() was subject
to buffer overflows. (Bug #55436, Bug #11762799)
* A race condition between loading a stored routine using the
name qualified by the database name and dropping that database
resulted in a spurious error message: The table mysql.proc is
missing, corrupt, or contains bad data (Bug #47870, Bug
#11756013)