MySQL

индекс
230,83

Что нового в MySQL 5.1

Осталось совсем немного времени до выхода MySQL 5.1. В статье будут рассмотрены изменения и новые возможности этой версии.


1. Разбиение таблиц (Partitioning)
Разбиение таблиц — это одна из важных функций, которых не хватало MySQL. Хотя в MySQL и реализован тип таблиц MERGE, однако, его функциональность довольно отличается от partitioning таблиц.

Разбиение таблиц позволит разделять большую таблицу на несколько и хранить их независимо друг от друга, при этом сохраняя логическую общность. Этим достигается увеличение скорости доступа к данным и простота управления дисками.

Все типы таблиц поддерживают такое разбиение.
В MySQL 5.1 реализованы следующие основные виды разбиения таблиц:
  • Разбиение по диапазону. Такое разбиение подходит для таблиц со слабо связанными данными, например, таблица с логами.
          CREATE TABLE logs (
              value VARCHAR(30) NOT NULL,
              create_date TIMESTAMP NOT NULL
          )
          PARTITION BY RANGE(YEAR(create_date)) (
              PARTITION p0 VALUES LESS THAN (2005),
              PARTITION p1 VALUES LESS THAN (2006),
              PARTITION p2 VALUES LESS THAN (2007),
              PARTITION P3 VALUES LESS THAN MAXVALUE
          );
    

    В этом примере данные будут разбиваться на таблицы по году создания записи.
  • Разбиение по списку значений. Этот вид разбиения во многом похож на предыдущий. Главное отличие заключается в том, что разбиение по списку значений позволяет точно указать распределение данных для каждого значения.
          CREATE TABLE employees (
              id INT NOT NULL,
              fname VARCHAR(30),
              lname VARCHAR(30),
              departament TINYINT(2),
          )
          PARTITION BY LIST(departament) (
            PARTITION management VALUES IN(1, 5, 6),
            PARTITION sales VALUES IN(2, 3),
            PARTITION technical VALUES IN(4, 7, 8)
          );
    
  • Разбиение по хеш-функции. В этом виде разбиения можно указать функцию, по которой будут разделяться данные:
          CREATE TABLE logs (
              value VARCHAR(30) NOT NULL,
              create_date TIMESTAMP NOT NULL
          )
          PARTITION BY HASH( YEAR(create_date) )
          PARTITIONS 4;
    


2. Построчная репликация (row-based replication)
При обычной репликации мастер-слейв при каждом изменении таблицы мастер посылает слейвам ту же команду на изменение данных. В MySQL 5.1 добавлена возможность создания репликации, при которой мастер не посылает слейвам команду на изменение данных, а записывает в лог-файл то, как и в каких строках были изменены данные. Такой вид репликации наиболее надежный и используется в большинстве коммерческих СУБД.

Включить построчную репликацию можно командой

SET GLOBAL binlog_format = 'ROW';

либо в конфигурационном файле.

3. События (events)
В новой версии добавлена возможность создания событий. Эта функциональность позволяет настроить выполнение периодических SQL запросов или процедур. Например, выполнять необходимый пересчет данных раз в день.
DELIMITER //
CREATE EVENT RECALC_SUMM
ON SCHEDULE EVERY 1 WEEK
STARTS '2008-08-13 1:00:00'
ON COMPLETION PRESERVE
DO
BEGIN
    UPDATE table1 SET sum = sum + today_amount
END
//

4. Удобство администрирования
Начиная с версии MySQL 5.1 появилась возможность сохранения логов сервера в таблицах. В предыдущих версиях логи можно было сохранять только в файловой системе, что добавляло трудностей с их обработкой. В таблицы можно записывать общий лог MySQL(general log)и лог медленных запросов (slow log). Настроить эту возможность можно параметром --log-output=TABLE. При выборе данной опции в базе данных mysql создадутся таблицы general_log и slow_log.

Кроме этого в MySQL 5.1 появилась таблица PROCESSLIST. В этой таблице сохраняются данные о том, какие процессы выполняет MySQL, идентично тому, как их выводит команда SHOW PROCESSLIST.

5. Поддержка XML XPath
В MySQL 5.1 добавлена поддержка XPath. Теперь XML документ, сохраненный в таблицу, доступен пользователю в виде дерева. Можно получить любое значение из дерева и обновить лишь нужный узел. Для этого были добавлены две функции: ExtractValue и UpdateXML. Например:

SELECT ExtractValue('test', '/a')

выдаст результат test.

SELECT UpdateXML('test', '/a', 'value')

выдаст результат value.

Кроме этого в MySQL 5.1 добавлены:
  • Поддержка plug-in архитектуры, позволяющая подключать и изменять компоненты сервера без перезагрузки.
  • Репликация кластер-кластер.
  • Возможность хранить данные NDB кластера на диске.
  • Программа mysqlslap, позволяющая эмулировать нагрузку на MySQL сервер.


Читайте оригинал статьи на MySQL Consulting.

P.S. пишите в личку темы статей по MySQL, которые вы хотели бы прочитать.

+78
16 сентября 2008, 00:03
85

комментарии (50)

+1
Gimli #
must have хабракат
+3
tuta_larson #
спасибо, добавил.
+3
gra #
большое спасибо за статью
кое-где правда форматирование побилось — обратите внимание на второй пункт
+2
tuta_larson #
поправил
–2
SCode #
бегом обновлять, хотя и не понял пункт 2 :)
+1
Bonch #
Вы не поняли:
>> Осталось совсем немного времени до выхода MySQL 5.1.

так что рано еще
+1
SCode #
простите, я это заметил только на сайте майскула((
+1
dohlik #
бегом в очередь на скачивание :)
+1
slyder #
класс, радует что разработчики не стоят на месте…
свой опыт работы с БД начинал с MS SQL и когда еще года 3-4 назад пришлось перейти на MySQL долго не мог привыкнуть, что нельзя было делать под-запросы, реляционный запросы и прочие жизнено-необходимые вещи…
а тут MySQL приобретает функциональность, которая присуща серьезным БД, остобено порадовало появление обрабочтика событий и xPath
НЛО прилетело и опубликовало эту надпись здесь
0
kot9lpa #
дождемся, вернее дождались, поскольку в Google (чисто к примеру) насколько я читал стоит именно MySQL, а там запросики будь здоров и нагрузка на серваки… мягко сказать неслабая
+1
maxshopen #
Ну они(Google), мягко говоря, не Community-Server MySQL используют :)
НЛО прилетело и опубликовало эту надпись здесь
0
kibitzer #
А у вас есть информация, что комьюинити сервер майскуля отличается функциональностью движков от энтерпрайз?

У гугли просто модифицированная ими версия майскуля, и свои расширения они обещали открывать, часть из них должна в версию 6.0 войти.
+2
makkintosh #
у них свой bigtable engine :)
0
B_dot #
А как вы себе это представляете? С теоретической точки зрения?
НЛО прилетело и опубликовало эту надпись здесь
0
B_dot #
Ну насколько я понимаю, там это возможно только с bitmap индексами.

А запрос типа SELECT * FROM the_table WHERE id IN (1, 2, 10, 20) AND age > 20; ну никак не может использовать более одного индекса.

Поправьте плиз если я не прав.
НЛО прилетело и опубликовало эту надпись здесь
0
B_dot #
И собственно что?

Тут скорее всего будет использоваться индекс по id, он вывалит ссылки на строки с id 1, 2, 10 и 20. Как к этому приделать индекс. Едиснтвенное возможное дальнейшее действие — выдернуть данные и пройтись по всем строкам, отфильтровав/отсортировав его.

В этом запросе возможно использование двойного индекса (т.е. по столбцам id и age), а не двух.
НЛО прилетело и опубликовало эту надпись здесь
+1
maghamed #
Позволю себе Вам напомпить при каких обстоятельствах будет использоваться составной индекс.

Indexes Basic

• Index (A, B) can be used for

– A=5, A=5 and B=5, A=5 and B>6

• But Can't be used for

– B=6, B<2

• Only Equality/List allows second key part usage

– A=5 and B>6 — will use 2 keyparts

– A IN (1,2) and B=2 will use 2 key parts

– A>5 and B=2 will use 1 key part only

Using Indexes for Order By

• Having same index (A, B)

• A=5 ORDER BY B — Will use index

• A>5 ORDER BY B — Will not use index

• A IN (1,2) ORDER BY B – Does not help either

• A>5 ORDER BY A — Will

• ORDER BY A ASC B DESC – Does not
0
maghamed #
Сделайте
SELECT * FROM the_table WHERE id = 1 AND age > 20
UNION ALL
SELECT * FROM the_table WHERE id = 2 AND age > 20
UNION ALL
SELECT * FROM the_table WHERE id = 10 AND age > 20
UNION ALL
SELECT * FROM the_table WHERE id = 20 AND age > 20

Ну и если допустим вам нужно вывести всего 10 отсортированых записей, то добавьте лимит и сортировку в каждый запрос, чтобы выгребал меньше. А потом и общий лимит
и сортировку.

Так каждый запрос будет использовать обе части индекса :-)
–14
tuta_larson #
merge индексы добавили еще в MySQL 5.0
НЛО прилетело и опубликовало эту надпись здесь
0
bat #
Не знаю как это работает в MySQL, но именно так как вы написали это работает в Firebird и работает весьма неплохо…

А вцелом от оптимизатора MySQL впечатления не очень… может я не умею его готовить…
0
maghamed #
>может я не умею его готовить…

Вполне вероятно :-)
0
maghamed #
index merge это запрос вида
SELECT * FROM the_table WHERE id = 1 OR age = 22
имея индексы по полю ID и индекс по полю age
0
proc #
Спасибо. А то тут впахиваешь и некогда за новинками следить.

Особо порадовало, что логи можно вести в таблицах. Ну и наличие events ооочень полезно
0
kot9lpa #
а я раньше вел логи свои в таблицах, используя триггеры
+1
imya_polzovatelya #
про поднаготную партишенинга можно было бы по-больше написать
остальное, по большому счему, ерунда
xpath — имхо, вообще, бред. дань моде на xml databases
+4
xsubst #
В целом — неплохая выжимка.
Но немного прокомментирую:

>> Разбиение по хеш-функции. В этом виде разбиения можно указать функцию, по которой будут разделяться данные:

На самом деле, указывается выражение, результат которого будет хешироваться, а по результату хеширования mysql будет определять в какую партицию попадет искомая строка. Подобная схема обычно используется для равномерного распределения данных по заданному количеству партиций.

Стоило также рассказать о «Composite partitioning» (субпартиционировании).

>> События (events)

На мой взгляд термин получился неправильный. Mysql использует формулировку «Event scheduler», что можно смело перевести как, скажем, «планировщик задач». Будет намного нагляднее.

>> 4. Удобство администрирования: Начиная с версии MySQL 5.1 появилась возможность сохранения логов сервера в таблицах.

А тут стоило упомянуть, что при сохранении логов в таблицы можно очень потерять в производительности (о чем недвусмысленно написано в доках), поэтому на боевом сервере лучше не включать. Либо использовать только для отладки.
0
tuta_larson #
> Стоило также рассказать о «Composite partitioning» (субпартиционировании).
Ну про партишенинг книгу можно отдельную написать :)

Насчет Event scheduler согласен с вами, но в большинстве русских источников используется именно термин «события»

> поэтому на боевом сервере лучше не включать
Включение general log'а естественно будет замедлять работу MySQL, даже при записи в файл. Но включить его на час другой скажем, чтобы посмотреть что там творится никого сильно не напряжет. Зато будет возможность посмотреть статистику в любых разрезах и не париться с парсерами логов.
0
xvoland #
Больше всего понравилось разбиение таблиц — круто!
+1
dewil #
в PGSQL это есть давно.
радует, что и мускул начал идти правильным путем.
0
Joka #
mysqlslap — интересно на это будет поглядеть. насколько эффективными будут их собственные стресс-тесты на базу ??

разбиение на партиции — наконец-то :)

запись логов сервера в таблицы — сомнительное счастье. разве что только для отладочного сервера. для продакшена не дай Боже такое вообще включить :)
0
maxshopen #
Это всё замечательно, вот только оптимизм по поводу «скорого выхода» — преждевременный.
MySQL 5.1 разрабатывается уже более 5 лет, и хотя на данный момент имеет статус релиз-кандидат, про сроки окончательного перехода в стабильную версию прогнозов никто не делает, т.к. есть не поправленные баги, и когда они будут исправлены — неизвестно. Хотелось бы конечно побыстрее
0
maxshopen #
более 3-х лет, опечатался. извините
0
ksm #
Уже сейчас 5.1 имеет меньше багов, чем релиз 5.0 в свое время :-), так что имхо скоро
–2
B_dot #
Гораздо интереснее выход MySQL Cluster 5.1, где они наконец-то добавят возможность хранить данные на диске, если в оперативку не влезают.
+1
ksm #
1. Это будет касаться только неиндексируемых данных, поля с индексом в памяти всегда
2. И в 5.0 бинарные поля (TEXT/BLOB) храняться на диске, а в памяти первые 256 байт
–2
Jekel #
То что в 5.1 пихнули функционал Cron`а очень даже хорошо, можно будет в него вынести все/часть запросы что сейчас запускаются через скрипты по крону.
/me скромно мечтает когда-же разработчики реализуют возможность делать ограничения на размер БД средствами mysql
–12
brom #
В новой версии добавлена возможность создания событий. Эта функциональность позволяет настроить выполнение периодических SQL запросов или процедур. Например, выполнять необходимый пересчет данных раз в день.


CREATE EVENT RECALC_SUMM
ON SCHEDULE EVERY 1 WEEK

Вы уж определитесь, либо раз в «WEEK», либо раз в «день»
–2
pouet0r #
«Теперь XML документ, сохраненный в таблицу, доступен пользователю в виде дерева. Можно получить любое значение из дерева и обновить лишь нужный узел.»

Это как-бы если у тебя лежит xml в поле типа «TEXT» например, или что-то спецефическое?
–5
tuta_larson #
Да, в текстовое поле можно положить xml и работать с ним через MySQL
0
pouet0r #
Ясно, спасибо
0
ksm #
Выжимка про 5.1 хорошая :-), разъясняющие комменты:

Row-based replication — также используется для репликации между кластерами. Кроме того statement-based replication не может корректно передавать некоторые функции (например UUID()). Но я бы отметил псевдо режим репликации: MIXED. Он по умолчанию идет в statement, но если появляются запросы, которые не могут быть корректно переданы через statement, то автоматом временно переключается в row.
Да еще: row репликации генерит больше данных для передачи по каналу связи мастер-слейв.
Кроме того в 5.1. поддерживается циклическая репликация мастер-мастер (т.е. оба сервера являются и мастером, и слейвом).

–2
floor12 #
уже на одном серваке стоит 50 а на друго 51 рц, а я даже и не знал что там будут такие новинки, надо попробовать что нибудь из этого…
–1
developer #
в избранное
–1
ad_Wolf #
никто не знает, как обновить мускул под XAMPP?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.