MySQL 5.6.15

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)

# Bugs Fixed
* InnoDB: A regression fix resulted a memory leak for memcached insert operations.
* InnoDB: The trx->error_key_num field was not initialized in the error injection code found in storage/innobase/handler/handler0alter.cc. The error_key_num field is usually 0 but can be a non zero value if the memory buffer of a DDL transaction object is reused.
* InnoDB: Fault-tolerant code found in the log apply code for InnoDB ALTER TABLE ... IN PLACE could result in data corruption.
* InnoDB: Databases names beginning with a digit would cause a full-text search (FTS) parser error.
* InnoDB: An ALTER TABLE ... CHANGE [COLUMN] operation would result in an rbt_empty(index_cache->words) assertion.
* InnoDB: Running SHOW ENGINE INNODB STATUS on one connection thread and killing that thread by running a KILL CONNECTION statement from a different connection thread would result in a severe error.
* InnoDB: An excessive amount of memory would be consumed when querying INFORMATION_SCHEMA.INNODB_FT_INDEX_TABLE. The problem would occur for very large full-text search indexes.
* InnoDB: CHECK TABLE would ignore the QUICK option.
* InnoDB: The information_schema.innodb_metrics index_merge counter was not incremented in btr0btr.cc. This patch also introduces new counters (index_page_reorg_attempts, index_page_reorg_successful and index_page_discards) and renames the index_merges counter to “index_page_merge_attempts” to distinguish it from the index_page_merge_successful counter.
* InnoDB: Setting the O_DIRECT flag on a file on tmpfs on some operating systems would result in an error printed to the error log. Creating multiple temporary tables on tmpfs would cause the error to be printed repeatedly. The error message has been changed to a warning that is only printed once when running CREATE TABLE multiple times.
* InnoDB: In debug builds, test case failures would occur due to ibuf_contract_ext performing merges and dict_stats_update returning evicted pages back into the buffer pool while ibuf_change_buffering_debug is enabled.
* InnoDB: InnoDB would fail to return an error when attempting to run a query after discarding the tablespace.
* InnoDB: A severe error would occur after discarding a tablespace.
* InnoDB: During a TRUNCATE TABLE operation, InnoDB: Trying to TRUNCATE a missing index of table ... warnings would be printed to the error log. These warnings should not be printed when the index is a full-text search (FTS) index.
* InnoDB: Full-text index creation on a large table would fail due to insufficient temporary table space and result in a misleading “incorrect key file” error.
* InnoDB: The InnoDB mecached plugin would update a record before inserting to the binlog, which would cause slave server replication to stop. The insert should occur before the update.
* InnoDB: During parallel full-text search (FTS) index creation, a scanner thread reads in documents and passes them to the tokenizer. The tokenizer frees documents from memory when tokenization is complete. When tokenizing documents with a large amount of text, the tokenizer thread would not keep pace with the scanner thread. As a result, memory would not be freed fast enough and the “tokenization pending list” would grow in size.
* InnoDB: A full-text search (FTS) BOOLEAN MODE query with an invalid character in the query string could result in a memory access violation failure.
* InnoDB: trx_create and trx_free would be called for every memcached get request.
* InnoDB: The hardcoded size for the srv_max_n_threads variable was insufficient. The variable setting is now configured based on the maximum number of connection threads and InnoDB background threads.
* InnoDB: In btr_validate_level there are checks to ensure that all B-tree pages are marked when allocated. The checks would fail on the change buffer because the allocation of change buffer pages is handled differently than other B-tree pages.
* InnoDB: When the change buffer is enabled, InnoDB would fail to write a transaction log record when merging a record from the insert buffer to a secondary index page if the insert was performed as an “update-in-place”.
* InnoDB: A SELECT COUNT (*) query would run very slowly when run concurrently with a LOAD DATA operation.
* InnoDB: An existing full-text index would become invalid after running ALTER TABLE ADD FULLTEXT due to an unsynchronized full-text cache.
* InnoDB: Due to a regression in MySQL 5.6, creating or dropping tables with innodb_force_recovery set to 3 (SRV_FORCE_NO_TRX_UNDO) would fail. Additionally, this bug fix includes a code modification that sets InnoDB to read-only when innodb_force_recovery is set to a value greater than 3 (SRV_FORCE_NO_TRX_UNDO).
* InnoDB: An InnoDB memcached configuration error message contained an incorrect file name. The error message stated, Please create config table containers in database innodb_memcache by running innodb_config.sql. error 31. The correct file name is innodb_memcached_config.sql. Also, the “error 31” portion of the error message has been translated to its text equivalent, which is “Table not found”.
* InnoDB: In mutex_spin_wait(), the sync_array_reserve_cell function could fail to find an empty slot on systems with sync wait arrays that are small in size, resulting in an error.
* InnoDB: When index_read_map is called for an exact search and fails to return a record due to non-matching search criteria, the cursor would be positioned on the next record after the searched key. A subsequent call to index_next would return the next record instead of returning the previous non-matching row, thereby skipping a record.
* InnoDB: Full-text search (FTS) index savepoint information would not be set resulting in a severe error when attempting to rollback to the savepoint.
* InnoDB: Converting a table with a large number of columns from MyISAM to InnoDB would cause an assertion due to insufficient log buffer space. Instead of asserting, InnoDB now attempts to increase log buffer size automatically if the redo log size is too large.
* Partitioning: The storage engine was set incorrectly during a rebuild of a partition; the table storage engine was ignored and the default storage engine used instead. Thus, in MySQL 5.1, it was possible for REBUILD PARTITION to change the partition storage engine from InnoDB to MyISAM, and for the reverse (rebuilding partitions of MyISAM tables causing the partitions to use InnoDB) to occurin MySQL 5.5 and later. Now, when rebuilding partitions, the storage engine actually used by the table is checked and used by the handler for the rebuild operation, so that the partition storage engine is not inadvertently changed.
* Partitioning: After disabling the parent table's indexes with ALTER TABLE ... DISABLE KEYS, rebuilding any of its partitions enabled the indexes on those partitions, leading MyISAM to fail with an error when the optimizer tried to use one of the affected indexes.
* Replication: A replication master did not handle correctly the disabling of the semisync plugin on the master and the slave, with a subsequent stopping of the slave.
* Replication: The final argument in the SET clause of a LOAD DATA ... SET statement was repeated in the binary log.
* Replication: When an error encountered by the dump thread while reading events from the active binary log file was a temporary error, so that the dump thread tried to read the event, it was possible for the dump thread to seek the wrong position, which could cause one or more events to be resent. To prevent this, the thread's position is obtained after each correct read of an event.
* Replication: When stopping the I/O thread, it was possible with a very large transaction (equivalent to a binary log size greater than 100MB) that the thread did not receive the transaction to the end. When reconnecting with MASTER_AUTO_POSITION=1 it then tried to fetch changes from the next transaction, which could lead to loss of the incomplete transaction and its data.
* Replication: Setting rpl_semi_sync_master_enabled while the master was waiting for a reply from the slave could in some cases cause the master to fail.
* Replication: Trying to set CHANGE MASTER TO ... MASTER_AUTO_POSITION = 0 failed with error 1777 (ER_AUTO_POSITION_REQUIRES_GTID_MODE_ON).
* Replication: The value of LAST_INSERT_ID() was not correctly replicated when filtering rules were used on the slave.
* Replication: An internal function used for storing GTID values could sometimes try to handle them as strings of the wrong length.
* Replication: During row-based replication with binlog_row_image set to MINIMAL, updating only some columns of a table having 9 or more columns caused mysqlbinlog to fail when it was used with the --verbose option.
* Replication: Issuing a GRANT statement with invalid parameters caused the master to write LOST_EVENTS events into its binary logs, causing replication to stop. Now such cases, if one or more grants or revocations of privileges are successful, an incident is written to the log; otherwise, only a warning is logged.
* libmysqlclient version 18 files were removed from MySQL-shared-compat RPM packages to avoid a conflict between the MySQL-shared and MySQL-shared-compat RPM packages.
* Enabling Index Merge optimizer switches and setting a small sort_buffer_size value could lead to a server exit.
* Semi-join materialization strategy was not used for VARCHAR columns longer than 512 bytes, resulting in use of a less-efficient strategy and worse query performance. (The limit in characters rather than bytes depends on the column character set; 170 characters for utf8, for example.)
* Some license and documentation files were missing from Windows MSI packages.
* Selecting from the Performance Schema session_connect_attrs table under high load could cause a server exit.
* Compilation failures under Visual Studio 2012 were corrected.
* The CLIENT_CONNECT_WITH_DB flag was improperly handled in the C client library. This could lead to a malformed packet sent to the server.
* An assertion was raised if SET PASSWORD was used for an account that has been manually deleted from the mysql.user table but still present in memory.
* The mysql_options() C API function could leak memory if called more than once with the MYSQL_SET_CLIENT_IP option.
* The CONV() function could call abs(INT_MIN), which is undefined, and cause a server exit.
* An error array in the SSL code was missing a comma, leading to implicit concatenation of adjacent messages and a resulting off-by-one error in the relationship between error numbers and messages.
* The filesort implementation sometimes failed to allocate enough buffer space, leading to a server exit.
* GRANT without an IDENTIFIED BY clause resulted in an error even for existing users.
* GROUP_CONCAT() with an invalid separator could cause a server exit.
* An internal InnoDB string routine could write past the end of a buffer.
* GIS intersection-related code was missing a return value check, leading to a loop in nondebug builds and a raised assertion in debug builds.
* Using the binary client/server protocol, the second execution of a prepared statement for a query with parameters in the LIMIT clause raised an assertion.
* For upgrades using the Windows MSI package installer, the upgrade dialog message was missing the “from” version.
* Very long database names in queries could cause the server to exit.
* Standalone Windows MSI packages did not have the ALLUSERS property set. They now set ALLUSERS=1. For earlier MSI packages in this MySQL series, a workaround is to use the following command:
- C:> msiexec /i msi_installer_name ALLUSERS=1
* Recursion by functions called as arguments to XPath expressions was not handled correctly, sometimes causing such expressions to fail.
* For an ALTER TABLE statement that renamed or changed the default value of a BINARY column, the alteration was done using a table copy and not in place.
* Some possible cases of memory use after being freed were fixed. Thanks to Jan Staněk for the patch.
* In debug builds, static initialization code could call DBUG functions before the DBUG subsystem was initialized.
* With the thread pool plugin enabled, the the PROCESSLIST_USER and PROCESSLIST_HOST columns of the Performance Schema threads table were always NULL for client sessions. Also, for the main thread, those columns were not NULL but set to a user account.
* COUNT(DISTINCT) should not count NULL values, but they were counted when the optimizer used Loose Index Scan.
* For queries of the form UPDATE ... WHERE unique_key ORDER BY ... LIMIT ..., incorrect rows could be updated. Unique keys permit multiple NULL values, but the optimizer did not always consider all of them.
* If asked to upgrade a server that was running without InnoDB enabled, mysql_upgrade issued complaints about InnoDB tables not existing (tables that will not exist unless InnoDB is available).
* In some cases, range conditions over indexes defined on column prefixes returned incomplete result sets. (For example, SELECT ... WHERE 'abcdef1' < col_name AND col_name < 'abcdef9', where the index on col_name indexed only the first 6 characters.)
* Performance Schema instrumentation overhead was reduced for frequent connect/disconnect operations.
* Setting host_cache_size at startup had no effect.
* InnoDB full-text searches failed to find records within transactions that included savepoints.
* Some INSERT INTO ... SELECT ... FROM statements were slow unless the tmp_table_size and max_heap_table_size system variables were set large enough to permit the temporary table used for query processing to be stored in the MEMORY storage engine.
* Incorrect reference counting in the range optimizer module resulted in potential for missing or duplicate rows in the query result set.
* Host names in grant tables are stored in lowercase, but mysql_install_db could fail to observe this convention, leading to accounts that could not be dropped with DROP USER.
* The server uses the ethernet hardware address for UUID generation, but made assumptions about the names of ethernet devices rather than querying the system for their names.
* Several issues identified by the Coverity static analysis tool were fixed. Thanks to Jan Staněk and Honza Horak for the patches.
* Missing va_end() calls were added to logging and UCS2 code. Thanks to Jan Staněk for the patch.
* MySQL did not compile on Mac OS X 10.9 (Mavericks).
* Killing a query that is performing a filesort operation resulted in an ER_SERVER_SHUTDOWN (Server shutdown in progess) error.