MySQLデータベースシステムの新バージョンであるMySQL 6.0.9アルファ版がリリースされました。MySQL 6.0に関する主要なページは、http://www.mysql.com/mysql60/にあります。
結合テーブルと結合バッファの両方へのインデックスアクセスを使用する新たなアルゴリズムが実装されました。Batched Key Access (BKA) Joinアルゴリズムと呼んでいます。当アルゴリズムは、ネストされた外部結合とネストされたsemi-joinを含む、内部結合、外部結合、およびsemi-joinの操作をサポートします。内部結合に対してのみ以前に使用されたBlock Nested Loop Joinアルゴリズムは改良され、ネストされた外部結合とネストされたsemi-joinを含む、外部結合、およびsemi-joinの操作も加わりました。
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に記述されています。
Functionality added or changed:
* Previously, index hints did not work for FULLTEXT searches.
Now they work as follows:
For natural language mode searches, index hints are silently
ignored. For example, IGNORE INDEX(i) is ignored with no
warning and the index is still used.
For boolean mode searches, index hints with FOR ORDER BY or
FOR GROUP BY are silently ignored. Index hints with FOR JOIN
or no FOR modifier are honored. In contrast to how hints apply
for non-FULLTEXT searches, the hint is used for all phases of
query execution (finding rows and retrieval, grouping, and
ordering). This is true even if the hint is given for a
non-FULLTEXT index. (Bug#38842:http://bugs.mysql.com/38842)
* MySQL support for adding collations using LDML specifications
did not support the <i> identity rule that indicates one
character sorts identically to another. The <i> rule now is
* Previously, RESTORE overwrote any databases with information
from the backup image. Now, RESTORE aborts with an error if
the backup image contains any databases that currently exist
on the server, unless the optional keyword OVERWRITE is given
following the image filename.
* Security Enhancement: When the DATA DIRECTORY or INDEX
DIRECTORY clause of a CREATE TABLE statement referred to a
subdirectory of the data directory via a symlinked component
of the data directory path, it was accepted, when for security
reasons it should be rejected.
* Incompatible Change: CHECK TABLE … FOR UPGRADE did not check
for collation changes made in MySQL 6.0.1 to latin2_czech_cs
or collation changes made in MySQL 6.0.6 to big5_chinese_ci,
cp866_general_ci, gb2312_chinese_ci, and gbk_chinese_ci. (This
also affects mysqlcheck and mysql_upgrade, which cause that
statement to be executed.)
* Partitioning: This bug was introduced in MySQL 6.0.5.
This regression was introduced by
* Partitioning: With READ COMMITTED transaction isolation level,
InnoDB uses a semi-consistent read that releases non-matching
rows after MySQL has evaluated the WHERE clause. However, this
was not happening if the table used partitions.
* Partitioning: For a partitioned table having an AUTO_INCREMENT
column: If the first statement following a start of the server
or a FLUSH TABLES statement was an UPDATE statement, the
AUTO_INCREMENT column was not incremented correctly.
* Partitioning: The server attempted to execute the statements
ALTER TABLE … ANALYZE PARTITION, ALTER TABLE … CHECK
PARTITION, ALTER TABLE … OPTIMIZE PARTITION, and ALTER TABLE
… REORGANIZE PARTITION on tables that were not partitioned.
* Partitioning: When executing an ORDER BY query on a
partitioned InnoDB table using an index that was not in the
partition expression, the results were sorted on a
per-partition basis rather than for the table as a whole.
* Partitioning: Partitioned table checking sometimes returned a
warning with an error code of 0, making proper response to
errors impossible. The fix also renders the error message
subject to translation in non-English deployments.
* Partitioning: When SHOW CREATE TABLE was used on a partitioned
table, all of the table’s PARTITION and SUBPARTITION clauses
were output on a single line, making it difficult to read or
* An assertion failure occurred for a join query when a small
size of the join buffer was set and the value of
record_per_key for the index used for a ref access with this
join buffer was big enough.
* For single-table UPDATE statements, an assertion failure
resulted from a runtime error in a stored function (such as a
recursive function call or an attempt to update the same table
as in the UPDATE statement).
* When executing concurrent CREATE TABLE … SELECT statements
on a Maria table, the error Error: Memory allocated at
trnman.c:129 was underrun, discovered at ma_close.c:65 error
would be logged in the error file, and the server would
eventually crash. (Bug#40416:http://bugs.mysql.com/40416)
* With statement-based binary logging format and a transaction
isolation level of READ COMMITTED or stricter, InnoDB printed
an error because statement-based logging might lead to
inconsistency between master and slave databases. However,
this error was printed even when binary logging was not
enabled (in which case, no such inconsistency can occur).
* A query with an outer join where the ON expression evaluated
to the constant FALSE could return incorrect results when a
join buffer was used for the outer join operation.
* If several errors occurred during a BACKUP DATABASE or RESTORE
operation, the final error was returned to the client, even
though the first error is usually more pertinent.
* Creation of a tablespace file within FALCON could create a
tablespace entry in the
INFORMATION_SCHEMA.FALCON_TABLESPACE_IO even the underlying
data file had not been created.
* The server could generate extra rows in the result set for a
query with a nested outer join if the inner tables of the
outer join were joined using join buffers.
* If BACKUP DATABASE was used to back up an empty database and
binary logging enabled, the backup image was flagged as
containing binary log information even though it did not.
Using RESTORE with the backup image then crashed trying to
parse the binary log filename.
* When an outer join employed a join buffer to join the first
inner table by the Blocked Nested Loops algorithm, extra
NULL-complemented rows could be generated if the WHERE clause
contained conditions that can be pushed down to this table.
* Support for the revision field in .frm files has been removed.
This addresses the downgrading problem introduced by the fix
* Retrieval speed from the following INFORMATION_SCHEMA tables
was improved by shortening the VARIABLE_VALUE column to 1024
characters: GLOBAL_VARIABLES, SESSION_VARIABLES,
GLOBAL_STATUS, and SESSION_STATUS.
As a result of this change, any variable value longer than
1024 characters will be truncated with a warning. This affects
only the init_connect system variable.
* If the operating system is configured to return leap seconds
from OS time calls or if the MySQL server uses a time zone
definition that has leap seconds, functions such as NOW()
could return a value having a time part that ends with :59:60
or :59:61. If such values are inserted into a table, they
would be dumped as is by mysqldump but considered invalid when
reloaded, leading to backup/restore problems.
Now leap second values are returned with a time part that ends
with :59:59. This means that a function such as NOW() can
return the same value for two or three consecutive seconds
during the leap second. It remains true that literal temporal
values having a time part that ends with :59:60 or :59:61 are
For additional details about leap-second handling, see Section
9.7.2, "Time Zone Leap Second Support."
* Creating a FALCON table while specifying a specific tablespace
and partition to be used for the table will fail if the
specified tablespace does not already exist, returning a error
indicating general table creation failure. The message has
been updated to indicate that the failure is due to
* With the ONLY_FULL_GROUP_BY SQL mode enabled, the check for
non-aggregated columns in queries with aggregate functions,
but without a GROUP BY clause was treating all the parts of
the query as if they were in the select list. This is fixed by
ignoring the non-aggregated columns in the WHERE clause.
* On 64-bit Windows systems, the server accepted key_buffer_size
values larger than 4GB, but allocated less. (For example,
specifying a value of 5GB resulted in 1GB being allocated.)
* Compiling MySQL with FALCON support enabled with a compiler
that does not support exceptions would fail to complete
successfully. configure has been updated to switch off FALCON
support if the specified compiler does not support exceptions.
* The server returned a column type of VARBINARY rather than
DATE as the result from the COALESCE(), IFNULL(), IF(),
GREATEST(), or LEAST() functions or CASE expression if the
result was obtained using filesort in an anonymous temporary
table during the query execution.
* Starting MySQL with FALCON support when MySQL has not been
compiled with a compiler supporting exceptions would lead to
strange errors and results. MySQL will now fail to initialize
if you have compiled without exceptions enabled with the
following message: 081116 12:21:12 [ERROR] Falcon must be
compiled with C++ exceptions enabled to work. Please adjust
your compile flags. [Falcon] Error: Falcon exiting process
* A server built using yaSSL for SSL support would crash if
configured to use an RSA key and a client sent a cipher list
containing a non-RSA key as acceptable.
* Use of InnoDB monitoring (SHOW ENGINE INNODB STATUS or one of
the InnoDB Monitor tables) could cause a server crash due to
invalid access to a shared variable in a concurrent
* Column names constructed due to wild-card expansion done
inside a stored procedure could point to freed memory if the
expansion was performed after the first call to the stored
* If delayed insert failed to upgrade the lock, it did not free
the temporary memory storage used to keep newly constructed
BLOB values in memory, resulting in a memory leak.
* For queries executed with the batched-key access method, an
incorrect value of an internal parameter caused a server
crashe if join_buffer_size was less then 256.
* Compiling MySQL with FALCON support enabled on Solaris 9 using
the Sun Studio compiler would fail with error: "Interlock.h",
line 149: Error: #error cas not defined. We need>= Solaris 10.
* mysqlcheck used SHOW FULL TABLES to get the list of tables in
a database. For some problems, such as an empty .frm file for
a table, this would fail and mysqlcheck then would neglect to
check other tables in the database.
* Statements that displayed the value of system variables (for
example, SHOW VARIABLES) expect variable values to be encoded
in character_set_system. However, variables set from the
command line such as basedir or datadir were encoded using
character_set_filesystem and not converted correctly.
* If a non-directory file f without an extension was created in
the data directory, the server would allow clients to execute
a USE f statement even though f could not be a database. The
server now verifies that that the named database corresponds
to a directory. (Bug#36897:http://bugs.mysql.com/36897)
* The FALCON storage would silently recreate missing tablespace
files if they did not exist. Errors are now written to the
MySQL error log when the FALCON system tablespace files are
found to be missing. Warnings are produce in the log file when
attempting to access data tablespace files that do not exist.
* The columns that store character set and collation names in
several INFORMATION_SCHEMA tables were lengthened because they
were not long enough to store some possible values: SCHEMATA,
TABLES, COLUMNS, CHARACTER_SETS, COLLATIONS, and
* Queries executed using the batched-key access method could
cause an assertion fail when key expressions for a ref access
depended on columns not only from the previous join table.
* There were spurious warnings about "Truncated incorrect DOUBLE
value" in queries with MATCH … AGAINST and > or < with a
constant (which was reported as an incorrect DOUBLE value) in
the WHERE condition. (Bug#34374:http://bugs.mysql.com/34374)
* mysql_config did not output -ldl (or equivalent) when needed
for –libmysqld-libs, so its output could be insufficient to
build applications that use the embedded server.
* The ROUTINES.DATA_TYPE,
REFERENTIAL_CONSTRAINTS.DATA_TYPE columns were declared longer
than the maximum allowed identifier length.
* Previously, use of index hints with views (which do not have
indexes) produced the error ERROR 1221 (HY000): Incorrect
usage of USE/IGNORE INDEX and VIEW. Now this produces ERROR
1176 (HY000): Key ‘…’ doesn’t exist in table ‘…’, the same
error as for base tables without an appropriate index.
* Server variables could not be set to their current values on
Linux platforms. (These fixes are in addition to those made in
MySQL 6.0.5.) (Bug#31177:http://bugs.mysql.com/31177)
* Searching for text values on a column using a character set
that provides multi-weight characters and sequences on an
INNODB or FALCON table with an index would fail to find the
expanded value. (Bug#29246:http://bugs.mysql.com/29246)
* Some SHOW statements and retrievals from the
INFORMATION_SCHEMA TRIGGERS and EVENTS tables used a temporary
table and incremented the Created_tmp_disk_tables status
variable, due to the way that TEXT columns are handled. The
TRIGGERS.SQL_MODE, TRIGGERS.DEFINER, and EVENTS.SQL_MODE
columns now are VARCHAR to avoid this problem.
* For several read only system variables that were viewable with
SHOW VARIABLES, attempting to view them with SELECT @@var_name
or set their values with SET resulted in an unknown system
variable error. Now they can be viewed with SELECT @@var_name
and attempting to set their values results in a message
indicating that they are read only.
* Setting the session value of the max_allowed_packet or
net_buffer_length system variable was allowed but had no
effect. The session value of these variables is now read only.