2. business software
  3. news
  4. reviews
  5. top apps
Descargar MySQL 5.5.27

MySQL 5.5.27

Por MySQL AB  (Open Source)
Valoración de los usuarios

MySQL Community Edition is a freely downloadable version of the world's most popular open source database that is supported by an active community of open source developers and enthusiasts.

MySQL delivers enterprise features, including:

  • Partitioning to improve performance and management of very large database environments
  • Row-based/Hybrid Replication for improved replication security
  • Event Scheduler to create and schedule jobs that perform various database tasks
  • XPath Support
  • Dynamic General/Slow Query Log
  • Performance/Load Testing Utility (mysqlslap)
  • Improved! Full Text Search (faster, new dev templates)
  • Improved! Archive engine (better compression, more features)
  • Improved! User session and problem SQL identification
  • Improved! MySQL embedded library (libmysqld)
  • Additional INFORMATION_SCHEMA objects
  • Faster data import operations (parallel file load)
  • ACID Transactions to build reliable and secure business critical applications
  • Stored Procedures to improve developer productivity
  • Triggers to enforce complex business rules at the database level
  • Views to ensure sensitive information is not compromised
  • Information Schema to provide easy access to metadata
  • Pluggable Storage Engine Architecture for maximum flexibility
  • Archive Storage Engine for historical and audit data
Título: MySQL 5.5.27
Nombre de fichero: mysql-5.5.27-win32.msi
Tamaño de fichero: 31.12MB (32,635,904 bytes)
Requisitos: Windows 9x / 2000 / XP / Vista / Windows 7 / Windows 8 / Windows 10 / Windows 10 64-bit
Idiomas: Múltiples idiomas
Licencia: Open Source
Fecha añadida: 6 de agosto de 2012
Autor: MySQL AB
Página de inicio: www.mysql.com
MD5 Checksum: CC877B223248774152B996AFE5A18EDA

* Functionality Added or Changed
- Important Change: The YEAR(2) data type is now deprecated because it is problematic. Support for YEAR(2) will be removed in a future release of MySQL.
* Bugs Fixed
- InnoDB: A race condition could cause assertion errors during a DROP TABLE statement for an InnoDB table. Some internal InnoDB functions did not correctly determine if a tablespace was missing; other functions did not handle the error code correctly if a tablespace was missing.
- InnoDB: If a row was deleted from an InnoDB table, then another row was re-inserted with the same primary key value, an attempt by a concurrent transaction to lock the row could succeed when it should have waited. This issue occurred if the locking select used a WHERE clause that performed an index scan using a secondary index.
- InnoDB: An assertion could be raised if an InnoDB table was moved to a different database using ALTER TABLE ... RENAME while the database was being dropped by DROP DATABASE.
- InnoDB: Using the KILL statement to terminate a query could cause an unnecessary message in the error log: [ERROR] Got error -1 when reading table table_name
- InnoDB: For an InnoDB table with a trigger, under the setting innodb_autoinc_lock_mode=1, sometimes auto-increment values could be interleaved when inserting into the table from two sessions concurrently. The sequence of auto-increment values could vary depending on timing, leading to data inconsistency in systems using replication.
- Replication: An event whose length exceeded the size of the master dump thread's max_allowed_packet caused replication to fail. This could occur when updating many large rows and using row-based replication. As part of this fix, a new server option --slave-max-allowed-packet is added, which permits max_allowed_packet to be exceeded by the slave SQL and I/O threads. Now the size of a packet transmitted from the master to the slave is checked only against this value (available as the value of the slave_max_allowed_packet server system variable), and not against the value of max_allowed_packet.
- Replication: Statements such as UPDATE ... WHERE primary_key_column = constant LIMIT 1 are flagged as unsafe for statement-based logging, despite the fact that such statements are actually safe. In cases where a great many such statements were run, this could lead to disk space becoming exhausted do to the number of such false warnings being logged. To prevent this from happening, a warning suppression mechanism is introduced. This warning suppression acts as follows: Whenever the 50 most recent ER_BINLOG_UNSAFE_STATEMENT warnings have been generated more than 50 times in any 50-second period, warning suppression is enabled. When activated, this causes such warnings not to be written to the error log; instead, for each 50 warnings of this type, a note is written to the error log stating The last warning was repeated N times in last S seconds. This continues as long as the 50 most recent such warnings were issued in 50 seconds or less; once the number of warnings has decreased below this threshold, the warnings are once again logged normally. The fix for this issue does not affect how these warnings are reported to MySQL clients; a warning is still sent to the client for each statement that generates the warning. This fix also does not make any changes in how the safety of any statement for statement-based logging is determined.
- Replication: After upgrading a replication slave to MySQL 5.5.18 or later, enabling the query cache eventually caused the slave to fail.
- The server did not build with gcc 4.7.
- Certain arguments to RPAD() could lead to “uninitialized variable” warnings.
- The presence of a file named .empty in the test database prevented that database from being dropped.
- For some subqueries that should be executed using a range scan on a non-primary index and required use of filesort, only the first execution of the subquery was done as a range scan. All following executions were done as full table scans, resulting in poor performance.
- The number of connection errors from a given host as counted by the server was periodically reset, with the result that max_connect_errors was never reached and invalid hosts were never blocked from trying to connect.
- File access by the ARCHIVE storage engine was not instrumented and thus not shown in Performance Schema tables.
- mysqlbinlog exited with no error code if file write errors occurred.
- Using CONCAT() to construct a pattern for a LIKE pattern match could result in memory corrupting and match failure.
- yaSSL rejected valid SSL certificates that OpenSSL accepts.
- Sessions could end up deadlocked when executing a combination of SELECT, DROP TABLE, KILL, and SHOW ENGINE INNODB STATUS.
- mysqldump could dump views and the tables on which they depend in such an order that errors occurred when the dump file was reloaded.

blog comments powered by Disqus