⚠ 這是歷史版本頁面 — 查看 MySQL 最新版本 →
MySQL 軟體圖示

MySQL 5.6.23

v 5.6.23
Windows ↔ 也有 macOS 版 開源軟體 8.4/10 (1021)
  • 軟體名稱MySQL
  • 目前版本5.6.23
  • 更新日期2015-02-03
  • 檔案大小44.73MB
  • 檔案名稱mysql-5.6.23-win32.msi
  • 作業系統Windows 7 64 / Windows 8 64 / Windows 10 64 / Windows 11
  • 支援語系English
  • 授權型式開源軟體
  • 開發商 Oracle
  • 軟體分類Windows 軟體 / 開發者工具

編輯短評

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 的一部分(例如 XAMPPWAMP)進行安裝,以建立完整的開發環境。

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)

畫面截圖

5 張

更新日誌

5.6.23

# Functionality Added or Changed
- Support for the SSL 2.0 and SSL 3.0 protocols has been disabled because they provide weak encryption. Support was added for the TLS 1.1 and TLS 1.2 protocols.
- yaSSL was upgraded to version 2.3.7.
- The valid date range of the SSL certificates in mysql-test/std_data has been extended to the year 2029.
# Bugs Fixed
- InnoDB: A tablespace export operation set the purge state to PURGE_STATE_STOP but the purge thread did not check the purge state until the current purge operation was completed. In the case of a large history list, the tablespace export operation was delayed, waiting for the current purge operation to finish. The purge state is now checked with every purge batch.
- InnoDB: An ALTER TABLE ... ADD INDEX operation raised an assertion due to assertion code that did not allow an online index status of ONLINE_INDEX_ABORTED_DROPPED. The assertion code has been relaxed.
- InnoDB: An error occurred when the push_warning_printf function was invoked during server recovery. This function was previously used to print a warning message to the client. Also, current_thd was NULL when the server was restarted.
- InnoDB: An ALTER TABLE operation that changed the name of a foreign key column resulted in a failure when reloading the foreign key constraint. The previous column name remained in the data dictionary cache instead of being evicted.
- InnoDB: Error messages regarding a size limitation on BLOB or TEXT data inserted in a single transaction have been revised.
- InnoDB: DML operations on a table with full-text search indexes raised an invalid assertion.
- InnoDB: A multiple-table delete operation caused the server to halt.
- InnoDB: A FLUSH TABLES operation raised an assertion.
- InnoDB: With change buffering enabled, a buffered sequence of operations that should not have been buffered resulted in an Unable to purge a record error.
- InnoDB: On non-Windows platforms, os-file_pread and os_file_pwrite functions return -1 when an error occurs. This value was printed in an error message as the number of bytes read or written. Instead of printing the -1 value in the error message, a separate error message indicating a system call failure is now printed. Thanks to David Bennett for the patch.
- InnoDB: A slow shutdown (innodb_fast_shutdown=0) after crash recovery raised an assertion. Slow shutdown did not wait for background rollback operations to finish before proceeding.
- InnoDB: The integer column value was handled incorrectly for the memcached incr and decr commands.
- Partitioning: A failed ALTER TABLE ... TRUNCATE PARTITION statement or a failed TRUNCATE TABLE statement against a partitioned table sometimes left inconsistent metadata in the table cache; subsequent SQL statements reusing this metadata failed, and could in some cases also lead to a failure of the server.
- Replication: If a client thread on a slave executed FLUSH TABLES WITH READ LOCK while the master executed a DML, executing SHOW SLAVE STATUS in the same client became blocked, causing a deadlock. The fix ensures that the read lock is only held during the period that the relay log is being updated and the deadlock is avoided.
- Replication: When an XA transaction was active, executing an internal rollback, for example using the BINLOG statement, resulted in an assertion. The fix ensures that a rollback happens only for a slave when a transaction spans multiple binary log files. Rollback does not happen now if the Format_description comes from the BINLOG statement being executed in the MySQL client.
- Replication: In normal usage, it is not possible for a slave to have more GTIDs than the master. But in certain situations, such as after a hardware failure or incorrectly cleared gtid_purged, the master's binary log could be truncated. This fix ensures that in such a situation, the master now detects that the slave has transactions with GTIDs which are not on the master. An error is now generated on the slave and the I/O thread is stopped with an error. The master's dump thread is also stopped. This prevents data inconsistencies during replication.
- Replication: When using SHOW SLAVE STATUS to monitor replication performance, Seconds_Behind_Master sometimes displayed unexpected lag behind the master. This was caused by Previous_gtids_log_events being written to the slave's relay log with a timestamp behind the master, and then being used to calculate the Seconds_Behind_Master. This fix ensures that events generated on the slave that are added to the relay log and are not used when calculating Seconds_Behind_Master.
- On Ubuntu 14.10, MySQL install operations could fail to reload AppArmor.
- EXPLAIN within an XA transaction could raise an assertion.
- Binary log files created by streaming the binary log from a remote server with mysqlbinlog were given an access mode more permissive than the original files.
- If the audit_log plugin encountered a disk-full error, the server would exit.
- Now, if the file system to which the audit log is being written fills up, a “disk full” error is written to the error log. Audit logging continues until the audit log buffer is full. If free disk space has not been made available by the time the buffer fills, client sessions will hang, and stopping the server at the time of client sessions hanging will result in audit log corruption. To avoid this if client sessions are hung, ensure that free space is available on the audit logging file system before stopping the server.
- For failure to create a temporary table due to being out of file descriptors, the server exited rather than returning an error.
- For some queries that contained a derived table (subquery in the FROM clause), delay of materialization resulted in a suboptimal execution plan due to a less accurate row-count estimate.
- For UPDATE and DELETE statements, the server could exit after attempting to access an uninitialized data structure.
- Starting the server with start service or mysqld_safe could result in failure to use the correct plugin directory.
- FLUSH TABLES on a FEDERATED table failed if the table had been idle longer than the wait_timeout time plus the TCP keepalive time.
- Selecting all columns from INFORMATION_SCHEMA.TABLES did not reopen tables if they were in the table cache, but selecting a subset of those columns under the same conditions did reopen tables.
- If my_write() encountered a disk-full condition, it could return an incorrect error value.
- InnoDB boolean full-text searches incorrectly handled + combined with parentheses; for example, +word1 +(>word2 <word3).
- MySQL failed to compile with GCC 4.9.1 in debug mode.
- For debug builds, the server could exit due to an optimizer failure to allocate enough memory for group references.
- The server no longer logs the following warnings because they are uninformative: Client failed to provide its character set. 'charset' will be used as client character set.
- A file created for an internal temporary table could cause problems if the file was orphaned for some reason and the file name was reused for later queries.

歷史版本

完整清單 →