MySQL 6.0.6アルファ版がリリースされました。


新たなFalconトランザクションストレージエンジンおよびクラッシュしても安全なMariaエンジンを持つMySQLデータベースシステムの新バージョンであるMySQL 6.0.6アルファ版がリリースされました。MySQL 6.0に関する主要なページは、http://www.mysql.com/mysql60/にあります。

Falconストレージエンジンが初めてで、より多くの情報が必要な場合、Falcon Evaluation Guide

と、Falcon White Paper

Mariaストレージエンジンは、MyISAMのクラッシュ・セーフなバージョンです。MariaはMyISAMエンジンの主な機能のすべてをサポートします。それだけでなく、システムクラッシュが発生した場合のリカバリサポート、CREATE, DROP, RENAME, TRUNCATEを含む十分なロギング機能、全てのMyISAMテーブルのrow format、Maria固有の新たなrow formatもMariaはサポートしています。Mariaについてはhttp://dev.mysql.com/doc/refman/6.0/en/se-maria.htmlに記述されています。

MySQL 6.0.6アルファ版は、http://dev.mysql.com/downloads/mysql/6.0.htmlとミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。



以下は、MySQL 6.0の以前のバージョン以来、追加または変更された機能です。http://dev.mysql.com/doc/refman/6.0/en/news-6-0-6.htmlでも見ることができます。


News from the Changelog:

Functionality added or changed:

* Important Change: Incompatible Change: The FEDERATED storage
  engine is now disabled by default in binary distributions. The
  engine is still available and can be enabled by starting the
  server with the --federated option.

* Incompatible Change: The engines column in the
  mysql.online_backup table has been renamed to drivers to better
  reflect its contents.

* Incompatible Change: A change has been made to the way that
  the server handles prepared statements. This affects prepared
  statements processed at the SQL level (using the PREPARE
  statement) and those processed using the binary client-server
  protocol (using the mysql_stmt_prepare() C API function).
  Previously, changes to metadata of tables or views referred to
  in a prepared statement could cause a server crash when the
  statement was next executed, or perhaps an error at execute time
  with a crash occurring later. For example, this could happen
  after dropping a table and recreating it with a different
  definition.  Now metadata changes to tables or views referred to
  by prepared statements are detected and cause automatic
  repreparation of the statement when it is next executed.
  Metadata changes occur for DDL statements such as those that
  create, drop, alter, rename, or truncate tables, or that
  analyze, optimize, or repair tables. Repreparation also occurs
  after referenced tables or views are flushed from the table
  definition cache, either implicitly to make room for new entries
  in the cache, or explicitly due to FLUSH TABLES.  Repreparation
  is automatic, but to the extent that it occurs, performance of
  prepared statements is diminished.  Table content changes (for
  example, with INSERT or UPDATE) do not cause repreparation, nor
  do SELECT statements.  An incompatibility with previous versions
  of MySQL is that a prepared statement may now return a different
  set of columns or different column types from one execution to
  the next. For example, if the prepared statement is SELECT *
  FROM t1, altering t1 to contain a different number of columns
  causes the next execution to return a number of columns
  different from the previous execution.  Older versions of the
  client library cannot handle this change in behavior. For
  applications that use prepared statements with the new server,
  an upgrade to the new client library is strongly recommended.
  Along with this change to statement repreparation, the default
  value of the table_definition_cache system variable has been
  increased from 128 to 256. The purpose of this increase is to
  lessen the chance that prepared statements will need
  repreparation due to referred-to tables/views having been
  flushed from the cache to make room for new entries.  A new
  status variable, Com_stmt_reprepare, has been introduced to
  track the number of repreparations.

* Important Change: Some changes were made to CHECK TABLE ...
  FOR UPGRADE and REPAIR TABLE with respect to detection and
  handling of tables with incompatible .frm files (files created
  with a different version of the MySQL server). These changes
  also affect mysqlcheck because that program uses CHECK TABLE and
  REPAIR table, and thus also mysql_upgrade because that program
  invokes mysqlcheck.  + If your table was created by a different
  version of the MySQL server than the one you are currently
  running, CHECK TABLE ... FOR UPGRADE indicates that the table
  has an .frm file with an incompatible version. In this case, the
  result set returned by CHECK TABLE contains a line with a
  Msg_type value of error and a Msg_text value of Table upgrade
  required. Please do "REPAIR TABLE `tbl_name`" to fix it!  +
  REPAIR TABLE without USE_FRM upgrades the .frm file to the
  current version.  + If you use REPAIR TABLE ...USE_FRM and your
  table was created by a different version of the MySQL server
  than the one you are currently running, REPAIR TABLE will not
  attempt to repair the table. In this case, the result set
  returned by REPAIR TABLE contains a line with a Msg_type value
  of error and a Msg_text value of Failed repairing incompatible
  .FRM file.  Previously, use of REPAIR TABLE ...USE_FRM with a
  table created by a different version of the MySQL server risked
  the loss of all rows in the table.

* On Unix, it is now possible for the output file for BACKUP
  DATABASE to be an existing FIFO.

* mysql_upgrade now has a --tmpdir option to enable the location
  of temporary files to be specified.

* mysqldump now adds the LOCAL qualifier to the FLUSH TABLES
  statement that is sent to the server when the --master-data
  option is enabled. This prevents the FLUSH TABLES statement from
  replicating to slaves, which is disadvantageous because it would
  cause slaves to block while the statement executes.
  See also Bug#38303:http://bugs.mysql.com/38303

* The use of the SQL_CACHE and SQL_NO_CACHE options in SELECT
  statements now is checked more restrictively: 1) Previously,
  both options could be given in the same statement. This is no
  longer true; only one can be given. 2) Previously, these options
  could be given in SELECT statements that were not at the
  top-level. This is no longer true; the options are disallowed in
  subqueries (including subqueries in the FROM clause, and SELECT
  statements in unions other than the first SELECT.

* The undocumented, deprecated, and not useful SHOW COLUMN TYPES
  statement has been removed.

* Several improvements were made to MySQL Backup (the BACKUP
  DATABASE and RESTORE statements): + Drivers are now included for
  storage engines that do not store any data or rely on other
  storage engines for data storage: MERGE, FEDERATED, BLACKHOLE,
  EXAMPLE.  + The backup kernel better determines the dependency
  ordering of objects to be backed up so that they can be restored
  in the proper order.  + Restored events and triggers are not
  reactivated until the restore operation completes.

* BACKUP DATABASE now has a WITH COMPRESSION clause. This causes
  the image file to be compressed, which reduces its size.
  Compression also may result in improved backup time by reducing
  writes to disk.

* The Maria Storage Engine is now available as standard.

Bugs fixed:

* Incompatible Change: Access privileges for several statements
  are more accurately checked: + CHECK TABLE requires some
  privilege for the table.  + CHECKSUM TABLE requires SELECT for
  the table.  + CREATE TABLE ... LIKE requires SELECT for the
  source table and CREATE for the destination table.  + SHOW
  COLUMNS displays information only for those columns you have
  some privilege for.  + SHOW CREATE TABLE requires some privilege
  for the table (previously required SELECT).  + SHOW CREATE VIEW
  requires SHOW VIEW and SELECT for the view.  + SHOW INDEX
  requires some privilege for any column.  + SHOW OPEN TABLES
  displays only tables for which you have some privilege on any
  table column.

* Incompatible Change: Certain characters were sorted
  incorrectly for the following collations: TILDE and GRAVE ACCENT
  in big5_chinese_ci; LATIN SMALL LETTER J in cp866_general_ci;
  TILDE in gb2312_chinese_ci; and TILDE in gbk_chinese_ci.  As a
  result of this fix, any indexes on columns that use these
  collations and contain the affected characters must be rebuilt
  when upgrading to 6.0.6 or higher. To do this, use ALTER TABLE
  to drop and re-add the indexes, or mysqldump to dump the
  affected tables and mysql to reload the dump file.

* Incompatible Change: An additional correction to the original
  MySQL 6.0.4 fix was made to normalize directory names before
  adding them to the list of directories. This prevents /etc/ and
  /etc from being considered different, for example.
  See also Bug#38180:http://bugs.mysql.com/38180

* Important Change: The server no longer issues warnings for
  truncation of excess spaces for values inserted into CHAR
  columns. This reverts a change in the previous release that
  caused warnings to be issued.

* Partitioning: When one user was in the midst of a transaction
  on a partitioned table, a second user performing an ALTER TABLE
  on this table caused the server to hang.

* Partitioning: Inserts failed on partitioned tables containing
  user-supplied values for an AUTO_INCREMENT column.

* Replication: CREATE PROCEDURE and CREATE FUNCTION statements
  containing extended comments were not written to the binary log
  correctly, causing parse errors on the slave.
  See also Bug#32575:http://bugs.mysql.com/32575

* Replication: When flushing tables, there was a slight chance
  that the flush occurred between the processing of one table map
  event and the next. Since the tables were opened one by one,
  subsequent locking of tables would cause the slave to crash.
  This problem was observed when replicating NDBCLUSTER or InnoDB
  tables, when executing multi-table updates, and when a trigger
  or a stored routine performed an (additional) insert on a table
  so that two tables were effectively being inserted into in the
  same statement.

* Replication: CREATE VIEW statements containing extended
  comments were not written to the binary log correctly, causing
  parse errors on the slave. Now, all comments are stripped from
  such statements before being written to the binary log.
  See also Bug#36570:http://bugs.mysql.com/36570

* The Windows my-template.ini template file contained a
  reference to the myisam_max_extra_sort_file_size system
  variable, which no longer exists, causing the installed server
  to fail upon startup.

* The fix for Bug#33812: http://bugs.mysql.com/33812 had the
  side effect of causing the mysql client not to be able to read
  some dump files produced with mysqldump. To address this, that
  fix was reverted.

* Building MySQL with SSL and Falcon enabled would lead to a
  build failure.

* The code for the ut_usectime() function in InnoDB did not
  handle errors from the gettimeofday() system call. Now it
  retries gettimeofday() several times and updates the value of
  the Innodb_row_lock_time_max status variable only if
  ut_usectime() was successful.

* If the length of a field was 3, internal InnoDB to integer
  type conversion didn't work on big-endian machines in the
  row_search_autoinc_column() function.

* For a view that referred to a MyISAM table, the contents of
  the table could be empty after BACKUP DATABASE followed by

* Data loss could be caused by attempts to read data from a
  database being restored by a RESTORE operation.

* Data loss could be caused by activation of a trigger for a
  MyISAM table being restored by a RESTORE operation.

* On Windows 64-bit systems, temporary variables of long types
  were used to store ulong values, causing key cache
  initialization to receive distorted parameters. The effect was
  that setting key_buffer_size to values of 2GB or more caused
  memory exhaustion to due allocation of too much memory.

* Multiple-table UPDATE statements that used a temporary table
  could fail to update all qualifying rows or fail with a spurious
  duplicate-key error.

* The online backup stream library failed to parse the backup

* SHOW STATUS took a lot of CPU time for calculating the value
  of the Innodb_buffer_pool_pages_latched status variable. Now
  this variable is calculated and included in the output of SHOW
  STATUS only when the UNIV_DEBUG symbol is defined at server
  build time.

* On 64-bit platforms, BACKUP DATABASE hung for backups of more
  than 32KB.

* A REGEXP match could return incorrect rows when the previous
  row matched the expression and used CONCAT() with an empty

* mysqltest ignored the value of --tmpdir in one place.

* The ER_TRUNCATED_WRONG_VALUE warning condition was sometimes
  raised as an error.

* ha_innodb.so was incorrectly installed in the lib/mysql
  directory rather than in lib/mysql/plugin.

* The default drivers for BACKUP DATABASE and RESTORE now
  support a cancel operation, which also allows better cleanup if
  a driver error occurs.

* The server crashed while parsing large floating-point numbers
  such as 1e37 or -1e15.

* When updating an existing instance (for example, from MySQL
  5.0 to 5.1, or 5.1 to 6.0), the Instance Configuration Wizard
  unnecessarily prompted for a root password when there was an
  existing root password.

* For InnoDB tables, the DATA_FREE column of the
  INFORMATION_SCHEMA.TABLES displayed free space in kilobytes
  rather than bytes. Now it displays bytes.

* BACKUP DATABASE failed to back up views that depend on tables
  in a different database.

* The project files created for Windows were missing the
  GenError project dependency.

* The mysql client failed to recognize comment lines consisting
  of -- followed by a newline.

* CREATE INDEX for InnoDB tables could under very rare
  circumstances cause the server to crash..

* A read past the end of the string could occur while parsing
  the value of the --innodb-data-file-path option.

* Conversion of a FLOAT ZEROFILL value to string could cause a
  server crash if the value was NULL.

* The combination of semi-join and materialization both being
  enabled could lead to assertion failure during subquery

* Range optimizer evaluation of IN subqueries to be handled with
  the materialization strategy could lead to assertion failure.

* A server crash could occur during the cleanup phase of
  subquery execution.

* On Windows, the installer attempted to use JScript to
  determine whether the target data directory already existed.  On
  Windows Vista x64, this resulted in an error because the
  installer was attempting to run the JScript in a 32-bit engine,
  which wasn't registered on Vista. The installer no longer uses
  JScript but instead relies on a native WiX command.

* mysqltest was performing escape processing for the
  --replace_result command, which it should not have been.

* An error in calculation of the precision of zero-length items
  (such as NULL) caused a server crash for queries that employed
  temporary tables.

* For EXPLAIN EXTENDED, execution of an uncorrelated IN subquery
  caused a crash if the subquery required a temporary table for
  its execution.

* The MERGE storage engine did a table scan for SELECT COUNT(*)
  statements when it could calculate the number of records from
  the underlying tables.

* The server crashed inside NOT IN subqueries with an impossible
  WHERE or HAVING clause, such as NOT IN (SELECT ... FROM t1, t2,
  ... WHERE 0).

* mysql_stmt_prepare() did not reset the list of messages (those
  messages available via SHOW WARNINGS).

* The Event Scheduler was not designed to work under the
  embedded server. It is now disabled for the embedded server, and
  the event_scheduler system variable is not displayed.

* Grouping or ordering of long values in unindexed BLOB or TEXT
  columns with the gbk or big5 character set crashed the server.

* SET GLOBAL debug='' resulted in a Valgrind warning in
  DbugParse(), which was reading beyond the end of the control

* If a SELECT table list contained at least one
  INFORMATION_SCHEMA table, the required privileges for accessing
  the other tables were reduced.

* Some syntactically invalid statements could cause the server
  to return an error message containing garbage characters.

* The "prefer full scan on clustered primary key over full scan
  of any secondary key" optimizer rule introduced by Bug#26447:
  http://bugs.mysql.com/26447 caused a performance regression for
  some queries, so it has been disabled.

* The server ignored any covering index used for ref access of a
  table in a query with ORDER BY if this index was incompatible
  with the ORDER BY list and there was another covering index
  compatible with this list. As a result, suboptimal execution
  plans were chosen for some queries that used an ORDER BY clause.

* mysql_upgrade did not properly update the mysql.event table.

* The current system time (as returned by NOW() or synonyms)
  became constant after a RESTORE operation.

* Processing of an uncorrelated subquery using semi-join could
  cause incorrect results or a server crash.

* An incorrect error and message was produced for attempts to
  create a MyISAM table with an index (.MYI) filename that was
  already in use by some other MyISAM table that was open at the
  same time. For example, this might happen if you use the same
  value of the INDEX DIRECTORY table option for tables belonging
  to different databases.

* Enabling the read_only system variable while autocommit mode
  was enabled caused SELECT statements for transactional storage
  engines to fail.

* The range optimizer ignored conditions on inner tables in
  semi-join IN subqueries, causing the the optimizer to miss good
  query execution plans.

* An empty bit-string literal (b'') caused a server crash. Now
  the value is parsed as an empty bit value (which is treated as
  an empty string in string context or 0 in numeric context).

* For InnoDB tables, REPLACE statements used "traditional" style
  locking, regardless of the setting of innodb_autoinc_lock_mode.
  Now REPLACE works the same way as "simple inserts" instead of
  using the old locking algorithm.  (REPLACE statements are
  treated in the same way as as INSERT statements.)

* Different invocations of CHECKSUM TABLE could return different
  results for a table containing columns with spatial data types.

* A semi-join subquery in the ON clause in the absence of a
  WHERE clause caused a server crash.

* InnoDB was not updating the Handler_delete or Handler_update
  status variables.

* If the server crashed with an InnoDB error due to
  unavailability of undo slots, errors could persist during
  rollback when the server was restarted: There are two UNDO slot
  caches (for INSERT and UPDATE). If all slots end up in one of
  the slot caches, a request for a slot from the other slot cache
  would fail. This can happen if the request is for an UPDATE slot
  and all slots are in the INSERT slot cache, or vice versa.

* The combination of GROUP_CONCAT(), DISTINCT, and LEFT JOIN
  could crash the server when the right table is empty.

* Accessing a MERGE table with an empty underlying table list
  incorrectly resulted in a "wrong index" error message rather
  than "end of file."

* BACKUP DATABASE caused a server crash upon encountering a
  table row that has been marked for deletion but not removed.

* For InnoDB tables, ALTER TABLE DROP failed if the name of the
  column to be dropped began with "foreign".

* The table pullout strategy was not reflected in EXPLAIN
  EXTENDED output if not all of the subquery tables were pulled

* Access-denied messages for INFORMATION_SCHEMA incorrectly
  showed the name of the default database instead.

* Passing an invalid parameter to CHAR() in an ORDER BY clause
  caused the server to hang.

* Some binaries produced stack corruption messages due to being
  built with versions of bison older than 2.1. Builds are now
  created using bison 2.3.

* Concurrent execution of FLUSH TABLES along with SHOW FUNCTION
  STATUS or SHOW PROCEDURE STATUS could cause a server crash.

* The log_output system variable could be set to an illegal

* A server crash or memory overrun could occur with a dependent
  subquery and joins.

* InnoDB could crash if overflow occurred for an AUTO_INCREMENT

* On Windows 64-bit builds, an apparent compiler bug caused
  memory overruns for code in innobase/mem/*. Removed
  optimizations so as not to trigger this problem.

* Several additional configuration scripts in the BUILD
  directory now are included in source distributions. These may be
  useful for users who wish to build MySQL from source. (See
  Section 2.9.3, "Installing from the Development Source Tree,"
  for information about what they do.)

* For InnoDB tables, loss of data resulted from performing
  inserts concurrently with a RESTORE operation.

* A number of problems in new subquery optimization code meant
  that MySQL could pick an incorrect query plan when using
  InsideOut and/or FirstMatch subquery optimizations, which in
  turn would cause wrong query results.

* TIMESTAMP columns were restored to the current date and time
  (not their actual values) by a RESTORE operation.

* Use of 61 nested subqueries caused a server crash.

* For InnoDB tables, there was a race condition involving the
  data dictionary and repartitioning.

* Executing a FLUSH PRIVILEGES statement after creating a
  temporary table in the mysql database with the same name as one
  of the MySQL system tables caused the server to crash.  Note:
  While it is possible to shadow a system table in this way, the
  temporary table exists only for the current user and connection,
  and does not effect any user privileges.

* Selecting from a view that referenced the same table in the
  FROM clause and an IN clause caused a server crash.

* There was a race condition between the event scheduler and the
  server shutdown thread.

* Assignment of relative pathnames to general_log_file or
  slow_query_log_file did not always work.

* Deeply nested subqueries could cause stack overflow or a
  server crash.

* Conversion of binary values to multi-byte character sets could
  fail to left-pad values to the correct length. This could result
  in a server crash.

* Killing a statement that invoked a stored function could
  return an incorrect error message indicating table corruption
  rather than that the statement had been interrupted.

* Occurrence of an error within a stored routine did not always
  cause immediate statement termination.

* For DROP FUNCTION db_name.func_name (that is, when the
  function name is qualified with the database name), the
  statement should apply only to a stored function named func_name
  in the given database. However, if a UDF with the same name
  existed, the statement dropped the UDF instead.

* TRUNCATE TABLE for InnoDB tables returned a count showing too
  many rows affected. Now the statement returns 0 for InnoDB

* InnoDB could return an incorrect rows-updated value for UPDATE

* The mysql.servers table was not created during installation on
  (Bug#28680: http://bugs.mysql.com/28680, Bug#32797:

* The jp test suite was not working.

* The internal init_time() library function was renamed to
  my_init_time() to avoid conflicts with external libraries.

* In some cases, the parser interpreted the ; character as the
  end of input and misinterpreted stored program definitions.

* Statements to create, alter, or drop a view were not waiting
  for completion of statements that were using the view, which led
  to incorrect sequences of statements in the binary log when
  statement-based logging was enabled.

* The Questions status variable is intended as a count of
  statements sent by clients to the server, but was also counting
  statements executed within stored routines.

* InnoDB exhibited thread thrashing with more than 50 concurrent
  connections under an update-intensive workload.

* DROP DATABASE did not drop orphaned FOREIGN KEY constraints.

* Delayed-insert threads were counted as connected but not as
  created, incorrectly leading to a Threads_connected value
  greater than the Threads_created value.

* The parser used signed rather than unsigned values in some
  cases that caused legal lengths in column declarations to be

* Stored procedure exception handlers were catching fatal errors
  (such as out of memory errors), which could cause execution not
  to stop to due a continue handler. Now fatal errors are not
  caught by exception handlers and a fatal error is returned to
  the client.

* On Windows, moving an InnoDB .ibd file and then symlinking to
  it in the database directory using a .sym file caused a server

* If a connection was waiting for a GET_LOCK() lock or a SLEEP()
  call, and the connection aborted, the server did not detect this
  and thus did not close the connection. This caused a waste of
  system resources allocated to dead connections. Now the server
  checks such a connection every five seconds to see whether it
  has been aborted. If so, the connection is killed (and any lock
  request is aborted).