MySQL 5.6.16

MySQL 是一套開源且由社群驅動的關聯式資料庫管理系統，主要用來儲存、管理與檢索數據，並以速度快、可靠性高和易於使用著稱。它最鮮明的特色在於具備高度的可擴展性，能從小型應用一路撐起大型企業系統，同時提供最佳化的查詢執行與索引技術，確保資料處理效率；安全性方面也內建多種驗證與加密機制，並支援複寫與叢集以達成高可用性。目前由 Oracle 持續維護，更新相當活躍，在同類開發者工具中屬於主流首選，使用者評價普遍不錯，累積的評分人數也相當可觀。

這套軟體適合需要建構資料驅動應用程式的開發者，無論是網站後端、企業內部系統或數據分析平台，都能派上用場。它主要透過命令列介面運作，對熟悉指令的進階使用者較友善，但市面上有許多第三方圖形介面工具可補足操作門檻。與同分類的 BlueStacks、Turbo C++ 或 VMware 等工具相比，MySQL 專注於資料庫核心服務，並非整合開發環境或虛擬化方案，取捨上更偏向純粹的資料層需求。授權為開源軟體，提供 Windows 與 macOS 版本，但介面僅支援英文，使用前需留意語系與操作習慣。

MySQL 是一款開源且由 community-driven RDBMS，為儲存、管理與檢索數據提供強大且具可擴展性的平台。

它以速度快、可靠性高且易於使用而聞名，使其成為小型應用程式與大型企業系統的理想選擇。

由 Oracle Corporation 開發，MySQL Community Server 提供了一套完整的工具與功能，讓開發者能夠輕鬆建構動態且由數據驅動的應用程式。

Key Features

Scalability
它能處理海量數據，並可毫不費力地擴展以滿足日益增長的需求。

Performance
憑藉優化的 Query Execution 與 Indexing 技術，它能確保快速的數據檢索與處理速度。

Security
它提供多種 Authentication 機制與 Encryption 選項，以保護敏感數據的安全。

High Availability
它支援 Replication 與 Clustering，可實現冗餘備援並確保數據的持續可用性。

Flexibility
MySQL 相容於多種作業系統並支援多種程式語言，具有極高的通用性。

User Interface

MySQL Database Server 主要透過 Command-line Interface (CLI) 運作，適合經驗豐富的使用者與開發者。

然而，許多第三方工具提供了 Graphical User Interface (GUI)，簡化了資料庫管理任務，例如建立表格、執行查詢以及監控效能。

常見的 GUI 選項包括 phpMyAdmin, MySQL Workbench 以及 Navicat。

Installation and Setup

它為 Windows, macOS 與 Linux 等主流作業系統提供安裝套件。

安裝過程非常簡單，通常只需執行安裝程式並按照提示操作即可。

在設定過程中，使用者可以配置資料庫設定、定義存取權限以及指定儲存選項。

此外，它也可以作為 Web 開發 Stack 的一部分（例如 XAMPP 或 WAMP）進行安裝，以建立完整的開發環境。

How to Use

為了有效地使用 MySQL，使用者應對 SQL (Structured Query Language) 以及資料庫管理原則有基本的了解。

它提供豐富的 SQL 指令集用於建立、檢索、更新與刪除數據。開發者可以使用專用的 Connector 與 Library 將 MySQL 整合至其選擇的程式語言中，例如 Java 的 MySQL Connector/J 或 Python 的 MySQL Connector/Python。

目前有大量的官方文件與線上資源可幫助使用者學習並精通 MySQL 的功能。

FAQ

Q: 我可以將現有的資料庫遷移到 MySQL Community Server 嗎？
A: 可以，它提供了將資料庫從其他 RDBMS（如 Oracle, SQL Server 和 PostgreSQL）遷移的工具與公用程式。

Q: MySQL 適合大型應用程式嗎？
A: 絕對適合！MySQL 的 Scalability 與 Performance 使其成為管理企業級應用程式數據的絕佳選擇。

Q: 免費開源版本的 MySQL 有任何限制嗎？
A: 開源版本提供了豐富的功能，但若需要進階功能（如即時分析與企業級支援），使用者可以考慮訂閱制且功能更強大的 MySQL Enterprise Edition。

Q: 我可以防止未經授權的存取來保護我的 MySQL 資料庫嗎？
A: 可以，它提供了強大的安全功能，包括 User Authentication、Access Control 與 Encryption 機制，以保護您的數據免於未經授權的存取。

Q: MySQL 支援 Stored Procedures 和 Triggers 嗎？
A: 是的，它支援 Stored Procedures, Triggers 以及 Functions，允許開發者在資料庫內執行複雜的操作並自動化任務。

Alternatives

雖然 MySQL Database Server 在 RDBMS 市場佔據主導地位，但仍有其他替代方案可供選擇，且各有其獨特功能與優勢。值得關注的替代產品包括：

Microsoft SQL Server: 針對 Windows 平台設計，提供強大的企業級功能、與 Microsoft 產品的無縫整合以及卓越的 Scalability。

PostgreSQL: 以注重標準合規性與進階功能著稱，是一款適用於複雜數據場景的強大開源 DBMS。

Oracle Database: 作為商業 RDBMS，提供極高性能、進階安全性和廣泛的管理工具，適合大型企業級應用。

SQLite: 理想的小型輕量化應用選擇，是一款 Serverless DBMS，在簡便性、可移植性與零配置部署方面表現出色。

Pricing

MySQL 主要分為兩個版本：Community Edition (免費開源) 與 Enterprise Edition (商業版，提供額外功能與支援)。

Community Edition 是大多數使用者的熱門選擇，而 Enterprise Edition 則需要訂閱，並提供量身打造的企業級進階功能。

此外，他們還提供以下產品：

• MySQL HeatWave
• MySQL Enterprise Edition
• MySQL Standard Edition
• MySQL Classic Edition
• MySQL Cluster CGE
• MySQL Embedded (OEM/ISV)

System Requirements

MySQL 的系統需求依據所使用的作業系統與版本而異。

一般而言，它支援 Windows, macOS 以及各種 Linux 發行版。

根據資料庫的大小與複雜程度，需要充足的磁碟空間、記憶體與處理能力。

PROS

• 開源且免費的 Community Server Edition
• 高效能與高 Scalability
• 強大的安全功能
• 豐富的文件紀錄與活躍的社群支援
• 相容於多種程式語言

CONS

• Command-line Interface 對初學者來說可能較具挑戰性
• 部分進階功能僅限於 Enterprise Edition
• 複雜的設定可能需要額外的配置與優化

Conclusion

MySQL Community Server 是一款可靠且功能豐富的 RDBMS，在管理關聯式資料庫方面享有盛名。其速度、Scalability 與通用性使其適用於從小型專案到企業級系統的各種應用。

雖然 Command-line Interface 對初學者而言可能需要一定的學習曲線，但 GUI 工具的出現簡化了資料庫管理流程。憑藉龐大的社群與詳盡的文件，它將繼續作為軟體開發生態系統中的核心工具。無論您是開發者、數據分析師還是企業主，MySQL 都能讓您高效地組織與存取數據，為您的專案與計畫帶來成功。

Also Available: MySQL for Mac

Download MySQL Latest Version Why is this app published on FileHorse? (More info)

# Functionality Added or Changed
* Previously, ALTER TABLE in MySQL 5.6 could alter a table such that the result had temporal columns in both 5.5 and 5.6 format. Now ALTER TABLE upgrades old temporal columns to 5.6 format for ADD COLUMN, CHANGE COLUMN, MODIFY COLUMN, ADD INDEX, and FORCE operations. This conversion cannot be done using the INPLACE algorithm, so specifying ALGORITHM=INPLACE in these cases results in an error.
* CMake now supports a -DTMPDIR=dir_name option to specify the default tmpdir value. If unspecified, the value defaults to P_tmpdir in <stdio.h>. Thanks to Honza Horak for the patch.
# Bugs Fixed
* InnoDB; Replication: Using the InnoDB memcached plugin (see InnoDB Integration with memcached) with innodb_api_enable_binlog set to 1 caused the server to leak memory.
* InnoDB: A boolean mode full-text search query would result in a memory access violation during parsing.
* InnoDB: When new indexes are added by an ALTER TABLE operation, instead of only saving table-level statistics and statistics for the new indexes, InnoDB would save statistics for the entire table, including the table's other indexes. This behavior slowed ALTER TABLE performance.
* InnoDB: Due to a parser error, full-text search queries that include a sub-expression could return the wrong result.
* InnoDB: The innochecksum tool did not use a Windows-specific API to retrieve file size information, which resulted in an incorrect error message (Error: ibdata1 cannot be found) when the MySQL 5.6 innochecksum 2GB file size limit was exceeded. innochecksum now provides support for files larger than 2GB in both MySQL 5.6 and MySQL 5.7.
* InnoDB: Due to a regression introduced by the fix for Bug#17371537, memory was not allocated for the default memcached engine when using the default memcached engine as the backstore for data instead of InnoDB.
* InnoDB: InnoDB would report an incorrect operating system error code after failing to initialize.
* InnoDB: Manipulating a table after discarding its tablespace using ALTER TABLE ... DISCARD TABLESPACE could result in a serious error.
* InnoDB: Persistent optimizer statistics would cause stalls due to latch contention.
* InnoDB: MATCH() ... AGAINST queries that use a long string as an argument for AGAINST() could result in an error when run on an InnoDB table with a full-text search index.
* InnoDB: An InnoDB full-text search failure would occur due to an “unended” token. The string and string length should be passed for string comparison.
* InnoDB: In debug builds, a merge insert buffer during a page read would cause a memory access violation.
* InnoDB: Truncating a memcached InnoDB table while memcached is performing DML operations would result in a serious error.
* InnoDB: In sync0rw.ic, rw_lock_x_lock_func_nowait would needlessly call os_thread_get_curr_id.
* InnoDB: Attempting to rename a table to a missing database would result in a serious error.
* InnoDB: If a tablespace data file path is updated in a .isl file and then a crash recovery is performed, the updated tablespace data file path is read from the .isl file but the SYS_DATAFILES table would not be not updated. The SYS_DATAFILES table is now updated with the new data file path after crash recovery.
* InnoDB: If the first page (page 0) of file-per-table tablespace data file was corrupt, recovery would be halted even though the doublewrite buffer contained a clean copy of the page.
* InnoDB: The InnoDB memcached Readme file (README-innodb_memcached) incorrectly stated that libevent 1.6.0 is linked statically into daemon memcached. The bundled version of libevent is 1.4.12, not 1.6.0.
* InnoDB: Attempting to reset a replication slave while innodb_force_recovery is greater than 0 would return a cryptic error message: ERROR(1030) HY000: Got error -1 from storage engine. The error message has been changed to: ERROR HY000: Operation not allowed when innodb_force_recovery > 0. Replication options such as --relay-log-info-repository=TABLE and --master-info-repository=TABLE store information in tables in InnoDB. When innodb_force_recovery is greater than 0, replication tables cannot be updated which may cause replication administration commands to fail.
* InnoDB: The ALTER TABLE INPLACE algorithm would fail to decrease the auto-increment value.
* InnoDB: Comments in btr0cur.cc incorrectly stated that btr_cur_pessimistic_update() and btr_cur_optimistic_update() would accept a NULL value.
* InnoDB: dict_table_schema_check would call dtype_sql_name needlessly.
* InnoDB: The function os_file_get_status would not work with raw devices.
* InnoDB: During crash recovery, an incorrect transaction active time would result in rolling back an uncommitted transaction.
* InnoDB: Heap block debugging information (file_name, lineno), used for logging diagnostics, would appear in release builds. This information should only appear in debug builds.
* InnoDB: Renaming a column while also adding or dropping columns in the same ALTER TABLE operation would cause an error.
* InnoDB: An online ALTER TABLE operation would consume more memory than expected. During an online ALTER TABLE operation, an online log buffer containing a head and tail buffer is created for each index that is created or rebuilt. The tail buffer is the writer context and is only required for concurrent write operations on an index while the ALTER TABLE operation is in progress. The head buffer is the reader context and is only required during the log apply phase. To reduce memory consumption, the tail buffer is now allocated when the first DML statement is run on the index, and the head buffer is only allocated in the log apply phase and freed afterwards.
* InnoDB: On Windows, the full-text search (FTS) object ID was not in the expected hexadecimal format.
* InnoDB: Fetching and releasing pages from the buffer pool and tracking the page state are expensive and complex operations. Prior to the bug fix, these operations were performed using a page mutex. Using a page mutex to track several things is expensive and does not scale well. The bug fix separates fetch and release tracking (in-use state) of a page from page I/O state tracking. Fetch and release is now tracked using atomics where available.
* InnoDB: Table renaming errors would appear in the LATEST FOREIGN KEY ERROR section of the SHOW ENGINE INNODB STATUS output.
* InnoDB: UNIV_SYNC_DEBUG, which was disabled in univ.i with the fix for Bug#16720368, is now enabled.
* Partitioning: Queries using the index_merge optimization (see Index Merge Optimization) could return invalid results when run against tables that were partitioned by HASH.
* Partitioning: When no partition had returned a row since the last HA_ERR_KEY_NOT_FOUND error, the use of uninitialized memory in the priority queue used for returning rows in sorted order could lead to a crash of the server.
* Replication: When the binary log I/O cache grew to exactly 32768 bytes and the current transaction was preceded by a transaction whose size was greater than 32768 bytes, events could be corrupted when written into the binary log.
* Replication: Creating and dropping large numbers of temporary tables could lead to increased memory consumption.
* Replication: mysqlbinlog --verbose failed when it encountered a corrupt row event in the binary log. Such a row event could also cause the slave to fail.
* Replication: When log_warnings is greater than 1, the master prints binary log dump thread information—containing the slave server ID, binary log file name, and binary log position—in mysqld.1.err. A slave server ID greater than 2 billion was printed with a negative value in such cases.
* Replication: mysqlbinlog did not properly decode DECIMAL values in a row-based binary log. This could cause invalid values to be printed out for DECIMAL columns.
* Replication: Seconds_Behind_Master in the output of SHOW SLAVE STATUS could under some conditions be reported as 0 when it should have had a value greater than zero.
* Replication: The semisynchronous replication plugin was called twice for a DDL statement, incrementing Rpl_semi_sync_master_yes_tx by 2 instead of 1 each time such a statement was executed.
* Compilation errors occurred on Solaris 10; resolved by including my_config.h before system header files.
* FORCE INDEX [FOR ORDER BY] (index_name) did not work for joins.
* With the compressed client/server protocol enabled, Performance Schema statement instrumentation could raise an assertion.
* In some cases, UNIX_TIMESTAMP() could return NULL when it should return 0.
* An assertion could be raised if a filesort failed to resize its main buffer when record properties changed.
* The cache used for the Index Merge access method was freed only after successful retrieval of all rows. Interruption or failure of the operation led to a file descriptor leak.
* Using the mysqldump --set-gtid-purged option with no value caused mysqldump to crash.
* A race condition between Performance Schema statement event threads led to a server exit.
* In a view definition requireing resolution of aggregrate expressions within a subquery to an outer query, selecting from the view could cause a server exit.
* An addressing error in accessing the join buffer could produce invalid results or a server exit.
* mysql_config incorrectly included some flags to generate compiler warning output.
* With semi-join optimization enabled, queries with nested subqueries could cause a server exit due to incorrect resolution of references to columns in the middle query block.
* In some cases, the optimizer wrote fixed-length temporary MyISAM tables to disk rather than variable-length temporary tables.
* Enabling the validate_password plugin could result in incorrect password hashes being stored in the mysql.user table.
* For accounts authenticated using the sha256_password plugin, setting the password after the password had been expired did not clear the password-expired flag.
* On Mac OS X 10.7, a race condition involving vio_shutdown() and the select-based implementation of vio_io_wait() could cause a server exit.
* Host names in example URLs used within the source code were replaced by names in the example.com domain, the domain intended by IANA for this purpose.
* For utf8 and utf8mb4 strings, handler functions unnecessarily called a Unicode conversion function.
* Several -W warning flags were turned off for compilation in maintainer mode if MySQL was configured with -DWITH_INNODB_MEMCACHED=1.
* Calling the ExtractValue() function with an invalid XPath expression could in some cases lead to a failure of the server.
* Use of a nonmulti-byte algorithm for skipping leading spaces in multi-byte strings could cause a server exit.
* With ONLY_FULL_GROUP_BY SQL mode enabled, a query that uses GROUP BY on a column derived from a subquery in the FROM clause failed with a column isn't in GROUP BY error, if the query was in a view.
* For the utf8_bin collation, ORDER BY LOWER(col_name) could produce incorrect ordering.
* Several issues identified by the Coverity static analysis tool were fixed. Thanks to Honza Horak for the patch.
* On Windows, the --local-service server option did not work, and was not displayed in the --help message.
* It was not possible to query a view with an ORDER BY clause that referenced an alias in the SELECT clause of the view definition, unless all columns in the view were named in the select list.
* To handle this problem, the server now writes a view differently into the .frm file that stores the view definition. If you experience view-evaluation errors such as just described, drop and recreate the view so that the .frm file contains the updated view representation.
* The prototype of the Performance Schema instrumentation API mysql_cond_timedwait() call was fixed to be drop-in compatible with pthread_cond_timedwait(). This fix affects only implementers of third-party plugins.
* The make_atomic_cas_body64 implementation on IA32 with gcc but without gcc builtins could be miscompiled due to an incorrect constraint. The patch also causes MySQL to use builtin atomics when compiled using Clang.
* Complex updates of Performance Schema tables involving joins or subqueries failed to update every row.
* For the path specified with the --basedir option, mysql_plugin attempted to unlink the path rather than free the memory in which the path was stored.
* COUNT(DISTINCT) sometimes produced an incorrect result when the last read row contained a NULL value.
* sql_resolver.cc referred to partitioning code that should have been protected by an #ifdef, even when MySQL was configured with -DWITH_PARTITION_STORAGE_ENGINE=OFF.
* In incorrect result could be returned for a query with an IF() predicate in the WHERE clause combined with OUTER JOIN in a subquery that is transformed to a semi-join. (A workaround is to disable semi-join using SET optimizer_switch='semijoin=off';)
* A full-text search combined with derived tables (subqueries in the FROM clause) caused a server exit.
* Now if a full-text operation depends on a derived table, the server produces an error indicating that a full-text search cannot be done on a materialized table.
* Some scripts displayed out-of-date information regarding where to report bugs.
* Some files in the Performance Schema file_instances table were not being removed because the file-removal operation was not instrumented.
* mysqldump --single-transaction acquired metadata locks for each dumped table but did not release them until the dump operation finished. Consequently, other DDL operations on a dumped table blocked even after the table itself had been dumped. mysqldump now attempts to release metadata locks earlier.
* Updating a FEDERATED table with UPDATE... JOIN caused a server exit when the local table contained a single row and that row could be joined to a row in the FEDERATED table.
* mysql_install_db referred to the obsolete mysqlbug script for reporting problems.