Скачать MySQL 5.1.39 - бесплатный сервер баз данных

MySQL Community Server — свободная система управления базами данных (СУБД). Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. MySQL является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения.

MySQL является решением для малых и средних приложений. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

Что нового в MySQL 5.1.39

Bugs fixed:

* Partitioning: An INSERT ... SELECT statement on an empty partition of a partitioned table failed with ERROR 1030 (HY000): Got error 124 from storage engine. This issue also caused queries run against a partitioned table while a LOAD DATA CONCURRENT INFILE statement was in progress to fail with the same error. (Bug#46639: http://bugs.mysql.com/46639) See also Bug#35845: http://bugs.mysql.com/35845, Bug#44657: http://bugs.mysql.com/44657, Bug#45840: http://bugs.mysql.com/45840.

* Partitioning: A partitioned table having a TIMESTAMP column with a default value of CURRENT_TIMESTAMP and this column was not defined using an ON UPDATE option, an ALTER TABLE ...REORGANIZE PARTITION statement on the table caused the TIMESTAMP column value to be set to CURRENT_TIMESTAMP regardless. (Bug#46478: http://bugs.mysql.com/46478)

* Partitioning: Attempting to access a partitioned table when partitioning support was disabled in a MySQL server binary that had been compiled with partitioning support caused the server to crash. (Bug#39893: http://bugs.mysql.com/39893)

* Partitioning: The use of TO_DAYS() in the partitioning expression led to selection failures when the column having the date value contained invalid dates. This occurred because the function returns NULL in such cases, and the partition containing NULL values was pruned away. For example, this problem occurred if '2001-02-00' was inserted into a DATE column of such a table, and a subsequent query on this table used WHERE date_col < '2001-02-00' --- while '2001-01-01' is
less than '2001-02-00', TO_DAYS('2001-02-00') evaluates as NULL, and so the row containing '2001-01-01' was not returned. Now, for tables using RANGE or LIST partitioning and having TO_DAYS() in the partitioning expression, the NULL partition
is also scanned instead of being ignored. The fix for this issue also corrects misbehavior such that a query of the form SELECT * FROM table WHERE date_col <
date_val on a table partitioned by RANGE or LIST was handled as though the server SQL mode included ALLOW_INVALID_DATES even if this was not actually part of the server SQL mode at the time the query was issued. (Bug#20577: http://bugs.mysql.com/20577) See also Bug#18198: http://bugs.mysql.com/18198,
Bug#32021: http://bugs.mysql.com/32021, Bug#46362: http://bugs.mysql.com/46362.

* Replication: Performing a multi-row update of the AUTO_INCREMENT column of a transactional table could result in an inconsistency between master and slave when there was a trigger on the transactional table that updated a non-transactional table. When such an update failed on the master, no rows were updated on the master, but some rows could (erroneously) be updated on the slave. (Bug#46864: http://bugs.mysql.com/46864)

* Replication: When using the --replicate-rewrite-db option and the database referenced by this option on the master was the current database when the connection to the slave was closed, any temporary tables existing in this database were not properly dropped. (Bug#46861: http://bugs.mysql.com/46861)

* Replication: When a statement that changed both transactional and non-transactional tables failed, the transactional changes were automatically rolled back on the master but the slave ignored the error and did not roll them back, thus leading to inconsistencies between master and slave. This issue is fixed by automatically rolling back a statement that fails on the slave; however, the transaction is not rolled back unless a corresponding ROLLBACK statement is found in the relay log file.(Bug#46130: http://bugs.mysql.com/46130) See also Bug#33864: http://bugs.mysql.com/33864.

* Replication: When slave_transaction_retries is set, a statement that replicates, but is then rolled back due to a deadlock on the slave, should be retried. However, in certain cases, replication was stopped with error 1213 (Deadlock found when trying to get lock; try restarting transaction) instead, even when this variable was set. (Bug#45694: http://bugs.mysql.com/45694)

* Replication: The binary logging behavior (and thus, the replication behavior) of CREATE DATABASE IF NOT EXISTS, CREATE TABLE IF NOT EXISTS, and CREATE EVENT IF NOT EXISTS was not consistent among these statements, nor with that of DROP DATABASE IF EXISTS, DROP TABLE IF EXISTS, and DROP EVENT IF EXISTS: A DROP ... IF EXISTS statement is always logged even if the database object named in the statement does not exist. However, of the CREATE ... IF NOT EXISTS statements, only the CREATE EVENT IF NOT EXISTS statement was logged when the database object named in the statement already existed.Now, every CREATE ... IF NOT EXISTS statement is written to the binary log (and thus replicated), whether the database object named in the statement exists or not. For more information, see Section 16.3.1.3, "Replication of CREATE ...IF NOT EXISTS Statements."Exception. Replication and logging of CREATE TABLE IF NOT EXISTS ... SELECT continues to be handled according to existing rules. See Section 16.3.1.4, "Replication of CREATE TABLE ... SELECT Statements," for more information.(Bug#45574: http://bugs.mysql.com/45574)