MySQL (32-bit)

最新版本 MySQL 5.5.9

MySQL 5.5.9

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

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

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

Top 使用 MySQL 的 10 個理由:

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

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

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

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

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

強大的數據保護功能
由於保護企業的數據資產是數據庫專業人員的頭號工作,MySQL 提供了絕對的數據保護的絕佳安全特性.

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

開源自由和 24×7 支持
許多公司都不願意完全致力於開源軟件,因為他們認為他們不能得到他們目前依靠專有軟件的支持類型或專業服務安全網,以確保他們的關鍵應用程序.

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

也可用:下載 MySQL for Mac

ScreenShot

軟體資訊
檔案版本 MySQL 5.5.9

檔案名稱 mysql-5.5.9-win32.msi
檔案大小 121.49 MB
系統 Windows XP / Vista / Windows 7 / Windows 8 / Windows 10
軟體類型 開源軟體
作者 Oracle
官網 http://www.mysql.com/
更新日期 2011-02-10
更新日誌

What's new in this version:

# Bugs fixed:

* Incompatible Change: When auto_increment_increment is greater than one, values generated by a bulk insert that reaches the maximum column value could wrap around rather producing an overflow error.
As a consequence of the fix, it is no longer possible for an auto-generated value to be equal to the maximum BIGINT UNSIGNED value. It is still possible to store that value manually, if the column can accept it. (Bug#39828)
* Important Change: Partitioning: Date and time functions used as partitioning functions now have the types of their operands checked; use of a value of the wrong type is now disallowed in such cases. In addition, EXTRACT(WEEK FROM col), where col is a DATE or DATETIME column, is now disallowed altogether because its return value depends on the value of the default_week_format system variable. (Bug#54483)
See also Bug#57071.
* Partitioning: InnoDB Storage Engine: The partitioning handler did not pass locking information to a table's storage engine handler. This caused high contention and thus slower performance when working with partitioned InnoDB tables. (Bug#59013)
* InnoDB Storage Engine: When multiple InnoDB buffer pools were enabled, SHOW ENGINE INNODB commands displayed information about each one, but not summary information combining statistics for the entire buffer pool subsystem. Now, the aggregated information is displayed in the BUFFER POOL AND MEMORY section, and information about individual buffer pool instances is displayed in a new INDIVIDUAL BUFFER POOL INFO section. (Bug#58461)
* InnoDB Storage Engine: The command to create a debug build (cmake -DWITH_DEBUG ...) now automatically sets the InnoDB debugging flag UNIV_DEBUG on all platforms. Formerly, the UNIV_DEBUG flag might not be set for Windows platforms with Visual Studio and not on OS X with Xcode. (Bug#58279)
* InnoDB Storage Engine: In InnoDB status output, the value for I/O sum[] could be incorrect, displayed as a very large number. (Bug#57600)
* InnoDB Storage Engine: It was not possible to query the information_schema.innodb_trx table while other connections were running queries involving BLOB types. (Bug#55397)
* InnoDB Storage Engine: When the lowercase_system_names variable was set to 2, InnoDB could fail to restore a mysqldump dump of a table with foreign key constraints involving case-sensitive names. (Bug#55222)
* InnoDB Storage Engine: The OPTIMIZE TABLE statement would reset the auto-increment counter for an InnoDB table. Now the auto-increment value is preserved across this operation. (Bug#18274)
* Partitioning: A failed ALTER TABLE ... TRUNCATE PARTITION statement was still written to the binary log. (Bug#58147)
* Partitioning: Failed ALTER TABLE ... PARTITION statements could cause memory leaks. (Bug#56380)
See also Bug#46949, Bug#56996.
* Replication: While an INSERT DELAYED statement with a single inserted value does not return any visible warnings, such a warning could be still written into the error log. (Bug#57666)
See also Bug#49567.
* Replication: When closing a session that used temporary tables, binary logging could sometimes fail with a spurious Failed to write the DROP statement for temporary tables to binary log. (Bug#57288)
* Replication: Due to changes made in MySQL 5.5.3, settings made in the binlog_cache_size and max_binlog_cache_size server system variables affected both the binary log statement cache (also introduced in that version) and the binary log transactional cache (formerly known simply as the binary log cache). This meant that the resources used as a result of setting either or both of these variables were double the amount expected. To rectify this problem, these variables now affect only the transactional cache. The fix for this issue also introduces two new system variables binlog_stmt_cache_size and max_binlog_stmt_cache_size, which affect only the binary log statement cache.
In addition, the Binlog_cache_use status variable was incremented whenever either cache was used, and Binlog_cache_disk_use was incremented whenever the disk space from either cache was used, which caused problems with performance tuning of the statement and transactional caches, because it was not possible to determine which of these was being exceeded when attempting to troubleshoot excessive disk seeks and related problems. This issue is solved by changing the behavior of these two status variables such that they are incremented only in response to usage of the binary log transactional cache, as well as by introducing two new status variables Binlog_stmt_cache_use and Binlog_stmt_cache_disk_use, which are incremented only by usage of the binary log statement cache.
For more information, see System variables used with the binary log, and Section 5.1.6, “Server Status Variables”. (Bug#57275)
* Replication: By default, a value is generated for an AUTO_INCREMENT column by inserting either NULL or 0 into the column. Setting the NO_AUTO_VALUE_ON_ZERO server SQL mode suppresses this behavior for 0, so that it occurs only when NULL is inserted into the column.
This behavior is also followed on a replication slave (by the slave SQL thread) when applying events that have been logged on the master using the statement-based format. However, when applying events that had been logged using the row-based format, NO_AUTO_VALUE_ON_ZERO was ignored, which could lead to an assertion.
To fix this issue, the value of an AUTO_INCREMENT column is no longer generated when applying an event that was logged using the row-based row format, as this value is already contained in the changes applied on the slave. (Bug#56662)
* Replication: The Binlog_cache_use and Binlog_cache_disk_use status variables were incremented twice by a change to a table using a transactional storage engine. (Bug#56343)
* Replication: The BINLOG statement modified the values of session variables, which could lead to problems with operations such a point-in-time recovery. One such case occurred when replaying a row-based binary log which relied on setting foreign_key_checks = OFF on the session level in order to create and populate a set of InnoDB tables having foreign key constraints. (Bug#54903)
* Replication: mysqlbinlog printed USE statements to its output only when the default database changed between events. To illustrate how this could cause problems, suppose that a user issued the following sequence of statements:

CREATE DATABASE mydb;
USE mydb;
CREATE TABLE mytable (column_definitions);
DROP DATABASE mydb;
CREATE DATABASE mydb;
USE mydb;
CREATE TABLE mytable (column_definitions);

When played back using mysqlbinlog, the second CREATE TABLE statement failed with Error: No Database Selected because the second USE statement was not played back, due to the fact that a database other than mydb was never selected.
This fix insures that mysqlbinlog outputs a USE statement whenever it reads one from the binary log. (Bug#50914)
* Replication: Previously, when a statement failed with a different error on the slave than on the master, the slave SQL thread displayed a message containing:
- The error message for the master error code
- The master error code
- The error message for the slaves error code
- The slave error code
However, the slave has no information with which to fill in any print format specifiers for the master message, so it actually displayed the message format string. To make it clearer that the slave is not displaying the actual message as it appears on the master, the slave now indicates that the master part of the output is the message format, not the actual message. For example, previously the slave displayed information like this:
Error: Query caused different errors on master and slave. Error on master: 'Duplicate entry '%-.192s' for key %d' (1062), Error on slave: 'no error' (0). Default database: 'test'. Query: 'insert into t1 values(1),(2)' (expected different error codes on master and slave)
Now the slave displays this:
Error: Query caused different errors on master and slave. Error on master: message format='Duplicate entry '%-.192s' for key %d' error code=1062 ; Error on slave: actual message='no error', error code=0. Default database: 'test'. Query: 'insert into t1 values(1),(2)' (expected different error codes on master and slave) (Bug#46697)
* Replication: When an error occurred in the generation of the name for a new binary log file, the error was logged but not shown to the user. (Bug#46166)
See also Bug#37148, Bug#40611, Bug#43929, Bug#51019.
* Comparisons of aggregate values with TIMESTAMP values were incorrect. (Bug#59330)
* For DIV expressions, assignment of the result to multiple variables could cause a server crash. (Bug#59241)
See also Bug#8457.
* MIN(year_col) could return an incorrect result in some cases. (Bug#59211)
* mysqlslap failed to check for a NULL return from mysql_store_result() and crashed trying to process the result set. (Bug#59109)
* In a subquery, a UNION with no referenced tables (or only a reference to the virtual table dual) did not allow an ORDER BY clause. (Bug#58970)
* Configuring MySQL with -DWITHOUT_PERFSCHEMA_STORAGE_ENGINE=1 caused build failures. (Bug#58953)
* Several Valgrind warnings were fixed. (Bug#58948, Bug#59021)
* OPTIMIZE TABLE for an InnoDB table could raise an assertion if the operation failed because it had been killed. (Bug#58933)
* If max_allowed_packet was set larger than 16MB, the server failed to reject too-large packets with “Packet too large” errors. (Bug#58887)
* A NOT IN predicate with a subquery containing a HAVING clause could retrieve too many rows, when the subquery itself returned NULL. (Bug#58818)
* EXPLAIN could crash for queries that accessed two derived tables. (Bug#58730)
* On Solaris, the MySQL build failed if it was configured with debugging enabled. (Bug#58699)
* Issuing EXPLAIN EXTENDED for a query that would use condition pushdown could cause mysqld to crash. (Bug#58553)
* An assertion could be raised for queries for which the optimizer could choose between Index Merge range access or const ref access methods. (Bug#58456)
* If MySQL was built with Visual Studio Express, the project wixca was not built. (Bug#58411)
* EXPLAIN could crash for queries that used GROUP_CONCAT(). (Bug#58396)
* CMake polluted the source tree by writing installation-related temporary files there. (Bug#58372)
* Security context references in sp_head.cc were rewritten for improved DTrace compatibility. (Bug#58350)
* The ucs2 character set does not support characters outside the Basic Multilingual Plane (BMP), but converting a string containing such characters did not produce a conversion-failure warning. (Bug#58321)
* A Valgrind failure occurred in fn_format when called from archive_discover. (Bug#58205)
* CMake did not add LINK_LIBRARIES for MYSQL_ADD_PLUGIN for libmysqld. (Bug#58158)
* An assertion could be raised if the server was closing a session at the same time the session was being killed by another thread. (Bug#58136)
* Condition pushdown optimization could push down conditions with incorrect column references. (Bug#58134)
* Configuration with maintainer mode enabled resulted in errors when compiling with icc. (Bug#57991, Bug#58871)
* An ORDER BY clause was bound to the incorrect substatement when used in UNION context. (Bug#57986)
* The BIT_AND() function could return incorrect results when a join returned no matching rows. (Bug#57954)
* If the set of values aggregated with AVG(DISTINCT) contained a NULL value, the function result could be incorrect. (Bug#57932)
* In rare cases, LIKE expressions failed for an indexed column that used a collation containing contractions. (Bug#57737)
* Unnecessary subquery evaluation in contexts such as statement preparation or view creation could cause a server crash. (Bug#57703)
* View creation could produce Valgrind warnings. (Bug#57352)
* NULL geometry values could cause a crash in Item_func_spatial_collection::fix_length_and_dec. (Bug#57321)
* It was possible to compile mysqld with Performance Schema support but with a dummy atomic-operations implementation, which caused a server crash. This problem does not affect binary distributions. It is helpful as a safety measure for users who build MySQL from source. (Bug#56769)
* The cp1251 character set did not properly support the Euro sign (0x88). For example, converting a string containing this character to utf8 resulted in '?' rather than the utf8 Euro sign. (Bug#56639)
* Some unsigned system variables could be displayed with negative values. (Bug#55794)
* CREATE DATABASE and DROP DATABASE caused mysql --one-database to lose track of the statement-filtering context. (Bug#54899)
* An assertion could be raised during concurrent execution of DROP DATABASE and REPAIR TABLE if the drop deleted a table's .TMD file at the same time the repair tried to read details from the old file that was just removed.
A problem could also occur when DROP TABLE tried to remove all files belonging to a table at the same time REPAIR TABLE had just deleted the table's .TMD file. (Bug#54486)
* After compilation from source, all header files were installed in the same directory, even those that should be installed into subdirectories of the installation include directory. (Bug#51925)
* When mysqld printed crash dump information, it incorrectly indicated that some valid pointers were invalid. (Bug#51817)
* On Mac OS X, a configuration error caused the preference pane to fail. (Bug#51264)
* On FreeBSD, if mysqld was killed with a SIGHUP signal, it could corrupt InnoDB .ibd files. (Bug#51023)
* An assertion could be raised if –1 was inserted into an AUTO_INCREMENT column by a statement writing more than one row. (Bug#50619)
* If a client supplied a user name longer than the maximum 16 characters allowed for names stored in the MySQL grant tables, all characters were being considered significant. Historically, only the first 16 characters were used to check for a match; this behavior was restored. (Bug#49752)
* The my_seek() and my_tell() functions ignored the MY_WME flag when they returned an error, which could cause client programs to hang. (Bug#48451)
* During assignment of values to system variables, legality checks on the value range occurred too late, preventing proper error checking. (Bug#43233)
* On Solaris, time-related functions such as NOW() or SYSDATE() could return a constant value. (Bug#42054)
* If the remote server for a FEDERATED table could not be accessed, queries for the INFORMATION_SCHEMA.TABLES table failed. (Bug#35333)

MySQL 5.5.9 相關參考資料