MySQL AB - (Open Source)
MySQL is a successful open source database used in most web applications, e-commerce and online transaction processing.
MySQL is one of the world's most famous and used open source database. The software can be used to manage web applications, e-commerce and online transaction processing since MySQL database incorporates support those transactions. It is also commonly associated with PHP when it comes to managing websites.
With standard JDBC , ODBC, and Net, the developer can choose the programming language. MySQL has the advantage of working with almost all the popular operating systems and communicate easily with programming languages ​​such as C, C + +, VB, C #, PHP, Python, Ruby, Java, Perl, Eiffel, etc.MySQL replication allows you to create profitable applications. In addition, it enables the development of typologies replication complex and massive chain.Its reliability and robustness, performance, ease of use makes MySQL have more success than anticipated.
# Functionality Added or Changed
* MySQL no longer uses the default OpenSSL compression.
# Bugs Fixed
* Performance; InnoDB: The DROP TABLE statement for a table using compression could be slower than necessary, causing a stall for several seconds. MySQL was unnecessarily decompressing pages in the buffer pool related to the table as part of the DROP operation.
* Important Note; Replication: It was possible to replicate from a table to a same-named view using statement-based logging, while using row-based logging instead led to a failure on the slave. Now the target object type is checked prior to performing any DML, and an error is given if the target on the slave is not actually a table. This is true regardless of the binary logging format in use.
* InnoDB: For InnoDB tables, if a PRIMARY KEY on a VARCHAR column (or prefix) was empty, index page compression could fail.
* InnoDB: For debug builds, InnoDB status exporting was subject to a race condition that could cause a server exit.
* InnoDB: Arithmetic underflow during page compression for CREATE TABLE on an InnoDB table could cause a server exit.
* InnoDB: This fix makes MySQL more responsive to KILL QUERY statements when the query is accessing an InnoDB table.
* InnoDB: When printing out long semaphore wait diagnostics, sync_array_cell_print() ran into a segmentation violation (SEGV) caused by a race condition. This fix addresses the race condition by allowing the cell to be freed while it is being printed.
* InnoDB: Killing a query caused an InnoDB assertion failure when the same table (cursor) instance was used again. This is the result of a regression error introduced. The fix introduced a check to handle kill signals for long running queries but the cursor was not restored to the proper state.
* InnoDB: The length of internally generated foreign key names was not checked. If internally generated foreign key names were over the 64 character limit, this resulted in invalid DDL from SHOW CREATE TABLE. This fix checks the length of internally generated foreign key names and reports an error message if the limit is exceeded.
* Partitioning: A query on a table partitioned by range and using TO_DAYS() as a partitioing function always included the first partition of the table when pruning. This happened regardless of the range employed in the BETWEEN clause of such a query.
* Replication: A zero-length name for a user variable (such as @``) was incorrectly considered to be a sign of data or network corruption when reading from the binary log.
* Replication: Backtick (`) characters were not always handled correctly in internally generated SQL statements, which could sometimes lead to errors on the slave.
* Replication: It was possible in certain cases—immediately after detecting an EOF in the dump thread read event loop, and before deciding whether to change to a new binary log file—for new events to be written to the binary log before this decision was made. If log rotation occurred at this time, any events that occurred following EOF detection were dropped, resulting in loss of data. Now in such cases, steps are taken to make sure that all events are processed before allowing the log rotation to take place.
* A long database name in a GRANT statement could cause the server to exit.
* Incorrect results were returned if a query contained a subquery in an IN clause which contained an XOR operation in the WHERE clause.
* Invocation of the range optimizer for a NULL select caused the server to exit.
* yaSSL did not perform proper padding checks, but instead examined only the last byte of plaintext and used it to determine how many bytes to remove.
* SHOW COLUMNS on a view defined as a UNION of Geometry columns could cause the server to exit.
* A LIKE pattern with too many '%' wildcards could cause a segmentation fault.
* SET var_name = VALUES(col_name) could cause the server to exit. This syntax is now prohibited because in SET context there is no column name and the statement returns ER_BAD_FIELD_ERROR.
* The COM_CHANGE_USER command in the client/server protocol did not properly use the character set number in * Subqueries with OUTER JOIN could return incorrect results if the subquery referred to a column from another SELECT.
* Field_geom::reset() failed to reset its base Field_blob. The range optimizer used the uninitialized field during optimization and execution, causing the server to exit.
* mysql_install_db did not escape '_' in the host name for statements written to the grant tables.
* PARTITION BY KEY on a utf32 ENUM column raised a debugging assertion.
* The optimizer used loose index scan for some queries for which this access method is inapplicable.
* If a dump file contained a view with one character set and collation defined on a view with a different character set and collation, attempts to restore the dump file failed with an “illegal mix of collations†error.
* The REPLACE() function produced incorrect results when a user variable was supplied as an argument and the operation was performed on multiple rows.
* UNION ALL on BLOB columns could produce incorrect results.
* View access in low memory conditions could raise a debugging assertion.
* Setting max_connections to a value less than the current number of open connections caused the server to exit.
* Incorrect metadata could be produced for columns returned from some views.
* For debug builds, some queries with SELECT ... FROM DUAL nested subqueries raised an assertion.
* Adjusted MySQL configuration to account for change in Automake 1.12 that produced sql_yacc.hh rather than sql_yacc.h as expected by sql/Makefile.am.