オリジナル版：http://dev.mysql.com/doc/refman/5.5/en/news-5-5-22.html
MySQL 5.5.22は世界でもっともポピュラーなオープンソースデータベースの5.5のプロダクトリリースの新しいバージョンです。MySQL 5.5.22はプロダクションシステムでの使用をお勧めします。
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.21をインストールする情報として、以下の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-22.html
Changes in MySQL 5.5.22 (21 March 2012)
Functionality Added or Changed
* InnoDB Storage Engine: A deprecation warning is now issued
when --ignore-builtin-innodb is used. (Bug #13586262)
* yaSSL was upgraded from version 1.7.2 to 2.2.0.
Bugs Fixed
* Important Change: InnoDB Storage Engine: When a row grew in
size due to an UPDATE operation, other (non-updated) columns
could be moved to off-page storage so that information about
the row still fit within the constraints of the InnoDB page
size. The pointer to the new allocated off-page data was not
set up until the pages were allocated and written, potentially
leading to lost data if the system crashed while the column
was being moved out of the page. The problem was more common
with tables using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED
along with the Barracuda file format, particularly with the
innodb_file_per_table setting enabled, because page allocation
operations are more common as the .ibd tablespace files are
extended. Still, the problem could occur with any combination
of InnoDB version, file format, and row format.
A related issue was that during such an UPDATE operation, or
an INSERT operation that reused a delete-marked record, other
transactions could see invalid data for the affected column,
regardless of isolation level.
The fix corrects the order of operations for moving the column
data off the original page and replacing it with a pointer.
Now if a crash occurs at the precise moment when the column
data is being transferred, the transfer will not be re-run
during crash recovery.
In MySQL 5.1, this fix applies to the InnoDB Plugin, but not
the built-in InnoDB storage engine. (Bug #13721257, Bug
#12612184, Bug #12704861)
* InnoDB Storage Engine: An erroneous assertion could occur, in
debug builds only, when creating an index on a column
containing zero-length values (that is, ''). (Bug #13654923)
* InnoDB Storage Engine: A DDL operation such as ALTER TABLE ...
ADD COLUMN could stall, eventually timing out with an Error
1005: Can't create table message referring to
fil_rename_tablespace. (Bug #13636122, Bug #62100, Bug #63553)
* InnoDB Storage Engine: A DDL operation for an InnoDB table
could cause a busy MySQL server to halt with an assertion
error:
InnoDB: Failing assertion: trx->error_state == DB_SUCCESS
The error occurred if the DDL operation was run while all 1023
undo slots were in use by concurrent transactions. This error
was less likely to occur in MySQL 5.5 and 5.6, because raising
the number of InnoDB undo slots increased the number of
simultaneous transactions (corresponding to the number of undo
slots) from 1K to 128K. (Bug #12739098, Bug #62401)
* InnoDB Storage Engine: Server startup could produce an error
for temporary tables using the InnoDB storage engine, if the
path in the $TMPDIR variable ended with a / character. The
error log would look like:
120202 19:21:26 InnoDB: Operating system error number 2 in
InnoDB: a file operation.
InnoDB: The error means the system cannot find the path
InnoDB: specified.
InnoDB: If you are installing InnoDB, remember that you
InnoDB: must create directories yourself, InnoDB does not
InnoDB: create them.
120202 19:21:26 InnoDB: Error: trying to open a table, but
InnoDB: could not open the tablespace file
InnoDB: './t/#sql7750_1_0.ibd'!
InnoDB: Have you moved InnoDB .ibd files around without
InnoDB: using the commands DISCARD TABLESPACE and IMPORT
InnoDB: TABLESPACE?
InnoDB: It is also possible that this is a temporary
InnoDB: table #sql...,
InnoDB: and MySQL removed the .ibd file for this.
The workaround for the problem was to create a similar
temporary table again, copy its .frm file to tmpdir under the
name mentioned in the error message (for example, #sql123.frm)
and restart mysqld with tmpdir set to its normal value without
a trailing slash, for example /var/tmp. On startup, MySQL
would see the .frm file and issue DROP TABLE for the orphaned
temporary table. (Bug #11754376, Bug #45976)
* Replication: Statements that wrote to tables with
AUTO_INCREMENT columns based on an unordered SELECT from
another table could lead to the master and the slave going out
of sync, as the order in which the rows are retrieved from the
table may differ between them. Such statements include any
INSERT ... SELECT, REPLACE ... SELECT, or CREATE TABLE ...
SELECT statement. Such statements are now marked as unsafe for
statement-based replication, which causes the execution of one
to throw a warning, and forces the statement to be logged
using the row-based format if the logging format is MIXED.
(Bug #11758263, Bug #50440)
* myisam_sort_buffer_size could not be set larger than 4GB on
64-bit systems. (Bug #45702, Bug #11754145)
* Due to improper locking, concurrent inserts into an ARCHIVE
table at the same time as repair and check operations on the
table resulted in table corruption. (Bug #37280, Bug
#11748748)