What is MariaDB 5.3

You are viewing an old version of this article. View the current version here.

The focus for MariaDB 5.3 is to improve the optimizer, especially for sub queries and complex/big joins.

MariaDB 5.3 is based on MariaDB 5.2 and thus on MariaDB 5.1 and MySQL 5.1.

Some of the code is backported from MySQL 6.0 and improved. Other code is written from scratch.

This is the biggest redesign of the MariaDB optimizer in 10 years and it will finally make all sub queries usable in MariaDB.

The plan is to have a beta version (feature complete) of MariaDB 5.3 in May. Until then you can get the source code from launchpad.

New features

  • Faster joins thanks to MRR (Multi-Read-Range access).
  • Faster joins thanks to BKA (Batch key access).
  • Better optimizations for derived tables and views.
  • Faster sub queries.
    • Avoid recalculating a subquery if external field values found in subquery cache
    • Backporting subquery optimization from 6.0
  • No materialization for many kinds of sub queries in the FROM clause.
  • Hash joins
  • New Annotate_rows mysqlbinlog event type.
  • Microsecond support for NOW() and timestamp, time and datetime columns.
  • Faster HANDLER commands; HANDLER READ now also work with prepared statements.
  • HandlerSocket plugin included.
  • Group commit for binary log; Gives you safer and faster replication.
  • CAST() now supports AS DECIMAL[(M,D)] and AS INT.
  • CAST() and all other datetime/time functions now supports microsecond fully.
  • Checksums for binlog events. This is a backport of the same feature in MySQL 5.6. It was implemented in MWL#180.
  • Subquery Cache
  • Dynamic Columns support.
  • Group commit for the binary log MariaDB 5.3 implements group commit which works when using XtraDB with the binary log enabled. (In previous MariaDB releases, and all MySQL releases at the time of writing, group commit works in InnoDB/XtraDB when the binary log is disabled, but stops working when the binary log is enabled).
  • Enhancements for START TRANSACTION WITH CONSISTENT SNAPSHOT In MariaDB 5.3, START TRANSACTION WITH CONSISTENT SNAPSHOT now also works with the binary log. This means it is possible to obtain the binlog position corresponding to a transactional snapshot of the database without blocking any other queries. This is used by the command "mysqldump --single-transaction --master-data" to do a fully non-blocking backup which can be used to provision a new slave. "START TRANSACTION WITH CONSISTENT SNAPSHOT" now also works consistently between transactions involving more than one storage engine (currently XTraDB and PBXT support this).
  • Annotation of row-based replication events with the original SQL statement When using row-based replication, the binary log does not contain SQL statements, only discrete single-row insert/update/delete events. This can make it harder to read mysqlbinlog output and understand where in an application a given event may have originated, complicating analysis and debugging.This feature adds an option to include the original SQL statement as a comment in the binary log (and shown in mysqlbinlog output) for row-based replication events.
  • Row-based replication for tables with no primary key This feature can improve the performance of row-based replication on tables that do not have a primary key (or other unique key), but which do have another index that can help locate rows to update or delete. With this feature, index cardinality information from ANALYZE TABLE is considered when selecting the index to use (before this feature is implemented, the first index was selected unconditionally).
  • Early release during prepare phase of XtraDB row locks This feature adds an option to make XtraDB release the row locks for a transaction earlier during the COMMIT step when running with "--sync-binlog=1" and "--innodb-flush-log-at-trx-commit=1". This can improve throughput if the workload has a bottleneck on hot-spot rows.
  • PBXT consistent commit ordering This feature implements the new commit ordering storage engine API in PBXT. With this feature, it is possible to use "START TRANSACTION WITH CONSISTENT SNAPSHOT" and get consistency among transactions which involve both XtraDB and InnoDB. (Without this feature, there is no such consistency guarantee. For example, even after running "START TRANSACTION WITH CONSISTENT SNAPSHOT" it was still possible for the InnoDB/XtraDB part of some transaction T to be visible and the PBXT part of the same transaction T to not be visible.)

Miscellaneous

  • MariaDB 5.3 also includes a small change to make mysqlbinlog omit redundant use statements around BEGIN, SAVEPOINT, COMMIT, and ROLLBACK events when reading MySQL 5.0 binlogs.
  • MariaDB unique error numbers now start from 1900 to not clash with MySQL error numbers.

For a more specific list and for things that are still planned, see the MariaDB 5.3 TODO page.

You can access the MariaDB 5.3 tree from launchpad.

Documentation is being worked on at mariadb-53-documentation

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.