MySQL 5.5.30 (32-bit) 軟體資訊交流 Mac

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

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

MySQL 5.5.30 (32-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.5.30 (32-bit)
檔案名稱 mysql-5.5.30-osx10.6-x86.dmg
檔案大小 110.04 MB
系統 Mac OS X 10.12 or later
軟體類型 開源軟體
作者 Oracle
更新日期 http://www.mysql.com/
軟體類型 2013-02-01
更新日誌

What's new in this version:

Functionality Added or Changed:
- InnoDB: The innodb_print_all_deadlocks configuration option from MySQL 5.6 was backported to MySQL 5.5. This option records each deadlock condition in the MySQL error log, allowing easier troubleshooting if frequent deadlocks point to application coding issues. (Bug #14515889)
- In RPM packages built for Unbreakable Linux Network, libmysqld.so now has a version number. (Bug #15972480)

Bugs Fixed:
- InnoDB; Performance: Some data structures related to undo logging could be initialized unnecessarily during a query, although they were only needed under specific conditions. (Bug #14676084)
- InnoDB; Performance: Optimized read operations for compressed tables by skipping redundant tests. The check for whether any related changes needed to be merged from the insert buffer was being called more often than necessary. (Bug #14329288, Bug #65886)
- InnoDB; Performance: Immediately after a table was created, queries against it would not use loose index scans. The issue went away following an ALTER TABLE on the table. The fix improves the accuracy of the index statistics gathered when the table is first created, and prevents the query plan from being changed by the ALTER TABLE statement. (Bug #14200010)
- InnoDB; Partitioning: Previously, when attempting to optimize one or more partitions of a partitioned table that used a storage engine that does not support partition-level OPTIMIZE, such as InnoDB, MySQL reported Table does not support optimize, doing recreate + analyze instead, then re-created the entire table, but did not actually analyze it. Now in such cases, the warning message is, Table does not support optimize on partitions. All partitions will be rebuilt and analyzed. In addition, the entire table is analyzed after first being rebuilt. (Bug #11751825)
- InnoDB: On systems that cannot handle unaligned memory access, depending on the stack frame alignment, a SIGBUS error could occur during startup. This issue was observed on Solaris 64-bit systems. (Bug #16021177)
- InnoDB: The status variable Innodb_buffer_pool_read_ahead_evicted could show an inaccurate value, higher than expected, because some pages in the buffer pool were incorrectly considered as being brought in by read-ahead requests. (Bug #15859402, Bug #67476)
- InnoDB: Creating an index on a CHAR column could fail for a table with a character set with varying length, such as UTF-8, if the table was created with the ROW_FORMAT=REDUNDANT clause. (Bug #15874001)
- InnoDB: The server could halt with an assertion error while creating an index: InnoDB: Assertion failure in thread thread_num in file row0merge.cc line 465
- InnoDB: If the server crashed at a precise moment during an ALTER TABLE operation that rebuilt the clustered index for an InnoDB table, the original table could be inaccessible afterward. An example of such an operation is ALTER TABLE ... ADD PRIMARY KEY The fix preserves the original table if the server halts during this operation. You might still need to rename the .ibd file manually to restore the original table contents: in MySQL 5.6 and higher, rename from #sql-ib$new_table_id.ibd to table_name.ibd within the database directory; prior to MySQL 5.6, the temporary file to rename is table_name#1 or #2. (Bug #14669848)
- InnoDB: An error at the filesystem level, such as too many open files, could cause an unhandled error during an ALTER TABLE operation.
- InnoDB: A RENAME TABLE statement could stall for several minutes before timing out. This issue could occurred for a table using compression, with change buffering enabled. (Bug #14556349)
- InnoDB: During shutdown, with the innodb_purge_threads configuration option set greater than 1, the server could halt prematurely with this error: mysqld got signal 11
- InnoDB: If the value of innodb_force_recovery was less than 6, opening a corrupted table might loop forever if a corrupted page was read when calculating statistics for the table. Information about the corrupted page was written repeatedly to the error log, possibly causing a disk space issue. The fix causes the server to halt after a fixed number of failed attempts to read the page. To troubleshoot such a corruption issue, set innodb_force_recovery=6 and restart. (Bug #14147491, Bug #65469)
- InnoDB: The value of the innodb_version variable was not updated consistently for all server releases for the InnoDB Plugin in MySQL 5.1, and the integrated InnoDB component in MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server development cycles are fully integrated and synchronized, now the value returned by the innodb_version variable is the same as for the version variable. (Bug #13463493, Bug #63435)
- Partitioning: Concurrent ALTER TABLE ... REBUILD PARTITION operations could interfere with one another, even when not running against the same table, because they both used global memory for storage. Now each partition rebuild operation stores intermediate data in memory that is local to that process. (Bug #14589559, Bug #66645)
- Partitioning: Inserting any number of rows into an ARCHIVE table that used more than 1000 partitions and then attempting to drop the table caused the MySQL Server to fail. (Bug #13819630, Bug #64580)
- Replication: After dropping a column from the slave's version of a table, then altering the same column of this table on the master (so that a type conversion would have been required had the column not been droppped on the slave), inserts into this table caused replication to fail. (Bug #15888454)
- Replication: When a binary log is replayed on a server (for example, by executing a command like mysqlbinlog binlog.000001 | mysql), it sets a pseudo-slave mode on the client connection used, so that the server can read binlog and apply binary log events correctly. However, the pseudo-slave mode was not disabled after the binary log dump was read, which caused unexpected filtering rules to be applied to SQL statements subsequently executed on the same connection. (Bug #15891524)
- Replication: When using statement-based replication, and where the master and the slave used table schemas having different AUTO_INCREMENT columns, inserts generating AUTO_INCREMENT values logged for a given table on the master could be applied to the wrong table on the slave. (Bug #12669186)
- Replication: Repeated execution of CHANGE MASTER TO statements using invalid MASTER_LOG_POS values could lead to errors and possibly a crash on the slave. Now in such cases, the statement fails with a clear error message. (Bug #11764602, Bug #57454)
- Replication: If the disk becomes full while writing to the binary log, the server hangs until space is freed up manually. It was possible after this was done for the MySQL server to fail, due to an internal status value being set when not needed. Now in such cases, rather than trying to set this status, a warning is written in the error log instead. (Bug #11753923, Bug #45449)
- Microsoft Windows: Dynamic file names (with colons) are no longer allowed. Static file names using the Alternate Data Stream (ADS) NTFS functionality of Microsoft Windows may continue to be used. (Bug #11761752)
- Directory name manipulation could result in stack overflow on Mac OS X and Windows. (Bug #16066243)
- Joins of exactly 32 tables and containing a HAVING clause returned an empty result. (Bug #15972635)
- A buffer-handling problem in yaSSL was fixed. (Bug #15965288)
- A mysys library string-formatting routine could mishandle width specifiers. (Bug #15960005)
- In certain cases, UpdateXML() could return NULL incorrectly. (Bug #15948580)
References: See also Bug #13007062.
- Metadata locking and table definition cache routines did not always check length of names passed to them. (Bug #15954872)
- XA START had a race condition that could cause a server crash. (Bug #14729757)
- Enabling the query cache during high client contention could cause the server to exit. (Bug #14727815)
- There was a performance regression for queries using SELECT ... INTO user variables and a WHERE condition on one or more of the variables in the INTO list. (Bug #14664077)
References: This bug was introduced by Bug #12408412.
- The server sometimes failed to respect MAX_CONNECTIONS_PER_HOUR limits on user connections. (Bug #14627287)
- Output generated with mysqldump --routines could produce syntax errors when reloaded. (Bug #14463669)
- With the thread pool plugin installed, a workload consisting of concurrent KILL statements and ping queries caused the server to exit. (Bug #14458232, Bug #14458002)
- CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had a corrupt key (.MYI) file. Now the server produces an error. (Bug #13556107, Bug #13556000)
- Passing an unknown time zone specification to CONVERT_TZ() resulted in a memory leak. (Bug #12347040)
- For dumps of the mysql database, mysqldump skipped the event table unless the --events option was given. To skip this table if that is desired, use the --ignore-table option instead (Bug #55587, Bug #11762933)
- For MEMORY tables with HASH indexes, DELETE sometimes failed to delete all applicable rows. (Bug #51763, Bug #11759445)
- The mysql client could mishandle the delimiter command if it occurred on a line during which mysql was looking for the end of a quoted string. (Bug #64135, Bug #13639125)
- mysqld_safe used the nonportable -e test construct. (Bug #67976, Bug #16046140)
- Configuring the server with performance_schema_events_waits_history_size=0 and performance_schema_events_waits_history_long_size=0 could cause a Performance Schema segmentation fault. (Bug #68008, Bug #16060864)
- DECIMAL multiplication operations could produce significant inaccuracy. (Bug #45860, Bug #11754279)
- For subqueries executing using a filesort, the optimizer could produce an incorrect result containing wrong rows. (Bug #66845, Bug #14636211)
References: See also Bug #12667154.
- UNION type conversion could incorrectly turn unsigned values into signed values. (Bug #49003, Bug #11757005)
- During the startup process, mysqld could incorrectly remove the PID file of an already running mysqld. (Bug #23790, Bug #11746142)

檔案下載 檔案下載