オリジナル版：http://dev.mysql.com/doc/refman/5.5/en/news-5-5-28.html
MySQL 5.5.28は世界でもっともポピュラーなオープンソースデータベースの5.5のプロダクトリリースの新しいバージョンです。MySQL 5.5.28はプロダクションシステムでの使用をお勧めします。
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.28をインストールする情報として、以下の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.28は、http://dev.mysql.com/downloads/とミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。
次の節では、MySQL 5.5の以前のバージョンからのMySQLソースコードの変更を記載しています。これはオンラインでも閲覧できます。
http://dev.mysql.com/doc/refman/5.5/en/news-5-5-28.html
Changes in MySQL 5.5.28 (2012-September-28)
Functionality Added or Changed
* The internal interface of the Thread Pool plugin has changed.
Old versions of the plugin will work with current versions of
the server, but versions of the server older than 5.5.28 will
not work with current versions of the plugin.
Bugs Fixed
* InnoDB: Certain information_schema tables originally
introduced in MySQL 5.6 are now also available in MySQL 5.5
and MySQL 5.1: INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and
INNODB_BUFFER_POOL_STATS. (Bug #13113026)
* InnoDB: When a SELECT ... FOR UPDATE, UPDATE, or other SQL
statement scanned rows in an InnoDB table using a < or <=
operator in a WHERE clause, the next row after the affected
range could also be locked. This issue could cause a lock wait
timeout for a row that was not expected to be locked. The
issue occurred under various isolation levels, such as READ
COMMITTED and REPEATABLE READ. (Bug #11765218)
* Partitioning: For tables using PARTITION BY HASH or PARTITION
BY KEY, when the partition pruning mechanism encountered a
multi-range list or inequality using a column from the
partitioning key, it continued with the next partitioning
column and tried to use it for pruning, even if the previous
column could not be used. This caused partitions which
possibly matched one or more of the previous partitioning
columns to be pruned away, leaving partitions that matched
only the last column of the partitioning key.
This issue was triggered when both of the following conditions
were met:
1. The columns making up the table's partitioning key were
used in the same order as in the partitioning key
definition by a SELECT statement's WHERE clause as in the
column definitions;
2. The WHERE condition used with the last column of the
partitioning key was satisfied only by a single value,
while the condition testing some previous column from the
partitioning key was satisfied by a range of values.
An example of a statement creating a partitioned table and a
query against this for which the issue described above
occurred is shown here:
CREATE TABLE t1 (
c1 INT,
c2 INT,
PRIMARY KEY(c2, c1)
) PARTITION BY KEY() # Use primary key as partitioning key
PARTITIONS 2;
SELECT * FROM t1 WHERE c2 = 2 AND c1 <> 2;
This issue is resolved by ensuring that partition pruning
skips any remaining partitioning key columns once a partition
key column that cannot be used in pruning is encountered. (Bug
#14342883)
* Partitioning: The buffer for the row currently read from each
partition used for sorted reads was allocated on open and
freed only when the partitioning handler was closed or
destroyed. For SELECT statements on tables with many
partitions and large rows, this could cause the server to use
excessive amounts of memory.
This issue has been addressed by allocating buffers for reads
from partitioned tables only when they are needed and freeing
them immediately once they are no longer needed. As part of
this fix, memory is now allocated for reading from rows only
in partitions that have not been pruned (see Partition Pruning
(http://dev.mysql.com/doc/refman/5.5/en/partitioning-pruning.h
tml)). (Bug #13025132)
References: See also Bug #11764622, Bug #14537277.
* Replication: On 64-bit Windows platforms, values greater than
4G for the max_binlog_cache_size and
max_binlog_stmt_cache_size system variables were truncated to
4G. This caused LOAD DATA INFILE to fail when trying to load a
file larger than 4G in size, even when max_binlog_cache_size
was set to a value greater than this. (Bug #13961678)
* Replication: In master-master replication with
--log-slave-updates enabled, setting a user variable and then
performing inserts using this variable caused the
Exec_master_log_position column in the output of SHOW SLAVE
STATUS not to be updated. (Bug #13596613)
* The RPM spec file now also runs the test suite on the new
binaries, before packaging them. (Bug #14318456)
* The libmysqlclient_r client library exported symbols from
yaSSL that conflict with OpenSSL. If a program linked against
that library and libcurl, it could crash with a segmentation
fault. (Bug #14068244)
* The argument for LIMIT must be an integer, but if the argument
was given by a placeholder in a prepared statement, the server
did not reject noninteger values such as '5'. (Bug #13868860)
* The Thread Pool plugin did not respect the wait_timeout
timeout for client sessions. (Bug #13699303)
* CHECK TABLE and REPAIR TABLE could crash if a key definition
differed in the .frm and .MYI files of a MyISAM table. Now the
server produces an error. (Bug #13555854)
* A query for a FEDERATED table could return incorrect results
when the underlying table had a compound index on two columns
and the query included an AND condition on the columns. (Bug
#12876932)
* mysqlhotcopy failed for databases containing views. (Bug
#62472, Bug #13006947, Bug #12992993)
* The argument to the --ssl-key option was not verified to exist
and be a valid key. The resulting connection used SSL, but the
key was not used. (Bug #62743, Bug #13115401)
* Adding a LIMIT clause to a query containing GROUP BY and ORDER
BY could cause the optimizer to choose an incorrect index for
processing the query, and return more rows than required. (Bug
#54599, Bug #11762052)
* mysqlbinlog did not accept input on the standard input when
the standard input was a pipe. (Bug #49336, Bug #11757312)