MySQL 5.6.20 (64-bit) 軟體資訊交流 Mac

winXmac軟體社群 Mac 開發工具 Oracle 開源軟體 Rate 90

MySQL for Mac,軟體教學,軟體下載,軟體社群,Windows軟體,Mac軟體

MySQL 5.6.20 (64-bit) Mac

MySQL for Mac 是專為企業組織提供業務關鍵數據庫應用程序。它為企業開發人員,數據庫管理員和 ISV 提供了一系列新的企業功能,以提高開發,部署和管理工業強度應用程序的效率.

如果您需要 MySQL 數據庫的 GUI,可以下載 - NAVICAT(MySQL GUI)。它支持將 MySQL,MS SQL,MS Access,Excel,CSV,XML 或其他格式導入到 MySQL.

MySQL 數據庫服務器提供了新的企業功能,包括:ACID 事務處理,以構建可靠和安全的業務關鍵型應用程序。存儲過程來提高開發人員的生產力。觸發器在數據庫級執行複雜的業務規則。保證敏感信息的觀點不受影響。信息架構,以便於訪問元數據。支持跨多個數據庫的複雜事務的分佈式事務(XA).

Top 10 使用的理由 MySQL for Mac:

可擴展性和靈活性 51235896 MySQL 數據庫服務器提供了極高的可擴展性,體現了處理深度嵌入式應用程序的能力,僅佔用 1MB 的空間來運行海量數據倉庫擁有太字節的信息.

獨特的存儲引擎架構允許數據庫專業人員專門為特定應用程序配置 MySQL 數據庫服務器,最終的結果是驚人的性能結果.

堅如磐石的可靠性和持續可用性是 MySQL 的標誌,客戶依靠 MySQL 來保證全天候的正常運行.

Robust 交易支持
MySQL 提供了市場上最強大的交易數據庫引擎之一。  功能包括完整的 ACID(原子性,一致性,隔離性,持久性)事務支持,無限的行級鎖定以及更多功能.

Web 和數據倉庫優勢
MySQL 是高流量網站的事實標準,因為它的高性能查詢引擎,極大的快速的數據插入能力,以及對快速全文搜索等專業化網頁功能的強大支持.

因為守衛企業的數據資產是數據庫專業人員的頭號工作,MySQL for Mac 提供了絕對的數據保護的卓越的安全特性.

MySQL 是世界上最流行的開源數據庫的原因之一就是它為每個應用程序開發提供了全面的支持。在數據庫中,支持存儲過程,觸發器,函數,視圖,游標,ANSI 標準 SQL 等等。分鐘.

開源自由和 24×7 支持

Lowest 總擁有成本
By 將當前的數據庫驅動器應用程序遷移到 MySQL,或使用 MySQL 進行新的開發項目,企業正在實現成本節省,多次延伸到七位數.

也可用:下載 Windows 版 MySQL

檔案版本 MySQL 5.6.20 (64-bit)
檔案名稱 mysql-5.6.20-osx10.7-x86_64.dmg
檔案大小 157.91 MB
系統 Mac OS X 10.12 or later
軟體類型 開源軟體
作者 Oracle
軟體類型 2014-08-05

What's new in this version:

Security Notes:
- Security Fix: The linked OpenSSL library for the MySQL 5.6 Commercial Server has been updated from version 1.0.1g to version 1.0.1h. Versions of OpenSSL prior to and including 1.0.1g are reported to be vulnerable to CVE-2014-0224.
- This change does not affect the Oracle-produced MySQL Community build of MySQL Server 5.6, which uses the yaSSL library instead. (CVE-2014-0224)

InnoDB Notes:
- Important Change: Redo log writes for large, externally stored BLOB fields could overwrite the most recent checkpoint. The 5.6.20 patch limits the size of redo log BLOB writes to 10% of the redo log file size. The 5.7.5 patch addresses the bug without imposing a limitation. For MySQL 5.5, the bug remains a known limitation.
- As a result of the redo log BLOB write limit introduced for MySQL 5.6, innodb_log_file_size should be set to a value greater than 10 times the largest BLOB data size found in the rows of your tables plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields). Failing to do so could result in “Row size too large” errors. No action is required if your innodb_log_file_size setting is already sufficiently large or your tables contain no BLOB data.
- Functionality Added or Changed:
- Replication: The new system variable binlog_impossible_mode controls what happens if the server cannot write to the binary log, for example, due to a file error. For backward compatibility, the default for binlog_impossible_mode is IGNORE_ERROR, meaning the server logs the error, halts logging, and continues updates to the database. Setting this variable to ABORT_SERVER makes the server halt logging and shut down if it cannot write to the binary log.
- CMake support was updated to handle CMake version 3.
- New Debian7, Ubuntu12.04, and Ubuntu14.04 distribution support that was introduced with 5.6.17 now comes with the platform-specific packaging source placed under the packaging directory, in the deb-precise, deb-wheezy, and deb-trusty directories.
- Support for LinuxThreads has been removed from the source code. LinuxThreads was superseded by NPTL in Linux 2.6.
- By default, mysql_install_db creates a my.cnf file in the installation base directory using a template. This may be undesireable for some deployments. To enable this behavior to be suppressed, mysql_install_db now supports a --keep-my-cnf option to preserve any existing my.cnf file and not create a new my.cnf file.
- The mysqlhotcopy utility is now deprecated and will be removed in a future version of MySQL. Among the reasons for this: It works only for the MyISAM and ARCHIVE storage engines; it works on Unix but not Windows. Alternatives include mysqldump and MySQL Enterprise Backup.
- The timed_mutexes system variable has no effect and is deprecated.

Bugs Fixed:
- Important Change; Replication: A DROP TABLE statement may be divided into multiple statements before it is sent to the binary log if it contains regular (not temporary) tables and temporary tables, or if it contains temporary tables using both transactional and non-transactional storage engines. Now, when using GTIDs, DROP TABLE statements affecting these combinations of tables are no longer allowed unless the value of the gtid_next system variable is AUTOMATIC. This is because, with GTIDs enabled on the server, issuing a DROP TABLE in the cases just described while having only one GTID associated with each statement (the SQL thread does this following SET gtid_next='uuid:number') causes problems when there are not enough GTIDs for assignment to all the resulting statements following the division of the original DROP TABLE.
- A DROP TABLE statement might be split due to the behavior of the statement with respect to the current transaction varying, depending on table characteristics, as follows:
- DROP TABLE of a regular (not temporary) table is committed immediately
- DROP TABLE of a temporary table using a transactional storage engine is committed with the current transaction (following COMMIT)
- DROP TABLE of a temporary table that uses a nontransactional storage engine is committed immediately
- Naming all three of these types of tables in a single DROP TABLE statement causes the MySQL server to divide the original statement into three separate DROP TABLE statements in the binary log. If GTIDs are enabled but the value of gtid_next is not AUTOMATIC, issuing a DROP TABLE statement that mixes any of the table types described previously causes the server to have an insufficient number of GTIDs to write with all of the resulting statements into the binary log. In addition, DROP TABLE IF EXISTS is always written in the binary log for all tables specified in the statement, even if some or all of the tables do not exist.
- Because temporary tables are handled differently by DROP TABLE depending on whether they use a transactional or nontransactional storage engine, any tables named by a DROP TEMPORARY TABLE statement that do not exist are assumed to be transactional. This means that, if a DROP TEMPORARY TABLE with two nontransactional temporary tables is issued on the master, it would writes only one DROP TABLE statement naming both tables. If one of the temporary tables no longer exists on the slave, then, when the SQL thread executes the statement, it tries to divide it into multiple statements due to it affecting a nontransactional (but existing) temporary table and a nonexistent transactional temporary table; this leads to problems because the SQL thread has only one GTID for the original DROP TABLE statement but must write two DROP TABLE statements in the binary log.
- In addition, when the slave dropped temporary tables after detecting that the master had restarted, it logged one DROP TABLE statement per pseudo-thread and per database, but combined temporary tables using transactional and nontransactional storage engines in a single DROP TABLE statement.
- Now, we throw an error in the client session if gtid_next is set to a uuid:number value and a DROP TABLE statement is issued mixing any of the table types described previously.
- In addition, we now group the nonexistent temporary tables and assume them to be transactional only if at least one transactional temporary table is dropped by the statement. If no transactional temporary tables are dropped, any nonexistent temporary tables are assumed to be nontransactional temporary tables.
- The slave now also handles dropping of temporary tables correctly in the event of the restart by the master.
- InnoDB: Opening a parent table that has thousands of child tables could result in a long semaphore wait condition.
- InnoDB: For single item full-text searches, deleted documents were included in inverse document frequency (IDF) calculations.
- InnoDB: On mysqld start, specifying multiple data files using the innodb_data_file_path option would return a Space id in fsp header error after data is written to the second file.
- InnoDB: A DELETE operation on a table with full-text search indexes raised an assertion.
- InnoDB: When calling the memcached flush_all command, InnoDB attempts to initialize a connection and a transaction. If the transaction is in TRX_STATE_NOT_STARTED state, InnoDB would fail to set CONN_DATA->CRSR_TRX to NULL, resulting in a serious error.
- InnoDB: When InnoDB is built as a shared library, attempting to load the InnoDB full-text search (FTS) INFORMATION_SCHEMA plugin would fail with a Can't open shared library '' error.
- InnoDB: A regression introduced in MySQL 5.6.5 would cause full-text search index tables to be created in the system tablespace (space 0) even though innodb_file_per_table was enabled.
- InnoDB: The InnoDB memcached plugin would call plugin_del without acquiring the lock_plugin mutex. This bug fix also addresses a race condition in ib_cursor_delete_row.
- InnoDB: The fix for Bug#16418661 added superfluous buf_flush_list() logic to InnoDB startup code.
- InnoDB: A race condition in fts_get_next_doc_id resulted in Duplicate FTS_DOC_ID and Cannot find index FTS_DOC_ID_INDEX in InnoDB index translation table errors.
- InnoDB: Due to differences in memory ordering on different processor types, some mutex and read-write lock flags were not read consistently.
- Partitioning: Selecting from a table having multiple columns in its primary key and partitioned by LIST COLUMNS(R), where R was the last (rightmost) column listed in the primary key definition, returned an incorrect result.
- Replication: mysqlbinlog --raw did not check for errors caused by failed writes, which could result in silent corruption of binary logs. Now in such cases it stops with an error.
- Replication: When a slave worker thread tried to execute a statement that was too large, the resulting error caused a crash. Now in such cases, the error is truncated to fit the size of the buffer.
- Replication: When using row-based replication, updating or deleting a row on the master that did not exist on the slave led to failure of the slave when it tried to process the change. This problem occurred with InnoDB tables lacking a primary key.
- Replication: Quotation marks were not always handled correctly by LOAD DATA INFILE when written into the binary log.
- Replication: Beginning in MySQL 5.6.20, when a user specified AUTO_INCREMENT value falls outside of the range between the current AUTO_INCREMENT value and the sum of the current and number of rows affected values it is replicated correctly. In previous versions, an error was generated by the slave even if the user specified AUTO_INCREMENT value fell outside of the range.
- Replication: A group of threads involved in acquiring locks could deadlock when the following events occurred:
- Dump thread reconnects from slave; on master, a new dump thread tries to kill zombie dump threads; having acquired the thread's LOCK_thd_data, it is about to acquire LOCK_log.
- Application thread executing show binary logs, having acquired LOCK_log and about to acquire LOCK_index.
- Application thread executing PURGE BINARY LOGS; having acquired LOCK_index, it is about to acquire LOCK_thread_count.
- Application thread executing SHOW PROCESSLIST (or SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST), having acquired LOCK_thread_count and about to acquire the zombie dump thread's LOCK_thd_data.
- This leads to the 4 threads deadlocking in the same order which the threads have been listed here.
- This problem arises because there are ordering rules for LOCK_log and LOCK_index, as well as rules for ordering LOCK_thread_count and LOCK_thd_data, but there are no rules for ordering across these two sets of locks. This was because the internal mysqld_list_processes() function invoked by SHOW PROCESSLIST acquired LOCK_thread_count for the complete lifetime of the function as well as acquiring and releasing each thread's LOCK_thd_data. Now this function takes a copy of the threads from the global thread list and performs its traversal on these, and only after releasing LOCK_thread_count. During this traversal, removal from the global thread list is blocked using LOCK_thd_remove such that the copies that would otherwise be destroyed by the removal remain valid during traversal. The locking order following this fix is shown here:
- LOCK_thd_remove -> LOCK_thd_data -> LOCK_log -> LOCK_index -> LOCK_thread_count
- Replication: On Windows, mysqldump failed if the error log file was deleted (missing) from the active MySQL server.
- Replication: Client applications should be able to set the BINLOG_DUMP_NON_BLOCK flag in the initial handshake packet (COM_BINLOG_DUMP). Clients connecting to a server issuing a COM_BINLOG_DUMP with the flag unset do not get an EOF when the server has sent the last event in the binary log, which causes the connection to block. This flag, which was removed in error in MySQL 5.6.5, is now restored in the current release.
- As part of this fix, a new --connection-server-id option is added to mysqlbinlog. This option can be used by the client to test a MySQL server for the presence of this issue.
- When a SELECT included a derived table in a join in its FROM list and the SELECT list included COUNT(DISTINCT), the COUNT() returned 1 even if the underlying result set was empty.
- Enabling optimizer trace could cause a server exit for queries with a subquery in a HAVING clause.
- SHA and MD5 functions failed for operations using the internal filename character set and could cause a server exit.
- Large arguments passed to mysqldump could lead to buffer overflow and program exit.
- Compiler flags were not passed to DTrace, causing problems for 32-bit builds cross-compiled on 64-bit platforms.
- ALTER TABLE on a partitioned table could result in the wrong storage engine being written into the table's .frm file and displayed in SHOW CREATE TABLE.
- With the max_heap_table_size system variable set to a large value (20GB), creation of a temporary table or a table using the MEMORY storage engine caused a server exit.
- For debug builds, a 0x00 character in a full-text query string that used the ujis_japanese_ci, utf8mb4_turkish_ci, or eucjpms_bin collation could raise an assertion.
- mysqladmin password masked the old password given on the command line, but not the new password.
- yaSSL code had an off-by-one error in certificate decoding that could cause buffer overflow.
- yaSSL code had an opendir() without a corresponding closedir().
- For full-text queries on InnoDB tables, attempts to access deleted document IDs could lead to a server exit.
- MyISAM temporary files could be used to mount a code-execution attack.
- For queries that selected from the Performance Schema events_statements_current table, adding an ORDER BY clause could produce incorrect results.
- If a query had both MIN()/MAX() and aggregate_function(DISTINCT) (for example, SUM(DISTINCT)) and was executed using Loose Index Scan, the result values of MIN()/MAX() were set improperly.
- For UNION statements, the rows-examined value was calculated incorrectly. This was manifest as too-large values for the ROWS_EXAMINED column of Performance Schema statement tables (such as events_statements_current).
- Clients could determine based on connection error message content whether an account existed.
- An assertion could be raised when creating a index on a prefix of a TINYBLOB or GEOMETRY column in an InnoDB column.
- Use of a nonmultibyte algorithm for skipping leading spaces in multibyte strings could cause a server exit. (Bug #12368495, Bug #18315770)
- For a view defined on a UNION, the server could create an invalid view definition.
- Configuring with cmake -DWITHOUT_SERVER to build clients without the server failed for builds outside of the source tree.
- With big_tables enabled, queries that used COUNT(DISTINCT) on a simple join with a constant equality condition on a non-duplicate key returned incorrect results.
- Deadlock could occur if three threads simultaneously performed INSTALL PLUGIN, SHOW VARIABLES, and mysql_change_user().
- mysql_config_editor exited when given an empty argument to the --login-path option.
- MySQL did not compile with Bison 3. A workaround is to downgrade to Bison 2.
- Uninstalling and reinstalling semisynchronous replication plugins while semisynchronous replication was active caused replication failures. The plugins now check whether they can be uninstalled and produce an error if semisynchronous replication is active. To uninstall the master-side plugin, there must be no semisynchronous slaves. To uninstall the slave-side plugin, there must be no semisynchronous I/O threads running.
- If there was a predicate on a column referenced by MIN() or MAX() and that predicate was not present in all the disjunctions on key parts earlier in the compound index, Loose Index Scan returned an incorrect result.
- Client auto-reconnect did not work for clients linked against libmysqlclient, even with MYSQL_OPT_RECONNECT enabled.
- Upgrades using RPM packages could change the ownership of an installation directory.
- Proxy users were unable to execute statements if the proxied user password had expired.
- A new CMake option, SUNPRO_CXX_LIBRARY, enables linking against libCstd instead of stlport4 on Solaris 10 or later. This works only for client code because the server depends on C++98. Example usage:
- File permissions and line endings of several test and configuration files were made more consistent to avoid warnings from package checkers. (Bug #68521, Bug #16415173, Bug #16395459, Bug #68517, Bug #16415032, Bug #71112, Bug #17919313, Bug #71113, Bug #17919422)

檔案下載 檔案下載