Что такое MariaDB 5.3? - Source

Revision: 43452
Пользователь: Alex Stranger
Date: 2016-03-14 13:52

<<style class="greenbox" style="border-radius:10px;text-align:center;font-family:'Droid Sans';font-weight:bold;font-size:1.2em;">>
[[http://downloads.mariadb.org/mariadb/5.3|Скачать MariaDB 5.3]]
<</style>>

Главным фокусом развития MariaDB 5.3 остается увеличение производительности
для подзапросов, таких как "JOIN" или одно-табличные запросы применяемые к большим наборам данных.

MariaDB 5.3 базируется на MariaDB 5.2, а она на MariaDB 5.1, которая основана на MySQL 5.1.
Она больше находиться в активной разработке, и будет получать критические исправления безопасности только до Февраля 2017 года.

Некоторая часть кода была портирована из MySQL 6.0 (версия которая не была 
допущена к релизу как GA компанией Oracle), который был переработан и обогащен 
новыми возможностями, ну и конечно некоторая часть кода была написана с нуля.

Все новые возможности и их комбинации могут быть включены или выключены динамически через
[[mariadb-53-optimizer_switch|системную переменную "optimizer_switch"]]

Первый стабильный (GA) релиз MariaDB 5.3 был
[[mariadb-535-release-notes|MariaDB 5.3.5]], который был выпущен 29 Февраля 2012 года.

Вы можете 
[[http://downloads.askmonty.org/MariaDB/5.3/|скачать последнюю бинарную сборку MariaDB 5.3 тут]],
или получить последнюю версию
[[source-getting-the-mariadb-source-code|исходного кода из Launchpad]].

== Сравнительные таблицы дополнений

Для оптимизаторов была создана таблица [[optimizer-feature-comparison-matrix|Сравнительная таблица дополнений-оптимизаторов]]
показывающая что новые дополнения для оптимизации в MariaDB 5.5 и 5.3 подходят к MySQL 5.5 и 5.6.

== Оптимизация запросов
=== Оптимизация подзапросов

Подзапросы окончательно вошли в нашу практику. Больше не требуется
переписывать подзапросы в ручную в "JOIN" или разделять запросы. 
MariaDB 5.3 нацелен на обеспечение обоснованной обработки для всех типов подзапросов
Все возникшие проблемы с ##EXPLAIN## полученные в процессе уже были решены.

* [[semi-join-subquery-optimizations|Semi-join subquery optimizations]]\\
  Оптимизатор трансформирует подзапросы в 'полу-join' запросы, это такие запросы похожие на
  'inner join', тогда оптимизатор выбирает лучшую стратегию выполнения 'полу-join' запросов.
  Глобально процесс сходный с тем как выполняется join в MySQL, MariaDB и других базах данных.
** [[table-pullout-optimization|"Table pullout"-оптимизация]]
** [[firstmatch-strategy|"FirstMatch" стратегия выполнения]]
** [[semi-join-materialization-strategy|"Полу-join Materialization" стратегия выполнения]]
** [[loosescan-strategy|"LooseScan" стратегия выполнения]]
** [[duplicateweedout-strategy|"DuplicateWeedout" стратегия выполнения]]
* [[non-semi-join-subquery-optimizations|Не "полу-join" оптимизация подзапросов]]\\
  если подзапросы не "полу-join", MariaDB 5.3 сделает выбор с учетом затрат из двух стратегий:
** Материализация для нескоррелированных подзапросов, при помощи [[http://askmonty.org/worklog/Server-Sprint/?tid=68|стратегия эффективного выполнения NULL-подобных вычислений]]
** IN-to-EXISTS трансформация (только оптимизаторы унаследованные от MariaDB 5.2 and MySQL 5.1/5.5)
* [[subquery-cache|Кэш подзапросов]]\\
  Кэш подзапросов, позволяет подзапросам выполняться несколько раз за короткое время
  что увеличивает быстродействие уже оптимизированных подзапросов.
* Подзапросы никогда не выполняются в процессе ##EXPLAIN##, таким образом результат всегда 
  практически мгновенный ##EXPLAIN##.
* DISTINCT и GROUP BY без использования HAVING [[optimizing-group-by-and-distinct-clauses-in-subqueries|оптимизированы]] 
  для подзапросов.

[[subquery-optimizations-map|Карта оптимизации подзапросов]] показывает новую схему оптимизации в графическом виде.

=== Оптимизация для доставки таблиц и представлений(запросов)

* No early materialization of derived tables (e.g. subqueries in a ##FROM##
  clause) and materialized views (##EXPLAIN## is always instantaneous)
* Thanks to [[derived-table-merge-optimization|Derived Table Merge optimization]], mergeable derived tables are now processed like mergeable VIEWs.
* [[derived-table-with-key-optimization|Derived Table with Keys]] optimization gives the optimizer an option to create indexes over materialized derived tables
* Fields of merge-able views and derived tables are involved now in all
  optimizations employing equalities

=== Оптимизация доступа к диску
* [[index-condition-pushdown|Index Condition Pushdown]]
* [[multi-range-read-optimization|Multi-Range-Read optimization (MRR)]]
** Key-ordered retrieval

=== Оптимизация 'Join' запросов
* [[block-based-join-algorithms|Block-based Join Algorithms]]
* Block Nested Loop algorithm can be used for outer joins
* Block Hash Join (classic algorithm) is implemented and can be used for any
  equi-joins
* Block Index Join (Batch Key Access Join) is supported and can exploit the
  benefits of ordered retrievals for primary and secondary keys provided by the
  new implementation of [[multi-range-read-optimization|MRR]]
* All block based algorithms for joins can use the benefits of new incremental
  join buffers
* All block based algorithms fully support outer joins including nested outer
  joins
* All block based algorithms can use the benefits of the first match
  optimization for semi-joins and the non-exist optimization for outer joins
* All block based algorithms for joins can exploit the benefits of index
  condition push-down.
* The total memory space used by the query for join buffers can be limited now,
  and block based algorithms can allocate join buffers up to their needs (not
  exceeding the set limits).
* Condition over outer tables extracted from ON expressions of outer joins are
  evaluated before inner tables are accessed (supported for both regular index
  join and block index join)
* Early checks for nulls for the fields from any null-rejecting conditions are
  performed

=== Index Merge improvements
* Correct optimization of index_merge vs range access: [[fair-choice-between-range-and-index_merge-optimizations|Fair choice between range and index_merge optimizations]] 
* [[index_merge_sort_intersection|index_merge/sort_intersection]] strategy

=== Optimizer control
* [[mariadb-53-optimizer_switch|@@optimizer_switch variable]] can be used to turn on/off all new optimizations.

== NoSQL-style interfaces
* [[handlersocket|HandlerSocket]] plugin included.
* Faster [[handler-commands|HANDLER]] commands; [[handler-commands|HANDLER READ]] now also work with prepared statements.
* [[dynamic-columns|Dynamic Columns]] support.

== Replication and binary logging
* [[group-commit-for-the-binary-log|Group commit for the binary log]] <<entity>>mdash<</entity>> 
  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).
* [[annotate_rows_log_event|Annotation of row-based replication events with the original SQL statement]] <<entity>>mdash<</entity>> 
  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.
* [[binlog-event-checksums|Checksums for binlog events]]. This is a backport of
  the same feature in MySQL 5.6. It was implemented in MWL#180.
* [[enhancements-for-start-transaction-with-consistent|Enhancements for START TRANSACTION WITH CONSISTENT SNAPSHOT]] <<entity>>mdash<</entity>> 
  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).
* [[row-based-replication-with-no-primary-key|Row-based replication for tables with no primary key]] <<entity>>mdash<</entity>> 
  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).
* ##mysqlbinlog## will now omit redundant ##use## statements
  around ##BEGIN##, ##SAVEPOINT##, ##COMMIT##, and ##ROLLBACK## events when
  reading MySQL 5.0 binlogs.

== Типы данных
* [[microseconds-in-mariadb|микросекунды]] поддерживает [[now|NOW()]] и
  [[timestamp]], [[time]], и [[datetime]] столбцы.
* [[cast|CAST()]] теперь поддерживает AS DECIMAL[(M,D)] и AS INT.
* [[cast|CAST()]] и все другие.datetime/time функции теперь полностью поддерживают микросекунды.

== Улучшения производительности в Windows

* Бэкпорт из [[http://www.facebook.com/note.php?note_id=238505812835782|Патчи для увеличения производительности в Windows]] из MySQL 5.5.
* Асинхронный IO в XtraDB
  теперь [[http://www.facebook.com/note.php?note_id=238687382817625|переработан]]
  и теперь работает быстрее, в связи с завершением IO-порта.
* Дополнительная устойчивость опций для XtraDB : ##innodb_flush_method## теперь может быть  ##O_DSYNC##, 
  прямо как в Unix. Эффект использования этой опции можно найти в лог-файле открываемом флагом ##FILE_FLAG_WRITETHROUGH##,
  и ##FlushFileBuffers()## теперь не работает(?). Это может ускорить выполнение тяжелых(в плане записи на диск) сценариев.
* Новый Windows [[installing-mariadb-msi-packages-on-windows|MSI-установшик]].
* Включает [[http://www.heidisql.com/|GUI-tool для HeidiSQL]].

== Всякое разное
* [[gis-features-in-533|GIS точные операции]]
* Новые переменные-статусы:  ##Rows_tmp_read##, ##Handler_tmp_write##,
  and ##Handler_tmp_update## которые считают что происходит во внутренних временных таблицах. 
  ##Rows_read##, ##Handler_write## and ##Handler_update## больше не считают
  то что происходит во внутренних временных таблицах.
* Новая переменная-статус ##Handler_read_rnd_deleted##, которая показывает количество
  удаленных строк, найденных и пропущенных при сканировании таблицы. Раньше она была частью ##Handler_read_rnd_next##.
* Новая переменная  'in_transaction' которая '1' если транзакция, иначе '0'.
* [[progress-reporting|Отчеты о прогрессе]] для ##ALTER TABLE##
  и ##LOAD DATA INFILE##. В дополнение Aria-таблицы дают отчеты о прогрессе 
  для ##REPAIR TABLE## and ##CHECK TABLE##. Прогресс вы можете посмотреть в ##SHOW PROCESSLIST##, ##INFORMATION_SCHEMA.PROCESSLIST## и это можно переслать
  клиентам MariaDB которые вызвали ##mysql_real_connect()## с новым ##CLIENT_PROGRESS## флагом. ##mysql##-клиент для командной строки теперь поддерживает
  новый индикатор прогресса.
*  [[enhancements-for-start-transaction-with-consistent|PBXT-подобное последовательное наложение коммитов]]
   <<entity>>mdash<</entity>> Эта возможность включает API новой службы хранения и наложения коммитов PBXT.
   с этой службой стало возможным использование "##START TRANSACTION WITH CONSISTENT SNAPSHOT##"
   и управлять наложением среди транзакций которые вызваны через XtraDB и InnoDB.
   (Без этой возможности вы не имеете гарантии. Например после запуска "##START TRANSACTION WITH CONSISTENT SNAPSHOT##"
   может получиться так что часть  InnoDB/XtraDB транзакций //T// будет видна, а часть PBXT транзакций //T// нет.)
* MariaDB уникальные номера ошибок теперь начинаются с ##1900## чтобы не пересекаться с MySQL
  номерами ошибок.
* {{{/*M!##### */}}} новый [[comment-syntax|синтаксис выполняемых комментариев]] который может быть использован
  когда вы хотите использовать новый синтаксис MariaDB но хочется оставить программу совместимой с MySQL.
* Оптимизированная версия MariaDB отсюда [[http://www.mysqlfanboy.com/mytop|mytop]] включена в MariaDB дистрибутив.
* Расширен [[data-manipulation-kill-connection-query|KILL синтаксис]]:<<code lang=text inline=false>>KILL [HARD | SOFT] [CONNECTION | QUERY] [thread_id | USER user_name]<</code>>
* <<code>>max_user_connections<</code>> (обе, глобальная переменная и  ##GRANT## опция) должна быть установлена в ##-1## чтобы запретить пользователям соединения с
  сервером. Глобальная <<code>>max_user_connections<</code>> переменная не влияет на
  пользователей с <<code>>SUPER<</code>> привелегиями.
* Директива [[ignore|IGNORE]] игнорирует не все ошибки (вроде fatal error), только то что можно безопасно игнорировать.

Вы можете получить доступ к дереву MariaDB 5.3 из
[[https://launchpad.net/maria/5.3|launchpad]].

=== Исправление уязвимостей безопасности в MariaDB 5.3
<<style class="graybox">>
Для того чтобы увидеть весь список исправленных уязвимостей, за все
версии MariaDB, гляньте эту [[cve|Исправленные уязвимости безопасности в MariaDB]] страницу.
<</style>>
<<listcve product="MariaDB 5.3.\d+">>

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.

Что такое MariaDB 5.3? - Source

Products

Services

Pricing

Resources

About Us

Download MariaDB