裝了 MySQL 之後不知道怎麼開始?它能做什麼、該不該用

What's new in this version:

Bugs Fixed:
- InnoDB Storage Engine: A failed CREATE INDEX operation for an InnoDB table could result in some memory being allocated and not freed. This memory leak could affect tables created with the ROW_FORMAT=DYNAMIC and ROW_FORMAT=COMPRESSED settings.
- Partitioning: Auto-increment columns of partitioned tables were checked even when they were not being written to. In debug builds, this could lead to a crash of the server.
- Partitioning: The UNIX_TIMESTAMP() function was not treated as a monotonic function for purposes of partition pruning.
- Replication: If a LOAD DATA INFILE statement—replicated using statement-based replication—featured a SET clause, the name-value pairs were regenerated using a method (Item::print()) intended primarily for generating output for statements such as EXPLAIN EXTENDED, and which cannot be relied on to return valid SQL. This could in certain cases lead to a crash on the slave. To fix this problem, we now name each value in its original, user-supplied form, and use that to create LOAD DATA INFILE statements for statement-based replication.
- Previously, an inappropriate error message was produced if a multiple-table update for an InnoDB table with a clustered primary key would update a table through multiple aliases, and perform an update that may physically move the row in at least one of these aliases. Now the error message is: Primary key/partition key update is not allowed since the table is updated both as 'tbl_name1' and 'tbl_name2'
- ALTER TABLE {MODIFY|CHANGE} ... FIRST did nothing except rename columns if the old and new versions of the table had exactly the same structure with respect to column data types. As a result, the mapping of column name to column data was incorrect. The same thing happened for ALTER TABLE DROP COLUMN, ADD COLUMN statements intended to produce a new version of table with exactly the same structure as the old version.
- Incorrect handling of metadata locking for FLUSH TABLES WITH READ LOCK for statements requiring prelocking caused two problems:
- Execution of any data-changing statement that required prelocking (that is, involved a stored function or trigger) as part of transaction slowed down somewhat all subsequent statements in the transaction. Performance in a transaction that periodically involved such statements gradually degraded over time.
- Execution of any data-changing statement that required prelocking as part of transaction prevented a concurrent FLUSH TABLES WITH READ LOCK from proceeding until the end of transaction rather than at the end of the particular statement.
- The fractional part of the “Queries per second” value in MySQL status output could be displayed incorrectly.
- LOAD DATA INFILE incorrectly parsed relative data file path names that ascended more than three levels in the file system and as a consequence was unable to find the file.
- For MyISAM tables, attempts to insert incorrect data into an indexed GEOMETRY column could result in table corruption.
- In debug builds, Field_new_decimal::store_value() was subject to buffer overflows.
- A race condition between loading a stored routine using the name qualified by the database name and dropping that database resulted in a spurious error message: The table mysql.proc is missing, corrupt, or contains bad data