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

What's new in this version:

Bugs fixed:

* Incompatible Change: In binary installations of MySQL, the supplied binary-configure script would start and configure MySQL, even when request help on the command with the --help command-line option. The --help, if provided, will no longer start and install the server. (Bug#30954)

* Partitioning: When reorganizing partitions, not all affected subpartitions were removed prior to renaming. One way in which the issue was visible was that attempting to reorganize two partitions into a single partition having the same name as one of the original partitions could lead to a crash of the server. (Bug#47029)
See also Bug#45961, Bug#43729.

* Partitioning: An online or fast ALTER TABLE of a partitioned table could leave behind temporary files in the database directory. (Bug#46483)

* Partitioning: When performing an INSERT ... SELECT into a partitioned table, read_buffer_size bytes of memory were allocated for every partition in the target table, resulting in consumption of large amounts of memory when the table had many partitions (more than 100).
This fix changes the method used to estimate the buffer size required for each partition and limits the total buffer size to a maximum of approximately 10 times read_buffer_size. (Bug#45840)

* Partitioning: Inserting negative values into an AUTO_INCREMENT column of a partitioned table could lead to apparently unrelated errors or a crash of the server. (Bug#45823)

* Partitioning: Unnecessary calls were made in the server code for performing bulk inserts on partitions for which no inserts needed to be made. (Bug#35845)See also Bug#35843.

* Replication: Performing ALTER TABLE ... DISABLE KEYS on a slave table caused row-based replication to fail. (Bug#47312)

* Replication: BEGIN statements were not included in the output of mysqlbinlog. (Bug#46998)

* Replication: When using row-based replication, importing a dump made with mysqldump and replicating a row with an AUTO_INCREMENT column set to 0, with NO_AUTO_VALUE_ON_ZERO active on the master, the row was inserted successfully on the master; however any setting for NO_AUTO_VALUE_ON_ZERO was ignored on the slave. When the AUTO_INCREMENT column was incremented, this caused replication to fail on the slave due to a duplicate key error. In some cases it could also cause the slave to crash. (Bug#45999)

* Replication: Concurrent transactions that inserted rows into a table with an AUTO_INCREMENT column could break statement-based or mixed-format replication error 1062 Duplicate entry '...' for key 'PRIMARY' on the slave. This was especially likely to happen when one of the transactions activated a trigger that inserted rows into the table with the AUTO_INCREMENT column, although other conditions could also cause the issue to manifest. (Bug#45677)

* Replication: By default, all statements executed by the mysql_upgrade program on the master are written to the binary log, then replicated to the slave. In some cases, this can result in problems; for example, it attempted to alter log tables on replicated databases (this failed due to logging being enabled).
As part of this fix, a new mysql_upgrade option --write-binlog is added. Its inverse, --skip-write-binlog, can be used to disable binary logging while the upgrade is in progress. (Bug#43579)

* Replication: On the master, if a binary log event is larger than max_allowed_packet, the error message ER_MASTER_FATAL_ERROR_READING_BINLOG is sent to a slave when it requests a dump from the master, thus leading the I/O thread to stop. On a slave, the I/O thread stops when receiving a packet larger than max_allowed_packet.
In both cases, however, there was no Last_IO_Error reported, which made it difficult to determine why the slave had stopped in such cases. Now, Last_IO_Error is reported when max_allowed_packet is exceeded, and provides the reason for which the slave I/O thread stopped. (Bug#42914) See also Bug#14068, Bug#47200, Bug#47303.

* API: The fix for Bug#24507 could lead in some cases to client application failures due to a race condition. Now the server waits for the “dummy” thread to return before exiting, thus making sure that only one thread can initialize the POSIX threads library. (Bug#42850)

* The pthread_cond_wait() implementations for Windows could deadlock in some rare circumstances. (Bug#47768)

* On Mac OS X or Windows, sending a SIGHUP signal to the server or an asynchronous flush (triggered by flush_time) caused the server to crash. (Bug#47525)

* Debug builds could not be compiled with the Sun Studio compiler. (Bug#47474)

* A multiple-table UPDATE involving a natural join and a mergeable view raised an assertion. (Bug#47150)

* Solaris binary packages now are compiled with -g0 rather than -g. (Bug#47137)

* EXPLAIN caused a server crash for certain valid queries. (Bug#47106)

* The configure option --without-server did not work. (Bug#46980)

* ailed multiple-table DELETE statements could raise an assertion. (Bug#46958)

* When creating a new instance on Windows using mysqld-nt and the --install parameter, the value of the service would be set incorrectly, resulting in a failure to start the configured service. (Bug#46917)

* The server crashed when re-using outer column references in correlated subqueries when the enclosing query used a temp table. (Bug#46791)

* Assertion failure could result from repeated execution of a stored procedure containing an incorrect query with a subselect. (Bug#46629)

* The server ignored the setting of sync_frm for CREATE TABLE ... LIKE. (Bug#46591)

* An attempt to create a table with the same name as an existing view could cause a server crash. (Bug#46384)

* A parser problem prevented properly stripping backquotes from an argument to a user-defined function (UDF). If the UDF was in an ORDER BY clause, its name would not be properly resolved against an alias with the same name in the select list. (Bug#46259)

* Dropping an InnoDB table that used an unknown collation (created on a different server, for example) caused a server crash. (Bug#46256)

* Certain SELECT statements containing DISTINCT, GROUP BY, and HAVING clauses could hang in an infinite loop. (Bug#46159)

* InnoDB did not disallow creation of an index with the name GEN_CLUST_INDEX, which is used internally. (Bug#46000)

* CREATE TEMPORARY TABLE failed for InnoDB tables on systems with case-insensitive file systems when lower_case_table_names = 2 and the pathname of the temporary file directory contained uppercase characters. (Bug#45638)

* Appending values to an ENUM or SET definition is a metadata change for which ALTER TABLE need not rebuild the table, but it was being rebuilt anyway. (Bug#45567)

* The socket system variable was unavailable on Windows. (Bug#45498)

* When re-installing MySQL on Windows on a server that has a data directory from a previous MySQL installation, the installer would fail to identify the existence of the installation and the password configured for the root user. (Bug#45200)

* Client flags were incorrectly initialized for the embedded server, causing several tests in the jp test suite to fail. (Bug#45159)

* InnoDB did not always disallow creating tables containing columns with names that match the names of internal columns, such as DB_ROW_ID, DB_TRX_ID, DB_ROLL_PTR, and DB_MIX_ID. (Bug#44369)

* SELECT ... WHERE ... IN (NULL, ...) was executed using a full table scan, even if the same query without the NULL used an efficient range scan. (Bug#44139) See also Bug#18360.

* InnoDB use of SELECT MAX(autoinc_column) could cause a crash when MySQL data dictionaries went out of sync. (Bug#44030)

* LOAD DATA INFILE statements were written to the binary log in such a way that parsing problems could occur when re-executing the statement from the log. (Bug#43746)

* Selecting from the process list in the embedded server caused a crash. (Bug#43733) See also Bug#47304.

* Attempts to enable large_pages with a shared memory segment larger than 4GB caused a server crash. (Bug#43606)

* A test for stack growth failed on some platforms, leading to server crashes. (Bug#42213)

* MySQL server used the wrong lock type (always TL_READ instead of TL_READ_NO_INSERT when appropriate) for tables used in subqueries of UPDATE statements. This led in some cases to replication failure because statements were written in the wrong order to the binary log. (Bug#42108)

* The mysql-stress-test.pl test script was missing from the noinstall packages on Windows. (Bug#41546)

* Privileges for SHOW CREATE VIEW were not being checked correctly. (Bug#35996)

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

* myisamchk performed parameter value casting at startup that generated unnecessary warning messages. (Bug#33785)

* When building MySQL on Windows from source, the WITH_BERKELEY_STORAGE_ENGINE option would fail to configure BDB support correctly. (Bug#27693)