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

What's new in this version:

# Bugs fixed:

* Security Fix: For servers built with yaSSL, a preauthorization buffer overflow could cause memory corruption or a server crash. We thank Evgeny Legerov from Intevydis for providing us with a proof-of-concept script that allowed us to reproduce this bug. (Bug#50227, CVE-2009-4484)
* Important Change: Replication: The RAND() function is now marked as unsafe for statement-based replication. Using this function now generates a warning when binlog_format=STATEMENT and causes the the format to switch to row-based logging when binlog_format=MIXED.
This change is being introduced because, when RAND() was logged in statement mode, the seed was also written to the binary log, so the replication slave generated the same sequence of random numbers as was generated on the master. While this could make replication work in some cases, the order of affected rows was still not guaranteed when this function was used in statements that could update multiple rows, such as UPDATE or INSERT ... SELECT; if the master and the slave retrieved rows in different order, they began to diverge. (Bug#49222)
* Partitioning: When used on partitioned tables, the records_in_range handler call checked all partitions, rather than the unpruned partitions only. (Bug#48846) See also Bug#37252, Bug#47261.
* Partitioning: A query that searched on a ucs2 column failed if the table was partitioned. (Bug#48737)
* Replication: A LOAD DATA INFILE statement that loaded data into a table having a column name that must be escaped (such as `key` INT), caused replication to fail when logging in mixed or statement mode. In such cases, the master wrote the LOAD DATA event to the binary log without escaping the field names. (Bug#49473) See also Bug#47927.
* Replication: Spatial data types cause row-based replication to crash. (Bug#48776)
* Replication: A flaw in the implementation of the purging of binary logs could result in orphaned files being left behind in the following circumstances:
- If the server failed or was killed while purging binary logs.
- If the server failed or was killed after creating of a new binary log when the new log file was opened for the first time.
In addition, if the slave was not connected during the purge operation, it was possible for a log file that was in use to be removed; this could lead data loss and possible inconsistencies between the master and slave. (Bug#45292)
* Replication: When using the STATEMENT or MIXED logging format, the statements LOAD DATA CONCURRENT LOCAL INFILE and LOAD DATA CONCURRENT INFILE were logged as LOAD DATA LOCAL INFILE and LOAD DATA LOCAL INFILE, respectively (in other words, the CONCURRENT keyword was omitted). As a result, when using replication with either of these logging modes, queries on the slaves were blocked by the replication SQL thread while trying to execute the affected statements. (Bug#34628)
* Replication: Manually removing entries from the binary log index file on a replication master could cause the server to repeatedly send the same binary log file to slaves. (Bug#28421)
* Cluster Replication: When expire_logs_days was set, the thread performing the purge of the log files could deadlock, causing all binary log operations to stop. (Bug#49536)
* Within a stored routine, selecting the result of CONCAT_WS() with a routine parameter argument into a user variable could return incorrect results. (Bug#50096)
* The IBMDB2I storage engine was missing from the i5os 64-bit distribution of MySQL 5.1.42. It is now included again. (Bug#50059)
* EXPLAIN EXTENDED UNION ... ORDER BY caused a crash when the ORDER BY referred to a nonconstant or full-text function or a subquery. (Bug#49734)
* The push_warning_printf() function was being called with an invalid error level MYSQL_ERROR::WARN_LEVEL_ERROR, causing an assertion failure. To fix the problem, MYSQL_ERROR::WARN_LEVEL_ERROR has been replaced by MYSQL_ERROR::WARN_LEVEL_WARN. (Bug#49638)
* Some prepared statements could raise an assertion when re-executed. (Bug#49570)
* A Valgrind error in make_cond_for_table_from_pred() was corrected. Thanks to Sergey Petrunya for the patch to fix this bug. (Bug#49506)
* When compiling on Windows, an error in the CMake definitions for InnoDB would cause the engine to be built incorrectly. (Bug#49502)
* Valgrind warnings for CHECKSUM TABLE were corrected. (Bug#49465)
* Specifying an index algorithm (such as BTREE) for SPATIAL or FULLTEXT indexes caused a server crash. These index types do not support algorithm specification, and it is now disallowed to do so. (Bug#49250)
* The optimizer sometimes incorrectly handled conditions of the form WHERE col_name='const1' AND col_name='const2'. (Bug#49199)
* Execution of DECODE() and ENCODE() could be inefficient because multiple executions within a single statement reinitialized the random generator multiple times even with constant parameters. (Bug#49141)
* MySQL 5.1 does not support 2-byte collation numbers, but did not check the number and crashed for out-of-range values. (Bug#49134)
* With binary logging enabled, REVOKE ... ON {PROCEDURE|FUNCTION} FROM ... could cause a crash. (Bug#49119)
* The LIKE operator did not work correctly when using an index for a ucs2 column. (Bug#49028)
* check_key_in_view() was missing a DBUG_RETURN in one code branch, causing a crash in debug builds. (Bug#48995)
* Several strmake() calls had an incorrect length argument (too large by one). (Bug#48983)
* On Fedora 12, strmov() did not guarantee correct operation for overlapping source and destination buffer. Calls were fixed to use an overlap-safe version instead. (Bug#48866)
* Incomplete reset of internal TABLE structures could cause a crash with eq_ref table access in subqueries. (Bug#48709)
* Re-execution of a prepared statement could cause a server crash. (Bug#48508)
* The error message for ER_UPDATE_INFO was subject to buffer overflow or truncation. (Bug#48500)
* SHOW BINLOG EVENTS could fail with a error: Wrong offset or I/O error. (Bug#48357)
* Valgrind warnings related to binary logging of LOAD DATA INFILE statements were corrected. (Bug#48340)
* An aliasing violation in the C API could lead to a crash. (Bug#48284)
* The InnoDB Monitor could fail to print diagnostic information after a long lock wait. (Bug#47814)
* Queries containing GROUP BY ... WITH ROLLUP that did not use indexes could return incorrect results. (Bug#47650)
* If an invocation of a stored procedure failed in the table-open stage, subsequent invocations that did not fail in that stage could cause a crash. (Bug#47649)
* On Solaris, no stack trace was printed to the error log after a crash. (Bug#47391)
* The first execution of STOP SLAVE UNTIL stopped too early. (Bug#47210)
* When the mysql client was invoked with the --vertical option, it ignored the --skip-column-names option. (Bug#47147)
* It was possible for init_available_charsets() not to initialize correctly. (Bug#45058)
* Comparison with NULL values sometimes did not produce a correct result. (Bug#42760)
* Crash recovery did not work for InnoDB temporary tables. (Bug#41609)
* The mysql_upgrade command would create three additional fields to the mysql.proc table (character_set_client, collation_connection, and db_collation), but did not populate the fields with correct values. This would lead to error messages reported during stored procedure execution. (Bug#41569)
* When compressed MyISAM files were opened, they were always memory mapped, sometimes causing memory-swapping problems. To deal with this, a new system variable, myisam_mmap_size, was added to limit the amount of memory used for memory mapping of MyISAM files. (Bug#37408)
* A race condition on the privilege hash tables allowed one thread to try to delete elements that had already been deleted by another thread. A consequence was that SET PASSWORD or FLUSH PRIVILEGES could cause a crash. (Bug#35589, Bug#35591)
* ALTER TABLE with both DROP COLUMN and ADD COLUMN clauses could crash or lock up the server. (Bug#31145)