Mysql：Changes in MySQL 5.6.2 (2011-04-11, Developer Milestone)

Changes in MySQL 5.6.2 (2011-04-11, Developer Milestone)

Note

This is a milestone release, for use at your own risk. Upgrades between milestone releases (or from a milestone release to a GA release) are not supported. Significant development changes take place in milestone releases and you may encounter compatibility issues, such as data format changes that require attention in addition to the usual procedure of running mysql_upgrade. For example, you may find it necessary to dump your data with mysqldump before the upgrade and reload it afterward. (Making a backup before the upgrade is a prudent precaution in any case.)

• INFORMATION_SCHEMA Tables for InnoDB Buffer Pool Information

• INFORMATION_SCHEMA Table for InnoDB Metrics

• INFORMATION_SCHEMA Tables for InnoDB Data Dictionary

• Persistent InnoDB Optimizer Statistics

• InnoDB Configurable Data Dictionary Cache

• Optimizer Notes

• Explicit Partition Selection

• Performance Schema Notes

• Pluggable Authentication

• Plugin Notes

• Crash-Safe Binary Log

• Slave Log Tables

• Row Image Control

• Functionality Added or Changed

• Bugs Fixed

 

Persistent InnoDB Optimizer Statistics

• Performance; InnoDB: The optimizer statistics for InnoDB tables can now persist across server restarts, producing more stable query performance. You can also control the amount of sampling done to estimate cardinality for each index, resulting in more accurate optimizer statistics. This feature involves the configuration options innodb_analyze_is_persistent (later replaced by innodb_stats_persistent), innodb_stats_persistent_sample_pages, and innodb_stats_transient_sample_pages, and the ANALYZE TABLE statement. See Configuring Persistent Optimizer Statistics Parameters for details.

InnoDB Configurable Data Dictionary Cache

• InnoDB: To ease the memory load on systems with huge numbers of tables, InnoDB now frees up the memory associated with an opened table using an LRU algorithm to select tables that have gone the longest without being accessed. To reserve more memory to hold metadata for open InnoDB tables, increase the value of the table_definition_cache configuration option. InnoDB treats this value as a “soft limit” for the number of open table instances in the InnoDB data dictionary cache. The actual number of tables with cached metadata could be higher than the value specified for table_definition_cache, because metadata for InnoDB system tables, and parent and child tables in foreign key relationships, is never evicted from memory. For additional information, refer to the table_definition_cache documentation. (Bug #20877, Bug #11745884)

Explicit Partition Selection

• Partitioning: It is now possible to select one or more partitions or subpartitions when querying a partitioned table. In addition, many data modification statements (DELETE, INSERT, REPLACE, UPDATE, LOAD DATA, and LOAD XML) that act on partitioned tables also now support explicit partition selection. For example, assume we have a table named t with some integer column named c, and t has 4 partitions named p0, p1, p2, and p3. Then the query SELECT * FROM t PARTITION (p0, p1) WHERE c < 5 returns rows only in partitions p0 and p1 that match the WHERE condition, whereas partitions p2 and p3 are not checked.

  For additional information and examples, see Partition Selection, as well as the descriptions of the statements just listed.

Crash-Safe Binary Log

• Replication: Support for checksums when writing and reading the binary log is added to the MySQL Server. Writing checksums into the binary log is disabled by default; it can be enabled by starting the server with the --binlog-checksum option. To cause the server to read checksums from the binary log, start the server with the master_verify_checksum system variable enabled. The --slave-sql-verify-checksum option causes the slave to read checksums from the relay log.

• Replication: The MySQL Server now records and reads back only complete events or transactions to and from the binary log. By default, the server now logs the length of the event as well as the event itself and uses this information to verify that the event was written correctly to the log. A master also uses by default this value to verify events when reading from the binary log.

  If you enable writing of checksums (using the binlog_checksum system variable), the master can use these instead by enabling the master_verify_checksum system variable. The slave I/O thread also verifies events received from the master. You can cause the slave SQL thread to use checksums (if available) as well, when reading from the relay log, by enabling the slave_sql_verify_checksum system variable on the slave.

Slave Log Tables

• Replication: It is now possible to write information about the slave connection to the master and about the slave's execution point within the relay log to tables rather than files. Logging of master connection information and of slave relay log information to tables can be done independently of one another; this is controlled by the master_info_repository and relay_log_info_repository system variables. When master_info_repository=TABLE, connection information is logged in the slave_master_info table in the mysql system database. When relay_log_info_repository=TABLE, relay log information is logged to the slave_relay_log_info table, also in the mysql system database.

Functionality Added or Changed

• Incompatible Change: The following obsolete constructs have been removed. Where alternatives are shown, applications should be updated to use them.

  • The FLUSH MASTER and FLUSH SLAVE statements. Use the RESET MASTER and RESET SLAVE statements instead.