MySQL: руководство профессионала

Паутов Алексей В.

Это не совсем книга. Просто по ходу работы и изучения пакета у меня накопилось немало заметок, которые я в конце концов собрал воедино и опубликовал с оглавлением и под единым названием. Данные заметки относятся к версиям 4 и 5 пакета MySQL. По ходу текста особо отмечены места, относящиеся к специфической версии пакета.

Введение

Данные заметки относятся к версиям 4 и 5 пакета MySQL. По ходу текста особо отмечены места, относящиеся к специфической версии пакета. Необходимо также отметить, что эти заметки логически продолжают книгу MySQL: Руководство администратора и ориентированы на ту же аудиторию.

Данный материал подготовлен Паутовым Алексеем в рамках некоммерческого проекта RussianLDP:MySQL. При любом использовании ссылка на автора и проект обязательна!

Глава 1. Точная математика

MySQL 5.1 обеспечивает поддержку для точной математики: числовая обработка значения, которая приводит к чрезвычайно точным результатам, и высокой степени контроль над недопустимыми значениями. Точность основана на этих двух свойствах:

SQL-режимы, которые управляют тем, как строг сервер относительно принятия или отклонения недопустимых данных.

MySQL-библиотека для арифметики с фиксированной запятой.

Эти свойства имеют несколько импликаций для числовых операций:

Точные вычисления : для получения точного значения вычисления не представляют ошибки с плавающей запятой. Вместо этого, используется высокая точность. Например, число типа .0001 обрабатывается как точное значение, а не как приближенное, и суммирование этого 10000 раз производит результат точно 1, а не значение, близкое к 1.

Четкое поведение округления : для чисел высокой точности результат ROUND() зависит только от параметра, а не от относящихся к окружению факторах типа того, как основная библиотека C работает.

Независимость от платформы: операции на точных числовых значениях дают тот же самый результат на различных платформах, типа Windows и Unix.

Контроль над обработкой недопустимых значений: переполнение и деление на нуль обнаруживаются и могут обрабатываться как ошибки. Например, Вы можете обрабатывать значение, которое является слишком большим для столбца, как ошибку, а не как наличие значения, усеченного так, чтобы попасть внутрь диапазона типа данных столбца. Точно так же Вы можете обрабатывать деление на нуль как ошибку, а не как операцию, которая производит результат NULL. Выбор подхода определен установкой переменной системы sql_mode.

Важный результат этих свойств: MySQL 5.1 обеспечивает высокую степень согласия со стандартом SQL.

Следующее обсуждение покрывает несколько аспектов того, как работает высокая точность (включая возможные несовместимости со старыми прикладными программами). В конце есть некоторые примеры.

1.1. Типы числовых значений

Контекст математической точности для операций с точным значением включает типы данных с точным значением (DECIMAL и целочисленные типы) и числовые литералы с точным значением. Типы данных с приблизительным значением и числовые литералы все еще обработаны как числа с плавающей запятой.

Числовые литералы с точным значением имеют целочисленную, дробную части или обе. Они могут быть со знаком или без него. Примеры: 1, .2, 3.4, -5, -6.78, +9.10.

Числовые литералы с приблизительным значением представляются в экспоненциальном формате с мантиссой и экспонентой. Любая из частей или обе могут иметь знак. Примеры: 1.2E3, 1.2E-3, -1.2E3, -1.2E-3.

Два числа, которые выглядят одинаково, могут не быть оба точными или приблизительными. Например, 2.34 представляет собой число с точным значением (с фиксированной запятой), в то время как 2.34E0 задает число с приблизительным значением (с плавающей запятой).

Тип данных DECIMAL является типом с фиксированной запятой, и вычисления точны. В MySQL тип DECIMAL имеет несколько синонимов: NUMERIC, DEC, FIXED. Целочисленные типы также типы с точным значением.

Типы данных FLOAT и DOUBLE являются типами с плавающей запятой, и вычисления приблизительны. В MySQL типы, которые являются синонимичными с FLOAT или DOUBLE, это DOUBLE PRECISION и REAL.

1.2. Изменения типа данных DECIMAL

Этот раздел обсуждает характеристики типа данных DECIMAL (и синонимов) в MySQL 5.1, со специфическим отношением к следующим темам

Максимальное число цифр

Формат хранения

Требования к памяти

Ненормативное MySQL расширение к верхнему диапазону столбцов DECIMAL

Возможные несовместимости с прикладными программами, которые написаны для старых версий MySQL, отмечены в этом разделе.

Синтаксис объявления для столбца DECIMAL: DECIMAL(M,D). Диапазоны значений для параметров в MySQL 5.1 следующие:

M: максимальное число цифр (точность). Это имеет диапазон от 1 до 65. Старые версии MySQL позволяли диапазон от 1 до 254.

D: число цифр направо от десятичной точки (масштаб). Это имеет диапазон от 0 до 30 и должно быть не больше, чем M.

Максимальное значение 65 для M означает, что вычисления на значениях DECIMAL точны до 65 цифр. Это ограничение точности в 65 цифр также применяется к числовым литералам с точным значением, так что оно задает максимальный диапазон таких литералов. В старых версиях MySQL десятичные значения могли иметь до 254 цифр. Однако, вычисления были выполнены, используя числа с плавающей запятой и таким образом были приблизительны, не точны.

Значения для столбцов DECIMAL в MySQL 5.1 сохранены, используя двоичный формат, который упаковывает девять десятичных цифр в четыре байта. Требования к памяти для целочисленных и дробных частей каждого значения определены отдельно. Каждые девять цифр требуют четырех байт, и любые цифры сверх этого требуют некоторой доли четырех байтов. Например, DECIMAL(18,9) имеет девять цифр с обеих сторон десятичной точки, так что целочисленная и дробная части требуют четырех байтов каждая. Столбец DECIMAL(20,10) имеет по десять цифр с обеих сторон десятичной точки. Каждая часть требует четырех байтов для девяти из цифр и одного байта для остающейся цифры.

Память, требуемая для остающихся цифр, показана в следующей таблице:

Остающиеся цифры | Число байтов

0 | 0

1 | 1

2| 1

3 | 2

4 | 2

5 | 3

6 | 3

7 | 4

8 | 4

9 | 4

В отличие от старых версий MySQL (до 5.0.3), столбцы DECIMAL в MySQL 5.1 не сохраняют символ + или цифры 0 в начале значения. Если Вы вставляете +0003.1 в столбец DECIMAL(5,1), это сохранено как 3.1. Прикладные программы, которые полагаются на старое поведение, должны измениться, чтобы обработать это изменение.

Столбцы DECIMAL в MySQL 5.1 не позволяют значения больше, чем диапазон, подразумеваемый по определению столбца. Например, столбец DECIMAL(3,0) поддерживает диапазон от -999 до 999. А столбец DECIMAL(M,D) позволяет M цифр налево от десятичной точки. Это не совместимо с прикладными программами, полагающимися на старые версии MySQL, которые разрешали сохранять дополнительную цифру вместо знака +.

SQL-стандарт требует, чтобы точность NUMERIC(M,D) была точно M цифр. Для DECIMAL(M,D) стандарт требует точности по крайней мере M цифр, но позволяет больше. В MySQL DECIMAL(M,D) и NUMERIC(M,D) то же самое, и оба типа имеют точность ровно M цифр.

1.3. Обработка выражений

Числа с точным значением используются как даны всякий раз, когда возможно. Например, числа в сравнениях используются точно как даны, без изменения в значении. В строгом SQL-режиме для INSERT в столбец с точным типом данных (DECIMAL или целое число), значение вставлено с точным значением, если оно внутри диапазона столбца. Когда значение получено, оно должно быть таким же как то, что было вставлено. Без строгого режима допустимо усечение для INSERT.

Обработка числового выражения зависит от значений, которое выражение содержит:

Если любые приблизительные значения присутствуют, выражение оценено приблизительно, используя арифметику с плавающей запятой.

Если никакие приблизительные значения не присутствуют, выражение содержит только точные значения. Если любое точное значение содержит дробную часть (значение после десятичной точки), выражение оценено, используя точную арифметику DECIMAL и имеет точность 65 цифр.

Иначе, выражение содержит только целочисленные значения. Выражение точно и оценено, используя целочисленную арифметику и имеет точность BIGINT (64 бита).

Если числовое выражение содержит любые строки, они преобразованы в значения с плавающей запятой двойной точности, и выражения приблизительны.

На вставки в числовые столбцы воздействует SQL-режим, который управляется переменной системы sql_mode. Следующее обсуждение упоминает строгий режим (выбранный значениями режима STRICT_ALL_TABLES или STRICT_TRANS_TABLES) и ERROR_FOR_DIVISION_BY_ZERO. Чтобы включить все ограничения, Вы можете просто использовать режим TRADITIONAL, который включает строгие значения режима и ERROR_FOR_DIVISION_BY_ZERO:

mysql> SET sql_mode='TRADITIONAL';

Если число вставлено в столбец точного типа (DECIMAL или целое число), оно вставлено с точным значением, если находится внутри диапазона столбца.

Если значение имеет слишком много цифр в дробной части, происходит округление, и будет сгенерировано предупреждение. Округление выполнено как описано в разделе "".

Если значение имеет слишком много цифр в целочисленной части, оно слишком большое и обработано следующим образом:

Если строгий режим не допускается, значение усечено к самому близкому допустимому значению, и сгенерировано предупреждение.

Если строгий режим допускается, происходит ошибка переполнения.

По умолчанию, деление на нуль производит результат NULL и никакого предупреждения. С включенным режимом SQL ERROR_FOR_DIVISION_BY_ZERO MySQL обрабатывает деление на нуль по-другому:

Если строгий режим не допускается, происходит предупреждение.

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

Другими словами, вставки и модификации, включающие выражения, которые выполняют деление на нуль, могут обрабатываться как ошибки, но это требует ERROR_FOR_DIVISION_BY_ZERO в дополнение к строгому режиму.

Предположим, что мы имеем эту инструкцию:

INSERT INTO t SET i = 1/0;

Это что случается для комбинации строгого режима и ERROR_FOR_DIVISION_BY_ZERO:

Значение sql_mode | Результат

'' (значение по умолчанию) | Никаких предупреждений и ошибок: i установлен в NULL.

strict | Никаких предупреждений и ошибок: i установлен в NULL.

ERROR_FOR_DIVISION_BY_ZERO | Никаких ошибок, но есть предупреждение: i установлен в NULL.

strict,ERROR_FOR_DIVISION_BY_ZERO | Ошибка: никакая строка не вставлена.

Для вставок строк в числовые столбцы, преобразование из строки в число обработано следующим образом, если строка имеет нечисловое содержание:

Строка, которая не начинается с числа, не может использоваться как число, и производит ошибку в строгом режиме или предупреждение в любом другом. Это включает пустую строку.

Строка, которая начинается с числа, может быть преобразована, но конечная нечисловая часть усечена. Если усеченная часть содержит что-нибудь другое, чем пробелы, это производит ошибку в строгом режиме или предупреждение в любом другом.

1.4. Поведение округления

Этот раздел обсуждает точность математического округления для функции ROUND() и для вставок в столбцы с типами с точным значением.

Функция ROUND() работает по-разному в зависимости от того, является ли параметр точным или приблизительным числом:

Для числа точного значения ROUND() использует метод "округления половины": значение с дробной частью .5 или больше округлено до следующего целого числа, если положительное, или до предыдущего целого числа, если отрицательное. Значения с дробной частью меньше, чем .5, округлены до предыдущего целого числа, если положительные, или до следующего, если отрицательные.

Для числа приблизительного значения результат зависит от библиотеки C. На многих системах это означает, что значение с любой дробной частью округлено ROUND() к самому близкому четному целому числу.

Следующий пример показывает, как округление отличается для точных и приблизительных значений:

mysql> SELECT ROUND(2.5), ROUND(25E-1);

+------------+--------------+

| ROUND(2.5) | ROUND(25E-1) |

+------------+--------------+

| 3 | 2 |

+------------+--------------+

Для вставок в DECIMAL или целочисленный столбец, если адресат представляет собой точный тип данных, используется метод "округления половины" независимо от того, является ли значение, которое будет вставлено, точным или приблизительным:

mysql> CREATE TABLE t (d DECIMAL(10,0));

Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO t VALUES(2.5),(2.5E0);

Query OK, 2 rows affected, 2 warnings (0.00 sec)

Records: 2 Duplicates: 0 Warnings: 2

mysql> SELECT d FROM t;

+------+

| d |

+------+

| 3 |

+------+

1.5. Примеры математической точности

Этот раздел обеспечивает некоторые примеры, которые показывают запросы с математической точностью в MySQL 5.1.

Пример 1. Числа используются с их точным значением, как даны, когда возможно:

mysql> SELECT .1 + .2 = .3;

+--------------+

| .1 + .2 = .3 |

+--------------+

| 1 |

+--------------+

Для значений с плавающей запятой, результаты неточны:

mysql> SELECT .1E0 + .2E0 = .3E0;

+--------------------+

| .1E0 + .2E0 = .3E0 |

+--------------------+

| 0 |

+--------------------+

Другой способ увидеть различие в точной и приблизительной обработке значения состоит в том, чтобы добавить маленькое число к сумме много раз. Рассмотрите следующую сохраненную процедуру, которая добавляет .0001 к переменной 1000 раз:

CREATE PROCEDURE p ()

BEGIN

DECLARE i INT DEFAULT 0;

DECLARE d DECIMAL(10,4) DEFAULT 0;

DECLARE f FLOAT DEFAULT 0;

WHILE i < 10000 DO

SET d = d + .0001;

SET f = f + .0001E0;

SET i = i + 1;

END WHILE;

SELECT d, f;

END;

Сумма для d и f логически должна быть 1, но это истинно только для десятичного вычисления. Вычисление с плавающей запятой представляет маленькие ошибки:

+--------+------------------+

| d | f |

+--------+------------------+

| 1.0000 | 0.99999999999991 |

+--------+------------------+

Пример 2. Умножение выполняется с масштабом, требуемым стандартом SQL. То есть, для двух чисел X1 и X2, которые имеют масштаб S1 и S2, масштаб результата: S1+S2:

mysql> SELECT .01 * .01;

+-----------+

| .01 * .01 |

+-----------+

| 0.0001 |

+-----------+

Пример 3. Поведение округления четко:

Поведение округления (например, с функцией ROUND()) независимо от реализации основной библиотеки C, что означает, что результаты непротиворечивы на разных платформах.

Округление для столбцов с точным значением использует округление половины, как показано здесь:

mysql> SELECT ROUND(2.5), ROUND(-2.5);

+------------+-------------+

| ROUND(2.5) | ROUND(-2.5) |

+------------+-------------+

| 3 | -3 |

+------------+-------------+

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

mysql> SELECT ROUND(2.5E0), ROUND(-2.5E0);

+--------------+---------------+

| ROUND(2.5E0) | ROUND(-2.5E0) |

+--------------+---------------+

| 2 | -2 |

+--------------+---------------+

Пример 4. В строгом режиме вставка значения, которое является слишком большим, приводит к переполнению и ошибке, а не к усечению до допустимого значения. Когда MySQL не выполняется в строгом режиме, происходит усечение к допустимому значению:

mysql> SET sql_mode='';

Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE t (i TINYINT);

Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO t SET i = 128;

Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> SELECT i FROM t;

+------+

| i |

+------+

| 127 |

+------+

1 row in set (0.00 sec)

Однако, условие переполнения происходит, если включен строгий режим:

mysql> SET sql_mode='STRICT_ALL_TABLES';

Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE t (i TINYINT);

Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO t SET i = 128;

ERROR 1264 (22003): Out of range value adjusted for column 'i' at row 1

mysql> SELECT i FROM t;

Empty set (0.00 sec)

Пример 5: В строгом режиме и с настройкой ERROR_FOR_DIVISION_BY_ZERO деление на нуль вызывает ошибку, а не результат NULL.

В нестрогом режиме деление на нуль имеет результат NULL:

mysql> SET sql_mode='';

Query OK, 0 rows affected (0.01 sec)

mysql> CREATE TABLE t (i TINYINT);

Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO t SET i = 1 / 0;

Query OK, 1 row affected (0.00 sec)

mysql> SELECT i FROM t;

+------+

| i |

+------+

| NULL |

+------+

1 row in set (0.03 sec)

Однако, деление на нуль выдает ошибку, если соответствующие SQL-режимы активны:

mysql> SET sql_mode='STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO';

Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE t (i TINYINT);

Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO t SET i = 1 / 0;

ERROR 1365 (22012): Division by 0

mysql> SELECT i FROM t;

Empty set (0.01 sec)

Пример 6. До MySQL 5.0.3 литералы с точным значением и с приблизительным значением преобразованы в значения с плавающей запятой двойной точности:

mysql> SELECT VERSION();

+------------+

| VERSION() |

+------------+

| 4.1.18-log |

+------------+

1 row in set (0.01 sec)

mysql> CREATE TABLE t SELECT 2.5 AS a, 25E-1 AS b;

Query OK, 1 row affected (0.07 sec)

Records: 1 Duplicates: 0 Warnings: 0

mysql> DESCRIBE t;

+-------+-------------+------+-----+---------+-------+

+-------+-------------+------+-----+---------+-------+

| a | double(3,1) | | | 0.0 | |

| b | double | | | 0 | |

+-------+-------------+------+-----+---------+-------+

2 rows in set (0.04 sec)

Начиная с MySQL 5.0.3, литерал с приблизительным значением все еще преобразован в значение с плавающей запятой, но литерал с точным значением обработан как DECIMAL:

mysql> SELECT VERSION();

+-----------------+

| VERSION() |

+-----------------+

| 5.1.6-alpha-log |

+-----------------+

1 row in set (0.11 sec)

mysql> CREATE TABLE t SELECT 2.5 AS a, 25E-1 AS b;

Query OK, 1 row affected (0.01 sec)

Records: 1 Duplicates: 0 Warnings: 0

mysql> DESCRIBE t;

+-------+-----------------------+------+-----+---------+-------+

+-------+-----------------------+------+-----+---------+-------+

| a | decimal(2,1) unsigned | NO | | 0.0 | |

| b | double | NO | | 0 | |

+-------+-----------------------+------+-----+---------+-------+

2 rows in set (0.01 sec)

Пример 7. Если параметр функции точный числовой тип, результат также точный числовой тип, с масштабом по крайней мере, как у параметра. Рассмотрите эти инструкции:

mysql> CREATE TABLE t (i INT, d DECIMAL, f FLOAT);

mysql> INSERT INTO t VALUES(1,1,1);

mysql> CREATE TABLE y SELECT AVG(i), AVG(d), AVG(f) FROM t;

Результаты до MySQL 5.0.3:

mysql> DESCRIBE y;

+--------+--------------+------+-----+---------+-------+

+--------+--------------+------+-----+---------+-------+

+--------+--------------+------+-----+---------+-------+

Результат двойной точности, независимо от типа параметра. А вот результаты в MySQL 5.0.3 и выше:

mysql> DESCRIBE y;

+--------+---------------+------+-----+---------+-------+

+--------+---------------+------+-----+---------+-------+

+--------+---------------+------+-----+---------+-------+

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

Глава 2. Типы памяти и таблиц

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

С MySQL 5.1 MySQL AB представил новую подключаемую архитектуру памяти, которая позволяет типам памяти загружаться и выгружаться по мере надобности. Если раньше приходилось перекомпилировать сервер, чтобы встроить поддержку соответствующего типа таблиц, теперь это не требуется.

Эта глава описывает каждый из типов памяти MySQL, кроме NDB Cluster. Это также содержит описание новой архитектуры хранения.

2.1. Краткий обзор архитектуры хранения данных в MySQL

Архитектура хранения данных в MySQL позволяет профессионалу базы данных выбирать специализированный тип памяти для специфической потребности прикладной программы. Сервер MySQL изолирует прикладного программиста и DBA от всех подробностей реализации низкого уровня памяти, обеспечивая непротиворечивую и простую модель прикладной программы и API. Таким образом, хотя имеются различные возможности различных типов памяти, прикладная программа ограждена от этих различий.

Такой подход обеспечивает стандартный набор управления и услуг поддержки, которые являются общими среди всех основных типов памяти. Эта эффективная и модульная архитектура обеспечивает огромные выгоды для всех.

Прикладной программист и DBA взаимодействует с базой данных MySQL через Connector API и сервисные уровни, которые стоят выше типов памяти. Если изменения прикладной программы вызывают необходимость сменить тип памяти, то не придется особо напрягаться.

2.1.1. Общий уровень сервера базы данных

Подключаемая архитектура памяти MySQL представляет собой компонент сервера базы данных, который является ответственным за выполнение фактических операции ввода-вывода данных для базы данных, а также предоставления и предписания некоторых наборов свойств, в которых нуждается специфическая прикладная программа. Главная польза в том, что Вы в любой момент используете то, что Вам удобно, затрачивая минимум усилий и экономя много ресурсов системы сервера.

Чем вообще отличаются типы памяти? Основные отличия включают:

Concurrency: некоторые прикладные программы имеют более гранулированные требования блокировки (типа блокировок уровня строки) чем другие. Выбор правильной блокирующей стратегии может уменьшать непроизводительные затраты и, следовательно, улучшать полную эффективность. Эта область также включает поддержку возможностей типа многоверсионного управления параллелизма или предоставления кадра чтения.

Transaction Support: не каждая прикладная программа нуждается в транзакциях, но для тех, которым это надо, имеются очень хорошо определенные требования типа совместимости с ACID.

Referential Integrity: иногда надо, чтобы сервер в реляционной базе данных поддерживал справочную целостность через DDL-определенные внешние ключи.

Physical Storage: это включает все от полного размера страницы для таблиц и индексов до формата, используемого для сохранения данных на физический диск.

Index Support: различные прикладные программы имеют тенденцию извлекать пользу из различных индексных cтратегий. Каждый тип памяти вообще имеет собственные методы индексации, хотя некоторые (типа индексов B-tree) общие на почти всех типах.

Memory Caches: различные прикладные программы лучше отвечают одним кэширующим cтратегиям, чем другим, хотя некоторые кэши памяти общие на всех типах хранения.

Performance Aids: это включает многократные потоки ввода-вывода для параллельных операций, параллелизма потоков, введения контрольных точек базы данных, объемной обработки вставки и тому подобных функций.

Miscellaneous Target Features: это может включать поддержку для географических операций, ограничения защиты для некоторых операций манипулирования данными и других подобных свойств.

Каждый набор съемных компонентов инфраструктуры памяти разработан, чтобы предложить выборочный набор выгод для специфической прикладной программы. Наоборот, уход от набора лишних свойств компонента уменьшает ненужные непроизводительные затраты. Надо усвоить, что понимание набора требований специфической прикладной программы и выбор соответствующего типа памяти MySQL может иметь драматическое воздействие на полную эффективность системы.

2.1.2. Съемная архитектура памяти

В MySQL 5.1 MySQL AB представила новую съемную архитектуру памяти, которая позволяет загружать и выгружать типы памяти (ранее известные как драйверы таблиц) по мере надобности, не перезапуская сервер.

2.1.2.1. Подключение типа памяти

Прежде, чем тип памяти сможет использоваться, сменная общедоступная библиотека должна быть загружена в MySQL используя инструкцию INSTALL PLUGIN. Например, если сменный тип памяти EXAMPLE называется ha_example, а общедоступная библиотека именована ha_example.so, то Вы загружаете это следующей инструкцией:INSTALL PLUGIN ha_example SONAME 'ha_example.so';

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

2.1.2.2. Отключение типа памяти

Чтобы отключить тип памяти, используйте инструкцию UNINSTALL PLUGIN:UNINSTALL PLUGIN ha_example;

Если Вы отключаете тип памяти, который необходим существующим таблицам, те таблицы станут недоступными, но будут все еще присутствовать на диске. Гарантируйте, что не имеется никаких таблиц, использующих этот тип памяти прежде, чем Вы его отключите.

2.1.2.3. Безопасность и сменные типы памяти

Чтобы устанавливать съемный тип памяти, сменный файл должен быть размещен в сменном каталоге MySQL, а пользователь, выдающий инструкцию INSTALL PLUGIN должен иметь привилегию INSERT для таблицы mysql.plugin.

2.2. Обеспечиваемые типы памяти

MySQL 5.1 поддерживает следующие типы памяти:

MyISAM: применяемый по умолчанию тип памяти MySQL, который наиболее используется в Web, хранилищах данных и других средах прикладных программ. MyISAM обеспечивается во всех конфигурациях MySQL. Описан в книге "Руководство администратора СУБД MYSQL", глава 7, раздел "".

InnoDB: использован для прикладных программ диалоговой обработки запросов и ряда свойств, включая поддержку транзакций ACID и внешние ключи. InnoDB включен по умолчанию во все двоичные дистрибутивы MySQL 5.1. Описан в книге "Руководство администратора СУБД MYSQL", глава 7, раздел "".

: работает с многократными потоками и безопасной средой транзакции, которая безопасно хранит данные при обеспечении весьма высокой производительности.

ПРЕДУПРЕЖДЕНИЕ: Falcon в настоящее время обеспечивается только внутри ветки MySQL 5.1 и не рассматривается готовым к выпуску. Это обеспечивается только для целей тестирования и оценки на этой стадии.

Memory: сохраняет все данные в RAM для чрезвычайно быстрого доступа в средах, которые требуют быстрых поисковых таблиц. Этот тип памяти был прежде известен как HEAP. Описан в книге "Руководство администратора СУБД MYSQL", глава 7, раздел "".

Merge: позволяет MySQL DBA или разработчику логически группировать ряд идентичных MyISAM-таблиц и ссылаться на них как на один объект. Хороши для VLDB-сред, типа хранилищ данных. Описан в книге "Руководство администратора СУБД MYSQL", глава 7, раздел "".

: обеспечивает совершенное решение для сохранения и восстановления больших количеств редко используемых исторических, архивированных данных.

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

NDB Cluster (он же NDB): кластерный вариант базы данных, который особенно подходит для прикладных программ с высокоэффективными потребностями поисковой таблицы, которые также требуют самой высокой возможной степени полезного времени и доступности. Описан подробно в моей работе "".

: хранит данные в текстовых файлах, использующих отделяемый запятыми формат значений. Вы можете использовать CSV, чтобы легко обмениваться данными между другим программным обеспечением и прикладными программами, которые могут импортировать и экспортировать в формате CSV.

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

: это тип памяти, который не делает ничего. Вы можете создавать таблицы с ним, но никакие данные не могут быть сохранены в них или восстановлены из них. Цель этого типа памяти в том, чтобы служить примером того, как вообще надо писать типы памяти. Это прежде всего представляет интерес для разработчиков.

Эта глава описывает каждый из типов памяти MySQL, кроме MySQL Cluster.

Важно не забыть, что Вы не ограничены использованием одного и того же типа памяти для всего сервера или схемы: Вы можете использовать различные типы памяти для каждой таблицы в схеме.

2.2.1. Выбор типа памяти

Различные типы памяти, обеспеченные MySQL, разработаны для различных случаев использования. Чтобы использовать съемную архитектуру памяти, хорошо иметь представление относительно выгод и недостатков различных типов памяти (хранения). Следующая таблица обеспечивает краткий обзор некоторых вариантов, обеспеченных MySQL:

Свойство MyISAM Memory InnoDB Arhive NDB Ограничения памяти 256 TB 64TB 384 EB[4] ТранзакцииНетНетДаНетДа Блокировка степени детализации Таблица Таблица Строка Строка Строка MVCC (кадр чтения) НетНет ДаДа Нет География Да Нет Да[1] Да[1] Да[1] Индексы B-tree Да Да Да Нет Да Hash-индексы Нет Да Нет Нет Да Поисковые индексы Full-text Да Нет Нет Нет Нет Индексы для кластера Нет Нет Да Нет Нет Кэширование данных Нет Не опред. Да Нет Да Кэширование индексов Да Не опред. Да Нет Да Сжатие данных Да Нет Нет Да Нет Шифрование данных[2] Да Да Да Да Да Cluster Нет Нет Нет Нет Да Репликация[3] Да Нет Да Да Да Поддержка внешнего ключа Нет Нет Да Нет Нет Копия / восстановление на момент времени[3] Да Да Да Да Да Поддержка кэша запросов Да Да Да Да Да Модификация статистики для словаря данных Да Да Да ДаДа

Некоторые необходимые пояснения:

[1] Поддерживает пространственные типы данных, но не выполняет индексацию таких данных.

[2] Выполнено в сервере (через функции шифрования), а не в типе памяти.

[3] Выполнено в сервере, а не в типе памяти.

[4] EB = exabyte (экзабайт = 1024 * 1024 терабайт).

2.2.2. Сравнение транзакционных и не транзакционных таблиц

Транзакционно-безопасные таблицы (TST) имеют несколько преимуществ над не транзакционно-безопасными таблицами (NTST):

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

Вы можете объединять много инструкций и принимать их все в то же самое время инструкцией COMMIT (если autocommit выключен).

Вы можете выполнять ROLLBACK, чтобы игнорировать Ваши изменения (если autocommit выключен).

Если произошел сбой модификации, все Ваши изменения вернутся. С не транзакционно-безопасными таблицами все изменения, которые имели место, постоянны.

Транзакционно-безопасные типы памяти могут обеспечивать лучший параллелизм для таблиц, которые делают много модификаций одновременно с чтением.

Вы можете объединять транзакционно-безопасные и не транзакционно-безопасные таблицы в тех же самых инструкциях. Однако, хотя MySQL поддерживает несколько транзакционно-безопасных типов памяти (хранения), для самых лучших результатов, Вы не должны смешивать различные типы внутри транзакции с заблокированным autocommit. Например, если Вы делаете это, изменения для не транзакционно-безопасной таблицы все еще совершены немедленно и не могут быть прокручены обратно.

Не транзакционно-безопасные таблицы также имеют несколько преимуществ, которые происходят из того, что не имеется никаких непроизводительных затрат на транзакции:

Намного быстрее.

Более низкие требования дискового пространства.

Меньшее количество памяти требуется, чтобы выполнить модификации.

2.2.3. Другие типы памяти

Другие типы памяти могут быть доступны от третьих лиц, которые использовали Custom Storage Engine interface.

Вы можете находить подробную информацию в списке типов памяти третьего лица на странице MySQL Forge Storage Engines .

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

На текущий момент есть следующие сторонние типы памяти:

PrimeBase XT (PBXT) : PBXT был разработан для современного web-основанного параллелизма.

RitmarkFS RitmarkFS позволяет Вам обращаться и управлять файловой системой, используя SQL-запросы. RitmarkFS также поддерживает репликацию файловых систем и трэкинг изменений.

Distributed Data Engine : Open Source проект, который специализирован, чтобы обеспечить поддержку распределенных данных согласно статистике рабочей нагрузки.

mdbtools : съемный тип памяти, который позволяет доступ только для чтения к .mdb-файлам базы данных Microsoft Access.

solidDB for MySQL разработан для задание-критических реализаций, которые требуют транзакционные базы данных. solidDB многопоточный драйвер, который полностью поддерживает ACID со всеми ожидаемыми уровнями изоляции транзакции, блокировкой уровня строки и многоверсионным управлением параллелизма (MVCC) с не блокируемыми чтением и записью.

Для подробной информации относительно разработки типа памяти, который может использоваться со съемной архитектурой памяти обратитесь к в MySQL Internals.

2.3. Установка типа памяти

Когда Вы создаете новую таблицу, Вы можете определять, который тип памяти использовать, добавляя опцию ENGINE к инструкции CREATE TABLE:CREATE TABLE t (i INT) ENGINE = INNODB;

Если Вы опускаете опцию ENGINE или TYPE, используется заданный по умолчанию памяти. Обычно это MyISAM, но Вы можете изменять это, используя опцию сервера --default-storage-engine или --default-table-type, либо устанавливая опцию default-storage-engine или default-table-type в файле конфигурации my.cnf.

Вы можете устанавливать заданный по умолчанию тип памяти, который нужно использовать в течение текущего сеанса, устанавливая переменную storage_engine:SET storage_engine=MYISAM;

Когда MySQL установлен на Windows, используя MySQL Configuration Wizard, InnoDB может быть выбран как значение по умолчанию вместо MyISAM.

Чтобы преобразовывать таблицу из одного типа памяти в другой, используйте инструкцию ALTER TABLE, которая указывает новый тип памяти:ALTER TABLE t ENGINE = MYISAM;

Если Вы пробуете использовать тип памяти, который не компилируется в сервер (или компилируется, но дезактивирован), MySQL взамен создает таблицу, использующую заданный по умолчанию тип памяти, обычно MyISAM. Это поведение удобно, когда Вы хотите копировать таблицы между серверами MySQL, которые поддерживают различные типы памяти.

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

Для новых таблиц MySQL всегда создает .frm-файл, чтобы сохранить определения столбцов и таблицу. Индекс таблицы и данные может быть сохранен в одном или большем количестве других файлов, в зависимости от типа памяти. Сервер создает .frm-файл выше уровня типа памяти. Индивидуальные типы создают любые дополнительные файлы, требуемые для таблиц, с которыми они управляются. Если имя таблицы содержит специальные символы, имена для файлов таблицы содержат закодированные версии тех символов. База данных может содержать таблицы различных типов. То есть, не все таблицы должны быть созданы с тем же самым типом памяти.

2.4. Тип памяти Falcon

Тип памяти Falcon был разработан с современными требованиями базы данных в памяти, и особенно для использования в web-сайтах большого объема или другой среде, которая требует высокой эффективности, при обеспечении транзакций и регистрации функциональных возможностей, требуемых в этой среде.

Предупреждение

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

Falcon в настоящее время доступен только для 32-разрядной Windows и 32 или 64-разрядной Linux. Дополнительные платформы будут добавлены после alpha-версии.

2.4.1. Свойства Falcon

Falcon был разработан для систем, которые способны поддерживать большую память и многопоточные или мультиядерные среды CPU. Большинство 64-битных систем представляют собой идеальные платформы для Falcon, где имеется большое доступное пространство памяти и 2, 4 или 8-ядерные CPU. Это также может быть развернуто внутри стандартной 32-разрядной среды.

Falcon поддерживает ряд главных особенностей, которые делают возможным его применение в среде с большими нагрузками:

Multi Version Concurrency Control (MVCC) дает возможность записям и таблицам модифицироваться без непроизводительных затрат, связанных с блокировками уровня строки. Реализация MVCC фактически устраняет потребность блокировать таблицы или строки в течение процесса модификации.

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

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

Transaction-safe (полностью совместим с ACID) и способен обрабатывать многократные параллельные транзакции.

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

Продвинутые индексы B-Tree.

Сервер предписывает справочную целостность и всегда гарантирует проверку правильности данных.

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

Интеллектуальное дисковое управление автоматически управляет размером файла на диске, расширениями и восстановлением места.

Данные и индексное кэширование обеспечивают быстрый доступ к данным без требования загрузить индексные данные с диска.

Неявные точки сохранения гарантируют целостность данных в течение транзакций.

2.4.2. Параметры конфигурации

Параметры конфигурированы через стандартный файл my.cnf или my.ini. Параметры могут быть конфигурированы, определяя имя параметра и соответствующее значение через пробел. Значения Memory могут быть определены в байтах или числом, сопровождаемым kb, mb или gb.

falcon_min_record_memory (Record Cache Base) устанавливает минимальный объем памяти, который будет распределен для кэширования данных при записи. Когда кэш-память убирает мусор, процесс остановится, пока использование кэша не достигнет этого значения. Значение по умолчанию: falcon_max_record_memory/2 (10 MB).

falcon_max_record_memory (Record Cache Top) устанавливает максимальный размер памяти, которая будет распределена для кэширования данных при записи. Значение по умолчанию 20 MB.

falcon_page_cache_size (Page Cache Size) устанавливает объем памяти, который будет распределен для кэширования страниц из файла пространства таблицы. Значение по умолчанию 4 MB.

Связь между кэшем записи и кэшем страницы управляется информацией, которая кэшируется каждой системой. Целые записи, которые находятся в активном использовании (читаемые или модифицируемые) сохранены внутри кэша записи, однако, данные BLOB сохранены только внутри кэша страницы.

Кэш страницы используется, чтобы сохранить метаданные базы данных, данные BLOB и индексы таблицы.

Параметры Falcon также могут быть установлены в командной строке mysqld через использование следующих параметров командной строки:

– -falcon-max-record-memory=#

– -falcon-min-record-memory=#

– -falcon-page-cache-size=#

Вы можете также допускать и отключать тип памяти Falcon при запуске, обеспечивая эти параметры mysqld, если этот mysqld включает тип памяти Falcon:

– -falcon включает Falcon.

– -skip-falcon выключает Falcon.

2.4.3. Создание пространства таблиц Falcon

Внутри Falcon все данные внутри одной базы данных сохранены внутри одиночного пространства таблиц, которое в свою очередь сохранено внутри одного файла в структуре каталогов MySQL. Одиночная база данных Falcon создаст три главных файла. Один файл содержит данные Falcon и будет сохранен в файле с именем базы данных Falcon с расширением .fts. Например, таблицы Falcon определенные в базе данных test, будут сохранены внутри файла test.fts в каталоге баз данных MySQL.

Два других файла содержат дисковую копию последовательного файла регистрации Falcon. Они также созданы внутри области соответствующей базы данных. В будущем выпуске Вы сможете определить альтернативное расположение для этих журналов. Так с вышеупомянутым файлом данных примера test.fts журналы будет именованы test.fl1 и test.fl2.

Определения таблицы, как с другими типами памяти MySQL, сохранены в файл .frm в каталоге базы данных. Например, таблица falcontest в базе данных test создаст файл определения (описания) таблицы falcontest.frm в каталоге test.

При создании таблицы внутри базы данных MySQL, где соответствующий файл пространства таблиц Falcon не существует, это будет автоматически создано с файлом данных и журналами.

2.4.4. Создание таблиц и индексов в Falcon

Falcon поддерживает все стандартные типы данных столбцов, обеспечиваемые MySQL.

Чтобы создать таблицу, которая использует Falcon, примените опцию ENGINE = Falcon в инструкции CREATE TABLE:

CREATE TABLE names (id INT, fname VARCHAR (20),

lname VARCHAR (20)) ENGINE=Falcon

Индексы могут быть созданы, используя все стандартные методы, например, Вы можете явно определять индекс на столбце:

CREATE TABLE ids (id int, index (id)) ENGINE=Falcon

Генерируйте один как часть первичного ключа:

CREATE TABLE ids (id int),PRIMARY KEY (id) ENGINE=Falcon

Или Вы можете создавать много ключей и многократные индексы:

CREATE TABLE t1 (id int NOT NULL, id2 int NOT NULL, id3 int NOT NULL,

name CHAR(30), primary key (id, id2),

index index_id3 (id3)) ENGINE=Falcon

2.4.5. Принципы и терминология

Вы должны понять следующие базисные принципы и терминологию.

MySQL Falcon объединяет продвинутые методы с упрощенной структурой, которая приводит к высокоэффективной транзакционной базе данных, которая требует небольшого сопровождения или поиска неисправностей администратором базы данных.

Файл данных пользователя сохраняет данные Falcon.

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

Кэш страницы хранит страницы базы данных.

Кэш записи хранит копии активных и нейтральных записей.

Память системы хранит информацию контекста транзакции, индексные акселераторы и метаданные системы.

Рабочие потоки являются фоновыми потоками. Имеются два потока: поток "gopher" перемещает данные из последовательный файла регистрации Falcon в кэш страницы базы данных и из кэша страниц на диск. Второй поток программы записи страницы, который пишет страницы с blob.

2.4.5.1. Файл и структуры данных Falcon

Одиночные файлы базы данных Falcon хранят все данные записи, индексы, структуру базы данных и другую информацию. Индивидуальная информация сохранена в ряде страниц.

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

Страницы, кэшируемые в памяти используются, чтобы сохранить индексы, blob'ы и структурные данные для конкретного пространства таблиц. Активные записи сохранены внутри отдельного кэша записей.

Все транзакции в базе данных регистрируются и сохранены внутри отдельного журнала. Журнал автоматически сбрасывается и изменения записываются на диск, когда имеется команда COMMIT, когда включен auto-commit или автоматически через каждые 30 секунд, когда транзакции не используются.

2.4.5.2. Последовательный файл регистрации Falcon

Falcon использует последовательный файл регистрации, чтобы сохранить некоторые типы информации до того, как данные окончательно сохранятся в базе данных. Файл регистрации используется, чтобы сохранить следующие типы информации:

Записи данных в течение совершающейся фазы.

Физические изменения базы данных, требуемые для восстановления данных после аварийного отказа.

Логические изменения базы данных, требуемые для восстановления ресурса после аварийного отказа.

Изменения статуса для всех активных транзакций.

Все транзакции в Falcon записаны в последовательный файл регистрации Falcon, а затем переданы к базе данных автоматически, если включен AUTOCOMMIT, или вручную, когда используется команда COMMIT.

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

Обратите внимание, однако, что последовательный файл регистрации только модифицирует данные записи через кэш страницы в оперативной памяти. Фактические данные записи будут записаны на диск, когда происходит процесс контрольной точки. Исключительная ситуация к этому правилу: индексные и blob-записи, которые немедленно записаны на диск как часть процесса.

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

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

2.4.5.2.1. Процесс обратной перемотки

Обратные перемотки транзакции обработаны потоком для соответствующей транзакции. Процесс обратной перемотки выполняет следующие действия:

Отступающие индексные модификации.

Отменяет любые данные blob, созданные транзакцией.

Освобождает распределенные слоты записи.

Отменяет версию записи, созданную в памяти.

2.4.5.2.2. Групповое завершение транзакций

Для эффективности Falcon использует систему, которая гарантирует, что все ждущие обработки модификации последовательного файла регистрации записаны на диск в то же самое время. Falcon может иметь многократные активные транзакции, но транзакции записывают все ждущие обработки изменения последовательного файла регистрации на диск только однократно, уменьшая число записей на диск и улучшая полную эффективность последовательного файла регистрации. Например:

Транзакция 1 создает все необходимые входы файла регистрации и начинает записывать файл регистрации на диск.

В то время как транзакция 1 завершается, транзакции 2 и 3 записывают их входы в последовательный файл регистрации.

Как только транзакция 1 закончила физическую запись, или транзакция 2 или 3 (но не обе) запишут незаписанную часть данных, находящуюся в оперативной памяти, файл регистрации будет готов к сбросу на диск. Потому как обе транзакции произошли после с последней записи на диск последовательного файла регистрации, информация для обемх записана на диск в то же самое время.

В то время как транзакции 2 и 3 записывают, транзакции 4, 5 и 6 записываются в журнал в оперативной памяти. Когда запись для 2 и 3 завершается, входы для 4, 5 и 6 записаны.

Результат вышеупомянутого процесса: имеются только три физические записи на диск, даже при том, что имеется шесть транзакций в последовательности:

Транзакция 1,

Транзакции 2 и 3,

Транзакции 4, 5 и 6.

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

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

2.4.5.3. Восстановление аварийного отказа Falcon

Последовательный файл регистрации Falcon используется автоматически, когда первая таблица в базе данных Falcon открыта, чтобы восстановить транзакции и модифицировать базу данных. Когда транзакции и изменения записаны в последовательный файл регистрации, он включает входы, которые записывают изменения для всех областей базы данных, включая индексы, изменения для данных BLOB и любые структурные изменения базы данных.

В течение восстановления аварийного отказа Falcon исследует последовательный файл регистрации и идентифицирует первый вход, который не был передан к базе данных. Процесс восстановления записывает все незаписанные данные, изменяет индекс и данные blob, освобождая любые необходимые слоты записи (из удаленных записей) и завершая любые структурные изменения.

2.4.5.4. Кэши памяти Falcon

Falcon был разработан, чтобы выполняться лучше всего на системах с щедрыми объемами памяти. Кэши памяти, используемые Falcon подобны в некоторых отношениях другим СУБД и MySQL. Однако, структура кэш имеет ряд усовершенствований по сравнению с традиционной cтратегией кэширующей памяти. Механизмы, используемые Falcon относительно кэширования памяти включают:

Log Cache информация файла регистрации сохраняется в памяти и сбрасывается на диск, когда транзакции совершаются. Falcon хранит восемь окон для чтения и записи в журнал, и каждое окно 1 MB.

System and Index Cache данные, необходимые Falcon (определения таблицы и полей, состояние транзакции и т.д.) также поддерживаются в памяти для справочника. Кроме того, локальные индексные акселераторы представляют индексные сегменты, созданные выполняющейся транзакцией, также сохранены в памяти системы. Когда транзакция изменяет индексированные поля, это формирует индексный раздел акселератора в памяти системы, представляя изменения. При завершении транзакции все индексные измене ния для транзакции записаны в сортируемом порядке в последовательный вход и позже объединены с постоянным индексом.

Page Cache страницы базы данных читаются с диска для специфической базы данных. Размер кэша страницы управляется параметром falcon_page_cache_size, значение по умолчанию которого 4 MB установлено в файле my.cnf. Хотя изменения записи и индекса идут в последовательный файл регистрации прежде, чем запишутся в страницы базы данных, данные blob записаны непосредственно в кэш страницы. Это не дает регистрировать большие элементы данных, которые редко вызваны или изменены транзакцией, которая создает их.

Record Cache кэш записи представляет собой область памяти в зоне ожидания строк, которые были запрошены запросами конечного пользователя для специфической базы данных или созданы активными транзакциями. Обратите внимание, что этот кэш отличается от традиционных кэшей данных тем, что только специфические строки, необходимые прикладным программам, постоянно находятся в кэше в противоположность всем данным страницы (которая может содержать только подмножества необходимой информации). Кэш записи может хранить несколько версий записей, которые изменились или удалены. Эта методика гарантирует, что активные данные, необходимые, чтобы удовлетворять запросы пользователя находятся в памяти, сокращают время доступа к строке и уменьшают кэш, не включая незапрошенную информацию. Кэш записи также помогает в обеспечении механизм многоверсионного управления параллелизма (MVCC). Кэш записи управляется двумя параметрами. Параметр falcon_min_record_memory (заданный по умолчанию в 10 MB) определяет минимальное количество RAM, обеспеченной кэшу записи, а falcon_max_record_memory (заданный по умолчанию в 20 MB) ограничивает общую сумму памяти, доступной кэшу.

Из-за поддержки кэша записи транзакциями, используется поток-мусоросборщик, чтобы гарантировать только горячие данные постоянно находятся в кэше. Когда ограничение falcon_max_record_memory достигнуто, Falcon рассматривает демографию данных в кэше и удаляет самые старые поколения. Этот процесс более усложнен, чем стандартный алгоритм LRU, используемый многими системами баз данных, но это более эффективно и быстро.

2.4.5.5. Потоки Falcon

Falcon использует два рабочих потока, чтобы обработать информацию внутри структур Falcon. Один поток посвящен перемещению совершенных изменений данных из файла регистрации на страницы и объединению индексных изменений с постоянными индексными данными. Второй обрабатывает периодический сброс кэша страницы и убирает мусор, распределенный внутри кэша записи.

2.4.5.6. Сжатие данных

Данные, сохраненные в пространстве таблиц Falcon сжаты на диске, но сохранены в несжатом формате в памяти. Сжатие происходит автоматически, когда данные переданы на диск.

2.4.5.7. Слот записи

Слот записи представляет собой внутренний идентификатор записи, который используется, чтобы найти записи в памяти и на диске. Это по существу указатель на страницы, которые содержат данные для специфической записи. Новый слот записи создан для каждой записи на время продолжительности существования этой записи. Слот записи освобожден только, когда запись удалена из базы данных.

2.4.6. Ограничения

Имеется ряд ограничений в alpha-версии Falcon. В дальнейшем они постепенно будут сниматься:

Не работает SELECT FOR UPDATE.

Для Alpha-версии максимальная длина ключа ограничена 1100 байтами.

Уровни изоляции Serializable не обеспечиваются.

Конфигурация времени ожидания для блокировки не обеспечивается.

Распределенные транзакции не обеспечиваются.

Имеется ограничение 232 (4.29 миллиарда) строк для одиночной таблицы. Используя много таблиц внутри того же самого пространства таблиц Вы можете иметь больше, чем это число записей. В будущем выпуске это ограничение будет удалено.

Размеры страницы с перестраиваемой конфигурацией не обеспечиваются, но запланированы на будущий выпуск.

Таблицы Falcon могут поддерживать до 32000 столбцов.

Каждое пространство таблиц имеет ограничение в 232 страниц внутри одиночного пространства. Через комбинацию размера страницы и максимального числа страниц имеется ограничение 140737488355328 байт (128 TB) одиночного пространства таблиц.

Интерактивное резервирование не обеспечивается, но поддержка запланирована в будущем выпуске.

Поддержка внешнего ключа в настоящее время недоступна.

Хотя максимальная доступная память внутри пространства таблиц 128 TB, истинное число записей и объем данных, которые Вы можете сохранять, зависит от ряда факторов:

Требования памяти записью.

Индексные требования памяти.

Коэффициент сжатия сохраненных данных.

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

2.5. Тип памяти EXAMPLE

Тип памяти EXAMPLE представляет собой заглушку, которая не делает ничего. Он только показывает, как надо разрабатывать типы памяти.

Тип памяти EXAMPLE включен в двоичные дистрибутивы MySQL-Max. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-example-storage-engine.

Чтобы исследовать исходник типа памяти EXAMPLE, смотрите каталог storage/example исходных текстов MySQL.

Когда Вы создаете таблицу типа EXAMPLE, сервер честно создает файл формата таблицы в каталоге баз данных. Имя файла начинается с имени таблицы и имеет расширение .frm. Никакие другие файлы не созданы. Никакие данные не могут быть сохранены в таблицу. Запросы возвращают пустой результат:

mysql> CREATE TABLE test (i INT) ENGINE = EXAMPLE;

Query OK, 0 rows affected (0.78 sec)

mysql> INSERT INTO test VALUES(1),(2),(3);

ERROR 1031 (HY000): Table storage engine for 'test' doesn't ┬╗

have this option

mysql> SELECT * FROM test;

Empty set (0.31 sec)

Тип EXAMPLE не поддерживает индексацию.

2.6. Тип памяти FEDERATED

Тип памяти FEDERATED обращается к данным в таблицах удаленных баз данных, а не в локальных таблицах.

Тип памяти FEDERATED включен в двоичные дистрибутивы MySQL-Max. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-federated-storage-engine.

Чтобы исследовать исходник типа памяти FEDERATED, смотрите каталог sql исходных текстов MySQL.

Дополнительные ресурсы:

Форум, специализированный на типе FEDERATED, доступен на .

2.6.1. Описание типа памяти FEDERATED

Когда Вы создаете таблицу типа FEDERATED, сервер создает файл формата таблицы в каталоге баз данных. Имя файла начинается с имени таблицы и имеет расширение .frm. Никакие другие файлы не созданы, потому что фактические данные находятся в удаленной таблице. Это отличается от способа, которым работают типы памяти для локальных таблиц.

Для локальных таблиц базы данных файлы данных локальны. Например, если Вы создаете MyISAM-таблицу с именем users, драйвер MyISAM создает файл данных, именованный users.MYD. Драйвер для локальных таблиц читает, вставляет, удаляет и модифицирует данные в локальных файлах данных, и строки сохранены в частном формате драйвера. Чтобы читать строки, драйвер должен анализировать данные в столбцах. Чтобы записывать строки, значения столбцов должны быть преобразованы в формат строки, используемый драйвером и записаны в локальный файл данных.

А вот в типе памяти FEDERATED не имеется никаких локальных файлов данных для таблицы (например, нет файла .MYD). Вместо этого удаленная база данных сохраняет данные, которые обычно были бы в таблице. Локальный сервер соединяется с удаленным и использует клиентское API MySQL, чтобы читать, удалять, модифицировать и вставлять данные в удаленной таблице. Поиск данных инициализирован через инструкции SQL SELECT * FROM tbl_name. Чтобы читать результат, строки выбраны по одной, используя функцию C API mysql_fetch_row(), а затем преобразуя столбцы в наборе результатов SELECT к формату, который ожидает получить драйвер FEDERATED.

Поток информации таков:

SQL-обращения выданы локально.

Используется MySQL handler API (данные в формате драйвера).

Клиентский API MySQL (данные преобразованы в обращения SQL).

Удаленная база данных -> клиентский API MySQL.

Конвертация набора результатов (если надо) к формату драйвера.

2.6.2. Как использовать таблицы FEDERATED

Процедура для использования таблиц FEDERATED очень проста. Обычно Вы имеете два выполняемых сервера. В принципе возможно использовать другую таблицу, которая управляется тем же самым сервером, хотя имеются некоторые хитрости при этом.

Сначала Вы должны иметь таблицу на удаленном сервере, к которой Вы хотите обращаться, используя таблицу FEDERATED. Предположите, что удаленная таблица находится в базе данных federated и определена подобно этому:

CREATE TABLE test_table (id INT(20) NOT NULL AUTO_INCREMENT,

name VARCHAR(32) NOT NULL DEFAULT '',

other INT(20) NOT NULL DEFAULT '0', PRIMARY KEY(id),

INDEX name (name), INDEX other_key (other))

ENGINE=MyISAM DEFAULT CHARSET=latin1;

Пример использует таблицу MyISAM, но таблица могла бы использовать любой тип памяти.

Затем создайте таблицу FEDERATED на локальном сервере для доступа к удаленной таблице:

CREATE TABLE federated_table (id INT(20) NOT NULL AUTO_INCREMENT,

name VARCHAR(32) NOT NULL DEFAULT '',

otherINT(20) NOT NULL DEFAULT '0',

PRIMARY KEY(id), INDEX name (name),

INDEX other_key (other)) ENGINE=FEDERATED

DEFAULT CHARSET=latin1

CONNECTION='mysql://root@remote_host:9306/federated/test_table';

Обратите внимание: CONNECTION заменяет COMMENT, используемый в некоторых предыдущих версиях MySQL.

Структура этой таблицы должна быть точно такая же, как у удаленной таблицы, за исключением того, что опция ENGINE таблицы должна быть FEDERATED, а опция таблицы CONNECTION задает строку подключения, которая указывает для драйвера FEDERATED, как соединиться с удаленным сервером.

Тип памяти FEDERATED создает только файл test_table.frm в базе данных federated.

Удаленная информация хоста указывает удаленный сервер, с которым Ваш локальный соединяется, а база данных и информация таблицы указывают, которую удаленную таблицу использовать как источник данных. В этом примере удаленный сервер обозначен как remote_host (порт 9306), так что на удаленной системе должен быть сервер MySQL, слушающий порт 9306.

Общая форма строки подключения в опции CONNECTION такова:

scheme://user_name[:password]@host_name

[:port_num]/db_name/tbl_name

Только mysql обеспечивается как значение scheme в этот момент, пароль и номер порта факультативны.

Имеются некоторые примеры строк подключения:

CONNECTION='mysql://username:password@hostname:port/database/tablename'

CONNECTION='mysql://username@hostname/database/tablename'

CONNECTION='mysql://username:password@hostname/database/tablename'

Использование CONNECTION для определения строки подключения не оптимально и, вероятно, измениться в будущем.

Потому что любой пароль, заданный в строке подключения, сохранен как простой текст, он может быть замечен любым пользователем, который может применить SHOW CREATE TABLE или SHOW TABLE STATUS для таблицы FEDERATED или сделать запрос таблицы TABLES в базе данных INFORMATION_SCHEMA.

2.6.3. Ограничения типа памяти FEDERATED

Далее перечислены свойства, которые FEDERATED не поддерживает:

В первой версии удаленный сервер должен быть MySQL-сервером. Поддержка FEDERATED для других СУБД может быть добавлена в будущем.

Удаленная таблица, на которую указывает таблица FEDERATED, ДОЛЖНА существовать прежде, чем Вы попробуете обращаться к ней через драйвер FEDERATED.

Возможно для одной таблицы FEDERATED указывать на другую, но Вы должны быть внимательны, чтобы не создать цикл.

Не имеется никакой поддержки транзакций.

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

FEDERATED понимает SELECT, INSERT, UPDATE, DELETE и индексы. Это не поддерживает ALTER TABLE или любые инструкции Data Definition Language, кроме DROP TABLE. Текущая реализация не использует подготовленные инструкции.

Любая инструкция DROP TABLE, выданная для таблицы FEDERATED, удалит только локальную таблицу, но не удаленную.

Реализованы SELECT, INSERT, UPDATE и DELETE, но не HANDLER.

Таблицы FEDERATED не работают с кэшем запроса.

Некоторые из этих ограничений могут сниматься в будущих версиях драйвера FEDERATED.

2.7. Тип памяти ARCHIVE

Тип памяти ARCHIVE используется для сохранения больших количеств данных без индексов в очень маленьком файле.

Тип памяти ARCHIVE включен в двоичные дистрибутивы MySQL. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-archive-storage-engine.

Чтобы исследовать исходник типа памяти ARCHIVE, смотрите каталог storage/archive исходных текстов MySQL.

Вы можете проверять, является ли доступным тип памяти ARCHIVE этой инструкцией:

mysql> SHOW VARIABLES LIKE 'have_archive';

Когда Вы создаете таблицу типа ARCHIVE, сервер создает файл формата таблицы в каталоге баз данных. Имя файла начинается с имени таблицы и имеет расширение .frm. Драйвер памяти создает и другие файлы, имена коих начинаются с имени таблицы. Данные и файлы метаданных имеют расширения .ARZ и .ARM, соответственно. Файл .ARN может появляться при операциях оптимизации.

Драйвер типа памяти ARCHIVE понимает INSERT и SELECT, но не DELETE, REPLACE или UPDATE. Это поддерживает операции ORDER BY столбцы BLOB и в основном все, кроме пространственных, типы данных. Блокировка уровня строки использована в ARCHIVE.

Начиная с MySQL 5.1.6, тип ARCHIVE поддерживает атрибут столбца AUTO_INCREMENT. Такие столбцы могут иметь уникальный или не-уникальный индекс. Попытка создавать индекс на любом другом столбце приводит к ошибке. Тип памяти ARCHIVE также поддерживает опцию таблицы AUTO_INCREMENT в CREATE TABLE и ALTER TABLE, чтобы определить начальное значение последовательности для новой таблицы или сбросить значение последовательности для существующей таблицы, соответственно.

Начиная с MySQL 5.1.6, тип ARCHIVE игнорирует столбцы BLOB, если они не запрошены, и просматривает их прошлое при чтении. Прежде, следующий две инструкции имели ту же самую логику, но с 5.1.6 вторая намного более эффективна, чем первая:

SELECT a, b, blob_col FROM archive_table;

SELECT a, b FROM archive_table;

Хранение: строки сжаты, когда они вставлены. Тип памяти ARCHIVE использует сжатие данных zlib без потерь (подробности на сайте ). Вы можете использовать OPTIMIZE TABLE, чтобы анализировать таблицу и упаковывать ее в меньший формат (причины применения именно OPTIMIZE TABLE, изложены ниже). Тип памяти также поддерживает CHECK TABLE. Имеются несколько типов вставок, которые используются:

Инструкция INSERT только помещает строки в буфер сжатий, а буферные пишется по мере необходимости. Вставка в буфер защищена блокировкой. SELECT сбрасывает все данные на диск, если вставки не были INSERT DELAYED (такие сбрасываются по мере необходимости).

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

Поиск: при поиске строки несжаты по требованию, не имеется никакого кэша строк. Операция SELECT выполняет полный просмотр таблицы. Когда происходит SELECT, это выясняет, сколько строк в настоящее время доступны, и читает это число строк. SELECT выполняется как непротиворечивое чтение. Обратите внимание, что большое количество инструкций SELECT в течение вставки может ухудшать сжатие, если только отсроченные вставки не используется. Чтобы достигать лучшего сжатия, Вы можете использовать OPTIMIZE TABLE или REPAIR TABLE. Число строк в таблицах ARCHIVE, сообщенное SHOW TABLE STATUS, всегда точно.

Дополнительные ресурсы:

Форум, специализированный на типе ARCHIVE, доступен на .

2.8. Тип памяти CSV

Тип памяти CSV хранит данные в текстовых файлах, использующих разделяемый запятыми формат значений.

Чтобы включить этот тип памяти, используйте опцию --with-csv-storage-engine в скрипте configure при сборке MySQL.

Тип памяти CSV включен в двоичные дистрибутивы MySQL-Max. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-csv-storage-engine. Чтобы исследовать исходник типа памяти CSV, смотрите каталог storage/csv исходных текстов MySQL.

Когда Вы создаете таблицу CSV, сервер создает файл формата таблицы в каталоге баз данных. Имя файла начинается с имени таблицы и имеет расширение .frm. Тип памяти также создает файл данных. Имя его начинается с имени таблицы и имеет расширение .CSV. Файл данных представляет собой простой текстовый файл. Когда Вы сохраняете данные в таблицу, тип памяти сохраняет это в файл данных в разделяемом запятыми формате значений.

mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = CSV;

Query OK, 0 rows affected (0.12 sec)

mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');

Query OK, 2 rows affected (0.00 sec)

Records: 2 Duplicates: 0 Warnings: 0

mysql> SELECT * FROM test;

+---+------------+

| i | c |

+---+------------+

| 1 | record one |

| 2 | record two |

+---+------------+

2 rows in set (0.00 sec)

Начиная с MySQL 5.1.9, при создании таблицы CSV также создается соответствующий метафайл, который сохраняет состояние таблицы и число строк, которые существуют в таблице. Имя этого файла такое же, как имя таблицы, но с расширением CSM.

Если Вы исследуете файл test.CSV в каталоге баз данных созданный, выполняя предшествующие инструкции, его содержимое должно выглядеть следующим образом:"1","record one"

"2","record two"

Этот формат может читаться и даже записываться прикладными программами электронных таблицы типа Microsoft Excel или StarOffice Calc.

2.8.1. Восстановление и проверка таблицы CSV

Функциональные возможности, представленные в версии 5.1.9.

Тип памяти CSV поддерживает команды CHECK и REPAIR, чтобы проверить и, если возможно, отремонтировать поврежденную таблицу CSV.

При выполнении команды CHECK файл CSV будет проверен на правильность, ища правильные разделители полей, экранированные поля (соответствующие кавычками и/или их отсутствию), правильное число полей, сравниваемых с определением таблицы и существование соответствующего метафайла CSV. Первая недопустимая обнаруженная строка сообщит ошибку. Проверка допустимой таблицы производит вывод, аналогично показанному ниже:

mysql> check table csvtest;

+--------------+-------+----------+----------+

+--------------+-------+----------+----------+

+--------------+-------+----------+----------+

1 row in set (0.00 sec)

Проверка на разрушенной таблице возвращает неисправность:

mysql> check table csvtest;

+--------------+-------+----------+----------+

+--------------+-------+----------+----------+

+--------------+-------+----------+----------+

1 row in set (0.01 sec)

Если сбой проверки произошел, таблица отмечена как разрушенная. Если только таблица была отмечена как разрушенная, она будет автоматически восстановлена, когда Вы затем выполняете инструкцию CHECK или SELECT. Соответствующее разрушенное состояние и новое состояние будут отображаться при выполнении CHECK:

mysql> check table csvtest;

+--------------+-------+----------+----------------------------+

+--------------+-------+----------+----------------------------+

+--------------+-------+----------+----------------------------+

2 rows in set (0.08 sec)

Для ремонта таблицы Вы можете использовать REPAIR, это скопирует так много допустимых строк из существующих CSV данных, сколько возможно, а затем заменяет существующий CSV файл на восстановленные строки. Любые строки вне разрушенных данных будут потеряны.

mysql> repair table csvtest;

+--------------+--------+----------+----------+

+--------------+--------+----------+----------+

+--------------+--------+----------+----------+

1 row in set (0.02 sec)

Предупреждение

Обратите внимание, что в течение ремонта только строки из CSV файла до первой поврежденной строки скопированы к новой таблице. Все другие строки, даже допустимые строки, до первой поврежденной строки удалены!

2.8.2. Ограничения CSV

Важно: тип памяти CSV не поддерживает индексацию.

Выделение разделов не обеспечивается для таблиц, использующих CSV. Начиная с MySQL 5.1.12, больше не возможно создать разбитую на разделы таблицу CSV ().

2.9. Тип памяти BLACKHOLE

Тип памяти BLACKHOLE действует как черная дыра. Это принимает данные, но не сохраняет их. Поиски всегда возвращают пустой результат:

mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;

Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO test VALUES(1,'record one'), (2,'record two');

Query OK, 2 rows affected (0.00 sec)

Records: 2 Duplicates: 0 Warnings: 0

mysql> SELECT * FROM test;

Empty set (0.00 sec)

Тип памяти BLACKHOLE включен в двоичные дистрибутивы MySQL-Max. Чтобы его включить, если Вы формируете MySQL из исходного текста, вызовите configure с опцией --with-blackhole-storage-engine. Чтобы исследовать исходник типа памяти BLACKHOLE, смотрите каталог sql исходных текстов MySQL.

Когда Вы создаете таблицу BLACKHOLE, сервер создает файл формата таблицы в каталоге баз данных. Имя файла начинается с имени таблицы и имеет расширение .frm. Не имеется никаких других файлов, связанных с таблицей.

Тип памяти BLACKHOLE поддерживает все виды индексов. То есть, Вы можете включать индексные объявления в определении таблицы. Вы можете проверять наличие поддержки типа памяти BLACKHOLE этой инструкцией:

mysql> SHOW VARIABLES LIKE 'have_blackhole_engine';

Вставки в таблицу не сохраняют BLACKHOLE никакие данные, но если двоичный файл регистрации допускается, инструкции SQL прилежно в нем регистрируются (и скопируются на подчиненные серверы). Это может быть полезно как повторитель или фильтрующий механизм. Например, предположите, что Ваша прикладная программа требует подчиненно-побочных правил фильтрации, но передача всех двоичных данных файла регистрации подчиненным порождает чрезмерно большой трафик. В таком случае возможно поставить на главном сервере макет подчиненного процесса, чей заданный по умолчанию тип памяти BLACKHOLE, описанный следующим образом:

Главный пишет в свой двоичный файл регистрации. Макет mysqld обрабатывает действия как подчиненный, применяя желательную комбинацию правил replicate-do-* и replicate-ignore-* после чего пишет новый, собственный, отфильтрованный двоичный файл регистрации. Этот фильтрованный файл регистрации передается подчиненному.

Фиктивный процесс фактически не сохраняет никакие данные, так что имеется немного непроизводительных затрат обработки, которые возникают, выполняя дополнительный процесс mysqld на главном сервере репликации. Этот тип установки может быть повторен с дополнительными подчиненными серверами репликации.

Другие возможные использования типа памяти BLACKHOLE:

Проверка синтаксиса файла дампа.

Измерение непроизводительных затрат из двоичной регистрации, сравнивая эффективность, используя BLACKHOLE с и без двоичной регистрации.

BLACKHOLE по существу тип памяти пустой команды, так что это могло бы использоваться для нахождения критических параметров эффективности, не связанных с типом памяти непосредственно.

Начиная с MySQL 5.1.4, тип памяти BLACKHOLE знает транзакции в том смысле, что совершенные транзакции записаны в двоичный файл регистрации, а отмененные транзакции уже нет.

2.10 MySQL 5 FAQ по таблицам и типам памяти

Questions and Answers

2.10.1: Имеются ли любые новые типы памяти в MySQL 5.1?

MySQL 5.1 представляет alpha-версию нового типа памяти Falcon.

Также имелись значительные усовершенствования существующих типов памяти, в частности для NDB, который формирует основание MySQL Cluster.

2.10.2: А какие-то типы памяти были удалены в MySQL 5.1?

Да. MySQL 5.1 больше не поддерживает BDB. Любые существующие таблицы BDB должны быть преобразованы в другой тип перед обновлением до MySQL 5.1.

2.10.3: Каковы уникальные выгоды типа памяти ARCHIVE?

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

2.10.4: Какие новые свойства в MySQL 5.1 относятся ко всем типам памяти?

Общие новые свойства типа views, сохраненных процедур, триггеров, INFORMATION_SCHEMA, точной математики (тип столбца DECIMAL), а также тип столбца BIT относятся ко всем типам памяти. Имеются также добавления и изменения для специфических типов.

2.10.5: Какие изменения в поддерживаемые типы таблиц внесены в MySQL 5.1?

Поддержка изменилась следующим образом:

Поддержка для таблиц ISAM была удалена в MySQL 5.0, и Вы должны теперь использовать таблицы MyISAM вместо ISAM. Чтобы преобразовать таблицу tblname из типа ISAM в MyISAM, просто выдайте инструкцию типа этой:

ALTER TABLE tblname ENGINE=MYISAM;

Внутренний RAID для таблиц MyISAM был также удален в MySQL 5.0. Это прежде использовалось, чтобы позволить большие таблицы в файловых системах, которые не поддерживали размеры файла больше, чем 2 GB. Все современные файловые системы учитывают большие таблицы, кроме того, теперь имеются другие решения типа таблиц MERGE и views.

Тип столбца VARCHAR теперь сохраняет конечные пробелы во всех типах памяти.

Таблицы MEMORY (прежде известные как таблицы HEAP) также могут содержать столбцы VARCHAR.

Глава 3. Выделение разделов (Partitioning)

Из-за проблем с формированием двоичный дистрибутив MySQL 5.1.12 не содержат NDB Cluster или Partitioning. Пожалуйста, обновитесь до 5.1.14. Если Вы формируете пакет из исходника, Вы можете выполнять выбор конфигурации configure с параметрами --with-ndbcluster и --with-partition.

Эта глава обсуждает определяемое пользователем выделение разделов, как выполнено в MySQL 5.1.

MySQL поддерживает несколько типов выделения разделов, а также подвыделение разделов.

Методы добавления, удаления и изменения разделов в существующих разбитых на разделы таблицах рассмотрены в "".

Важно: разбитые на разделы таблицы, созданные в MySQL до версии 5.1.6, не могут читаться версией 5.1.6 или позже. Кроме того, таблица INFORMATION_SCHEMA.TABLES не может использоваться, если такие таблицы присутствуют на сервере 5.1.6. Начиная с MySQL 5.1.7, подходящее предупреждающее сообщение сгенерировано о том, что несовместимые разбитые на разделы таблицы были найдены сервером.

Важно: если Вы используете разбитые на разделы таблицы, которые были созданы в MySQL 5.1.5 или ранее, убедитесь, что изучили список изменений.

Реализация выделения разделов в MySQL 5.1 все еще подвергается изменениям. Дополнительные ресурсы по теме:

Это официальный форум обсуждения для тех, кого заинтересовала технология MySQL выделение разделов. Это показывает объявления и модификации от MySQL разработчиков и других. Это контролируется членами Partitioning Development and Documentation Teams.

MySQL Partitioning Architect and Lead Developer Mikael Ronstr├╢m часто регистрирует статьи относительно работы с выделением разделов MySQL и с кластером MySQL.

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

Двоичная версия MySQL 5.1 теперь доступна с . Однако, для последнего исправления механизма выделения разделов и добавления свойств, Вы можете получать исходник из архива BitKeeper. Чтобы допускать выделению разделов, Вы должны компилировать сервер, используя опцию --with-partition. Если Вы имеете проблемы при компилировании MySQL 5.1 с допускаемым выделением разделов, почитайте форум и поищите ответ там.

3.1. Краткий обзор выделения разделов в MySQL

Этот раздел обеспечивает концептуальный краткий обзор выделения разделов в MySQL 5.1.

Стандарт SQL не обеспечивает многого относительно физических аспектов хранения данных. Язык SQL непосредственно предназначен, чтобы работать независимо от любых структур данных или средств, лежащих в основе схем, таблиц, строк или столбцов, с которыми работает. Тем не менее, наиболее продвинутые системы управления базами данных развили некоторые средства определения физического расположения, которое нужно использовать для сохранения специфических частей данных в терминах аппаратных средств или даже файловых систем. В MySQL InnoDB обеспечил понятие пространства таблиц, так что сервер MySQL даже до введения выделения разделов, мог быть сконфигурирован, чтобы использовать различные физические каталоги для сохранения различных баз данных.

Partitioning берет это понятие и продвигает на шаг далее, позволяя Вам распределить части индивидуальных таблиц по файловым системам согласно правилам, которые Вы можете устанавливать в значительной степени так, как необходимо. В действительности, различные части таблицы сохранены как отдельные таблицы в различных местах. Выбранное пользователем правило, которым выполнен раздел данных, известно как функция выделения разделов, которая в MySQL может быть модулем, простым соответствием набору диапазонов или списков, внутренней или линейной хэш-функцией. Функция выбрана согласно типу выделения разделов, определенному пользователем, и берет как параметр значение обеспеченного пользователем выражения. Это выражение может быть целочисленным значением столбца или функция, действующая на один или большее количество значений столбца, и возвращающая целое число. Значение этого выражения передано функции выделения разделов, которая возвращает целочисленное значение, представляющее номер раздела, в котором эта специфическая запись должна быть сохранена. Эта функция должна быть непостоянная и непроизвольная. Это не может содержать любые запросы, но может использовать фактически любое выражение SQL, которое является допустимым в MySQL, поскольку то выражение возвращает положительное целое число меньше, чем MAXVALUE (самое большое возможное положительное целое число). Примеры выделения разделов функций могут быть найдены в обсуждениях выделения разделов позже в этой главе.

Это известно как горизонтальное выделение разделов (horizontal partitioning), то есть различные строки таблицы могут быть назначены к различным физическим разделам. MySQL 5.1 не поддерживает вертикальное выделение разделов (vertical partitioning), в котором различные столбцы таблицы назначены различным физическим разделам. Не имеется никаких планов представить вертикальное выделение разделов в MySQL 5.1.

Выделение разделов включено в -max выпуски MySQL 5.1 (то есть двоичные версии 5.1 -max сформированы с --with-partition). Если MySQL сформирован с выделением разделов, ничто далее не должно быть выполнено, чтобы допустить это (например, никакие специальные записи не требуются в Вашем файле my.cnf). Вы можете определять, поддерживает ли сервер выделение разделов посредством команды SHOW VARIABLES типа этого:

mysql> SHOW VARIABLES LIKE '%partition%';

Variable_name Value have_partitioning YES

1 row in set (0.00 sec)

Если Вы не видите, что переменная have_partitioning со значением YES перечислена как показано выше в выводе соответствующей SHOW VARIABLES, то Ваша версия MySQL не поддерживает выделение разделов.

До MySQL 5.1.6 эта переменная была именована have_partition_engine ().

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

Обратите внимание:: выделение разделов MySQL не может использоваться с типами памяти MERGE или CSV. До MySQL 5.1.6 также было невозможно создать разбитую на разделы таблицу, использующую BLACKHOLE (). Выделение разделов KEY обеспечивается для использования с NDBCluster, но другие типы определяемого пользователем выделения разделов не обеспечиваются для таблиц Cluster в MySQL 5.1.

Чтобы использовать специфический тип памяти для разбитой на разделы таблицы, необходимо только использовать опцию [STORAGE] ENGINE точно как для не разбитой на разделы таблицы. Однако, Вы должны иметь в виду, что [STORAGE] ENGINE (и другие параметры таблицы) должен быть перечислен прежде, чем любые параметры выделения разделов используются в инструкции CREATE TABLE. Этот пример показывает, как создать таблицу, которая разбита на 6 разделов по hash и использует тип памяти InnoDB:

CREATE TABLE ti (id INT, amount DECIMAL(7,2), tr_date DATE)

ENGINE=INNODB PARTITION BY

HASH(MONTH(tr_date)) PARTITIONS 6;

Обратите внимание, что каждое предложение PARTITION может включать опцию [STORAGE] ENGINE, но в MySQL 5.1 это не имеет никакого эффекта.

Обратите внимание: выделение разделов применяется ко всем данным и индексам таблицы. Вы не можете выделять разделы только данных и не индексы или наоборот, при этом Вы не можете выделять разделы только части таблицы.

Данные и индексы для каждого раздела могут быть назначены к специфическому каталогу, используя опции DATA DIRECTORY и INDEX DIRECTORY для предложения PARTITION инструкции CREATE TABLE, используемой чтобы создать разбитую на разделы таблицу. Кроме того, MAX_ROWS и MIN_ROWS могут использоваться, чтобы определить максимальные и минимальные числа строк, соответственно, которые могут быть сохранены в каждом разделе таблицы.

Некоторые из преимуществ выделения разделов:

1. Можно сохранять большее количество данных в одной таблице, чем может быть записано на одиночном диске или файловой системе.

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

3. Некоторые запросы могут быть значительно оптимизированы в том, что данные, удовлетворяющие предложению WHERE могут быть сохранены только на одном или большем количестве разделов, таким образом исключая любые остающиеся разделы из поиска. Поскольку разделы могут быть изменены после того, как разбитая на разделы таблица была создана, Вы можете реорганизовать данные, чтобы расширить частые запросы, которые, возможно, были медленными, когда схема выделения разделов была сначала установлена. Эта возможность, иногда упоминаемая как сокращение раздела (partition pruning), была выполнена в MySQL 5.1.6.

4. Другие выгоды, обычно связываемые с выделением разделов, включены в следующий список. Эти свойства в настоящее время не выполнены в MySQL Partitioning, но высоки в списке приоритетов.

5. Запросы, включающие составные функции типа SUM() и COUNT(), легко могут быть распараллелены. Простым примером такого запроса мог бы быть SELECT salesperson_id, COUNT(orders) as order_total FROM sales GROUP BY salesperson_id;. Запрос может быть выполнен одновременно на каждом разделе, и результат получен просто суммируя результаты, полученные для всех разделов.

6. Достижение большей производительности запроса благодаря разбросу данных по разным дискам.

3.2. Типы раздела

Этот раздел обсуждает типы выделения разделов, которые доступны в MySQL 5.1. Они включают:

– RANGE partitioning : назначает строки разделам, основанным на значениях столбца, попадающих внутрь заданного диапазона.

– LIST partitioning: подобно выделению разделов диапазоном, за исключением того, что раздел выбран основанным на столбцах, соответствующих одному из набора дискретных значений.

– HASH partitioning: раздел выбран основанным на значении, возвращенном определяемым пользователем выражением, которое функционирует на значениях столбца в строках, которые будут вставлены в таблицу. Функция может состоять из любого выражения, допустимого в MySQL, которое выдает не отрицательное целочисленное значение.

– KEY partitioning: подобно выделению разделов hash, за исключением того, что обеспечены только один или большее количество столбцов, которые будут оценены, и сервер MySQL обеспечивает собственную хэш-функцию. Эти столбцы могут содержать не целочисленные значения, так как хэш-функция, обеспеченная MySQL, гарантирует целочисленный результат, независимо от типа данных столбца.

Очень общее использование выделения разделов базы данных должно выделять данные по времени. Некоторые системы баз данных поддерживают явное выделение разделов даты, которое MySQL не выполняет в 5.1. Однако, нетрудно создать в MySQL схемы выделения разделов, основанные на столбцах DATE, TIME, DATETIME или на выражениях, использующих такие столбцы.

При выделении разделов KEY или LINEAR KEY, Вы можете использовать столбец DATE, TIME или DATETIME как столбец выделения разделов без того, чтобы выполнить любую модификацию значения столбца. Например, эта инструкция создания таблицы совершенно допустима в MySQL:

CREATE TABLE members (firstname VARCHAR(25) NOT NULL,

lastname VARCHAR(25) NOT NULL,

username VARCHAR(16) NOT NULL,

email VARCHAR(35), joined DATE NOT NULL)

PARTITION BY KEY(joined) PARTITIONS 6;

Другие типы выделения разделов MySQL, однако, требуют выражения выделения разделов, которое выдает целочисленное значение или NULL. Если Вы желаете использовать дата-основанное выделение разделов RANGE, LIST, HASH или LINEAR HASH, Вы можете просто использовать функцию, которая функционирует на столбце DATE, TIME или DATETIME и возвращает такое значение, как показано здесь:

CREATE TABLE members (firstname VARCHAR(25) NOT NULL,

lastname VARCHAR(25) NOT NULL,

username VARCHAR(16) NOT NULL,

email VARCHAR(35), joined DATE NOT NULL)

PARTITION BY RANGE(YEAR(joined)) (

PARTITION p0 VALUES LESS THAN (1960),

PARTITION p1 VALUES LESS THAN (1970),

PARTITION p2 VALUES LESS THAN (1980),

PARTITION p3 VALUES LESS THAN (1990),

PARTITION p4 VALUES LESS THAN MAXVALUE);

Выделение разделов в MySQL оптимизирован для использования с функциям. TO_DAYS() и YEAR(). Однако, Вы можете использовать другие функции даты и времени, которые возвращают целое число или NULL, типа WEEKDAY(), DAYOFYEAR() или MONTH().

Важно помнить, что независимо от типа выделения разделов, которое Вы используете, разделы всегда нумеруются автоматически и в той последовательности, в какой созданы, при старте с 0. Когда новая строка вставлена в разбитую на разделы таблицу, это числа раздела, которые используются в идентификации правильного раздела. Например, если Ваша таблица использует 4 раздела, эти разделы пронумерованы 0, 1, 2 и 3. Для типов разделов RANGE и LIST необходимо гарантировать, что имеется раздел, определенный для каждого номера раздела. Для выделения разделов HASH использованная функция пользователя должна возвратить целочисленное значение большее, чем 0. Для выделения разделов KEY об этой проблеме позаботится автоматическая хэш-функция, которую сервер MySQL использует внутренне.

Имена разделов вообще следуют правилам для других MySQL-идентификаторов, типа тех, что применяются для таблиц и баз данных. Однако, Вы должны обратить внимание, что имена раздела не чувствительны к регистру. Например, следующая инструкция CREATE TABLE терпит неудачу как показано:

mysql> CREATE TABLE t2 (val INT)

– > PARTITION BY LIST(val) (

– > PARTITION mypart VALUES IN (1,3,5),

– > PARTITION MyPart VALUES IN (2,4,6));

ERROR 1488 (HY000): Duplicate partition name mypart

Сбой происходит потому, что MySQL не видит никакого различия между именами разделов mypart и MyPart.

Когда Вы определяете число разделов для таблицы, это должно быть выражено как положительный ненулевой целочисленный литерал без начальных нулей, и не может быть выражением типа 0.8E+01 или 6-2, даже если это оценивается как целое число. Начиная с MySQL 5.1.12, десятичные дроби больше не усечены, но взамен отвергнуты полностью.

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

3.2.1. RANGE Partitioning

Таблица, которая разбита на разделы диапазоном, разбита на разделы таким способом, которым каждый раздел содержит строки, для которых значение выражения выделения разделов находится внутри данного диапазона. Диапазоны должны быть непрерывны, но не перекрываться и определены, используя оператор VALUES LESS THAN. Для следующих немногих примеров, предположите, что Вы создаете таблицу типа следующей, чтобы сохранить персональные записи для цепочки из 20 видеоклипов, пронумерованных от 1 до 20:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code INT NOT NULL, store_id INT NOT NULL);

Эта таблица может быть разбита на разделы диапазоном по-разному, в зависимости от Ваших потребностей. Один способ состоит в том, чтобы использовать столбец store_id. Например, Вы могли бы выделять разделы таблицы 4 способами, добавляя предложение PARTITION BY RANGE как показано здесь:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code INT NOT NULL, store_id INT NOT NULL)

PARTITION BY RANGE (store_id)

(PARTITION p0 VALUES LESS THAN (6),

PARTITION p1 VALUES LESS THAN (11),

PARTITION p2 VALUES LESS THAN (16),

PARTITION p3 VALUES LESS THAN (21));

В этой схеме выделения разделов все строки, соответствующие записям, занимающим номера от 1 до 5, сохранены в разделе p0, от 6 до 10 в p1 и т. д. Обратите внимание, что каждый раздел определен чтобы хранить номера от самого низкого до самого высокого. Это требование синтаксиса PARTITION BY RANGE: Вы можете думать об этом как об аналоге переключателя switch … case в C или Java в этом отношении.

Просто определить, что новая строка, содержащая данные (72, 'Michael', 'Widenius', '1998-06-25', NULL, 13), вставлена в раздел p2, но что случается, когда Ваша цепочка, добавляет 21-ю запись? Согласно этой схеме, не имеется никакого правила, которое покрывает строку, с store_id большим чем 20, так что результатом будет ошибка, потому что сервер не знает, где поместить это. Вы можете обойти сбой, используя предложение VALUES LESS THAN в инструкции CREATE TABLE, которая обеспечивает все значения большие, чем явно именованное самое высокое значение:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code INT NOT NULL, store_id INT NOT NULL)

PARTITION BY RANGE (store_id) (PARTITION p0 VALUES LESS THAN (6),

PARTITION p1 VALUES LESS THAN (11),

PARTITION p2 VALUES LESS THAN (16),

PARTITION p3 VALUES LESS THAN MAXVALUE);

MAXVALUE представляет самое большое возможное целочисленное значение. Теперь, любые строки, чье значение столбца store_id является большим или равным 16 (самое высокое определенное значение), сохранены в разделе p3. В некоторой точке в будущем, когда число записей увеличится до 25, 30 или больше, Вы можете использовать инструкцию ALTER TABLE, чтобы добавить новые разделы для диапазонов 21-25, 26-30 и т. д.

В аналогичном режиме Вы могли бы выделять разделы таблицы, основанные на кодах работы служащего, то есть на диапазонах значений столбца job_code. Например, приняв, что коды работы с двумя цифрами используются для регулярных (in-store) рабочих, коды с тремя цифрами используются для ведомства и персонала поддержки, а четырехразрядные коды для позиций управления, Вы могли бы создать разбитую на разделы таблицу, используя:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code INT NOT NULL, store_id INT NOT NULL)

PARTITION BY RANGE (job_code) (

PARTITION p0 VALUES LESS THAN (100),

PARTITION p1 VALUES LESS THAN (1000),

PARTITION p2 VALUES LESS THAN (10000));

В этом образце все строки в отношении рабочих in-store были бы сохранены в разделе p0, строки для ведомства и персонала поддержки в p1, а администраторы в разделе p2.

Также возможно использовать выражение в предложениях VALUES LESS THAN. Однако, MySQL должен быть способен оценить возвращаемое значение выражения как часть сравнения LESS THAN (<).

Вы можете использовать выражение, основанное на одном из двух столбцов DATE. Например, предположим, что Вы желаете выделить разделы основанные на годе, в котором каждый служащий оставил компанию, то есть значение YEAR(separated). Пример инструкции CREATE TABLE, которая осуществляет такую схему выделения разделов, показывается здесь:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code INT, store_id INT)

PARTITION BY RANGE (YEAR(separated)) (

PARTITION p0 VALUES LESS THAN (1991),

PARTITION p1 VALUES LESS THAN (1996),

PARTITION p2 VALUES LESS THAN (2001),

PARTITION p3 VALUES LESS THAN MAXVALUE);

В этой схеме для всех служащих, кто оставил работу до 1991, строки сохранены в разделе p0, для периода 1991-1995 в p1, для 1996-2000 в p2, а для любых рабочих, кто оставил фирму после 2000 года в p3.

Выделение разделов по диапазону особенно полезно когда:

Вы хотите удалить старые данные. Если Вы используете схему выделения разделов, показанную выше, Вы можете просто использовать ALTER TABLE employees DROP PARTITION p0; , чтобы удалять все строки в отношении служащих, оставивших работу до 1991. Для таблицы с очень многими строками, это может быть намного более эффективно, чем выполнение запроса DELETE, например,

DELETE FROM employees WHERE YEAR(separated) <=1990;.

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

Вы часто выполняете запросы, которые зависят непосредственно от столбца, используемого для выделения разделов таблицы. Например, при выполнении запроса типа

SELECT COUNT(*) FROM employees WHERE YEAR(separated) = 2000 GROUP BY store_id;,

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

3.2.2. LIST Partitioning

Как в выделении разделов RANGE, каждый раздел должен быть явно определен. Главное различие в том, что в выделении разделов списка, каждый раздел определен и выбран основываясь на членстве значения столбца в одном наборе значений списков, а не непрерывных диапазонов значений. Это выполнено, используя PARTITION BY LIST(expr) , где expr значение столбца или выражение, основанное на значении столбца и возврате целочисленного значения, а затем определение каждого раздела посредством VALUES IN (value_list), где value_list разделяемый запятыми список целых чисел.

Обратите внимание: В MySQL 5.1 возможно соответствовать только списку целых чисел (и возможно NULL) при выделении разделов LIST.

В отличие от случая с разделами, определенными диапазоном, разделы списка не должны быть объявлены в любом специфическом порядке.

Для примеров ниже будем считать, что базисное определение таблицы, которая будет разбита на разделы обеспечивается инструкцией CREATE TABLE, показанной здесь:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code INT, store_id INT);

Предположите, что имеются 20 видеоклипов, распределенных среди 4 привилегий, как показано в следующей таблице:

Область

Store ID Numbers

Север3, 5, 6, 9, 17Восток1, 2, 10, 11, 19, 20Запад4, 12, 13, 14, 18Центр7, 8, 15, 16

Чтобы выделять разделы таблицы таким способом, чтобы строки для клипов, принадлежащих к той же самой области, были сохранены в том же самом разделе, Вы могли бы использовать инструкцию CREATE TABLE, показанную здесь:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code INT, store_id INT)

PARTITION BY LIST(store_id) (

PARTITION pNorth VALUES IN (3,5,6,9,17),

PARTITION pEast VALUES IN (1,2,10,11,19,20),

PARTITION pWest VALUES IN (4,12,13,14,18),

PARTITION pCentral VALUES IN (7,8,15,16));

Это облегчает добавление или удаление записи в отношении специфических областей. Например, предположите, что все клипы в западной области проданы другой компании. Все строки в их отношении могут быть удалены запросом ALTER TABLE employees DROP PARTITION pWest;, который может быть выполнен намного более эффективно, чем эквивалентная инструкция DELETE FROM employees WHERE store_id IN (4,12,13,14,18);.

Как с RANGE и HASH partitioning, если Вы желаете выделить разделы таблицы столбцом, чье значение не целое число или NULL, Вы должны использовать выражение выделения разделов, основанное на том столбце, который возвращает такое значение. Например, предположите, что таблица, содержащая данные определена, как показано здесь:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code CHAR(1), store_id INT);

В этой версии таблицы employees код работы является символом, а не числом. Каждый символ соответствует специфической работе, и мы желаем выделить разделы таблицы таким способом, чтобы записи для служащих, имеющих подобные работы, или работающих в том же самом отделе, были сгруппированы в том же самом разделе, согласно следующей схеме:

Категория работы или отдел

Коды работы

ManagementD, M, O, PSalesB, L, STechnicalA, E, G, I, TClericalK, N, YSupportC, F, J, R, VUnassignedEmpty

Так как мы не можем использовать символьные значения в списках, мы должны преобразовать их в целых числа или NULL. Для этой цели мы можем использовать функцию ASCII() на значении столбца. Кроме того, из-за использования различных прикладных программ в разное время коды могут быть верхнего или нижнего регистра, значение empty означает "сейчас не назначен", представлением чего могут быть NULL, пустая строка или пробел. Разбитая на разделы таблица, которая осуществляет эту схему, показывается здесь:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code CHAR(1), store_id INT)

PARTITION BY LIST(ASCII(UCASE(job_code))) (

PARTITION management VALUES IN(68, 77, 79, 80),

PARTITION sales VALUES IN(66, 76, 83),

PARTITION technical VALUES IN(65, 69, 71, 73, 84),

PARTITION clerical VALUES IN(75, 78, 89),

PARTITION support VALUES IN(67, 70, 74, 82, 86),

PARTITION unassigned VALUES IN(NULL, 0, 32));

Так как выражения не разрешаются в списках значения раздела, Вы должны внести в список коды ASCII для символов, которые должны быть согласованы. Обратите внимание, что ASCII(NULL) вернет NULL.

Важно: если Вы пробуете вставлять строку так, что значение столбца (или возвращаемое значение выражения выделения разделов) не найдено в любом из списков значения выделения разделов, запрос INSERT будет терпеть неудачу с ошибкой. Например, этот запрос будет терпеть неудачу:

INSERT INTO employees VALUES

(224, 'Linus', 'Torvalds', '2002-05-01', '2004-10-12', 'Q', 21);

Сбой происходит, потому что 81 (код ASCII для прописной буквы 'Q') не найден в любом из списков значения используемых, чтобы определить любой из разделов. Не имеется никаких перехватчиков catch-all для list partitions, аналогичных VALUES LESS THAN(MAXVALUE), который приспосабливает значения, не найденные в любом из списков значения. Другими словами, любое значение, которое должно быть согласовано, должно быть найдено в одном из списков значений.

Как с выделением разделов RANGE, возможно объединить выделение разделов LIST, чтобы произвести составное выделение разделов (подвыделение разделов).

3.2.3. HASH Partitioning

Выделение разделов HASH используется прежде всего, чтобы гарантировать четкое распределение данных среди предопределенного числа разделов. С диапазоном или выделением разделов списка, Вы должны определить явно, в который раздел данное значение столбца или набор значений столбца должно быть сохранено, с выделением разделов hash MySQL заботится об этом для Вас, и Вы должны только определить значение столбца или выражение, основанное на значении столбца для хэширования и число разделов, на которые должна быть разделена разбитая на разделы таблица.

Чтобы выделять разделы таблицы, использующей выделение разделов HASH, необходимо конкатенировать к инструкции CREATE TABLE предложение PARTITION BY HASH (expr), где expr выражение, которое возвращает целое число. Это может быть просто имя столбца, чей тип является одним из целочисленных типов MySQL. Кроме того, Вы будете, наиболее вероятно, пользоваться предложением PARTITIONS num, где num неотрицательное целое число, представляющее число разделов, на которые таблица должна быть разделена.

Например, следующая инструкция создает таблицу, которая использует хэширование на столбце store_id и разделена на 4 раздела:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code INT, store_id INT)

PARTITION BY HASH(store_id) PARTITIONS 4;

Если Вы не включаете предложение PARTITIONS, числом разделов по умолчанию будет 1. Использование ключевого слова PARTITIONS без числа после него приводит к синтаксической ошибке.

Вы можете также использовать выражение SQL, которое возвращает целое число для expr. Например, Вы могли бы выделять разделы, основываясь на годе, в котором служащий был нанят. Это может быть выполнено как показано здесь:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code INT, store_id INT)

PARTITION BY HASH(YEAR(hired)) PARTITIONS 4;

Вы можете использовать любое функциональное или другое выражение для expr, которое является допустимым в MySQL, пока это возвращает непостоянное, непроизвольное целочисленное значение. Другими словами, это должно изменяться, но детерминировано. Однако, Вы должны иметь в виду, что это выражение оценено каждый раз, когда строка вставлена или модифицируется (или возможно удалена). Это означает, что очень сложные выражения могут вызывать проблемы эффективности, особенно при выполнении операций (типа пакетных вставок), которые воздействуют на очень многие строки в одно время.

Наиболее эффективная хэш-функция та, которая функционирует на одиночном столбце таблицы, и чье значение увеличивается или уменьшается последовательно со значением столбца, поскольку это учитывает сокращение (pruning) на диапазонах разделов. То есть, выражение изменяется со значением столбца, на котором основано.

Например, если столбец date_col типа DATE, то выражение TO_DAYS(date_col) изменяется непосредственно со значением date_col, потому что для каждого изменения в значении date_col значение выражения изменяется непротиворечивым способом. Дисперсия выражения YEAR(date_col) относительно date_col не так пряма, как TO_DAYS(date_col), потому что не каждое возможное изменение в date_col производит эквивалентное изменение в YEAR(date_col). Даже в этом случае YEAR(date_col) хороший кандидат на хэш-функцию, потому что это изменяется непосредственно с частью date_col, и не имеется никакого возможного изменения в date_col, которое производит непропорциональное изменение в YEAR(date_col).

Посредством контраста, предположите, что Вы имеете столбец int_col типа INT. Теперь рассмотрите выражение POW(5-int_col,3)+6. Это было бы плохим выбором для хэш-функции, потому что изменение в значении int_col не произведет пропорциональное изменение в значении выражения. Изменение значения int_col может производить очень разные изменения в значении выражения. Например, изменение int_col с 5 на 6 производит изменение в значении выражения -1, но при изменении значения int_col с 6 на 7 это будет уже -7.

Другими словами, граф значения столбца против значения выражения более близко следует за прямой строкой по уравнению y=nx, где n некоторая константа, отличная от нуля. Такое выражение лучше подходит для хэширования. Более нелинейный выражение произведет более неравное распределение данных среди разделов.

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

Когда используется PARTITION BY HASH, MySQL определяет который раздел num использовать, основываясь на модуле результата функции пользователя. Другими словами, для выражения expr раздел, в котором запись сохранена, представляет собой номер раздела N, где N=MOD(expr, num). Например, предположите, что таблица t1 определена следующим образом, чтобы имела 4 раздела:

CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)

PARTITION BY HASH(YEAR(col3)) PARTITIONS 4;

Если Вы вставляете в t1 запись с '2005-09-15' в col3, то раздел, в котором это будет сохранено, определен следующим образом:MOD(YEAR('2005-09-01'),4)=MOD(2005,4)=1

MySQL 5.1 также поддерживает вариант HASH partitioning известного как linear hashing (линейное хэширование) , которое использует более сложный алгоритм для определения размещения новых строк, вставленных в разбитую на разделы таблицу.

Функция пользователя оценена каждый раз, когда запись вставлена или модифицируется. Это может также быть в зависимости от обстоятельств, когда записи удалены.

Обратите внимание: если таблица, которая будет разбита на разделы, имеет ключ UNIQUE, то любые столбцы, обеспеченные как параметры к HASH функции пользователя или на KEY column_list, должны быть частью того ключа. Исключительная ситуация: это ограничение не относится к таблицам, использующим NDBCluster.

3.2.3.1. LINEAR HASH Partitioning

MySQL также поддерживает линейное хэширование, которое отличается от регулярного хэширования тем, что линейное хэширование использует линейный алгоритм степени двух в то время, как регулярное хэширование использует модуль значения хэш-функции.

Синтаксически единственное различие между выделением разделов линейного хэширования и регулярным хэшированием: добавление ключевого слова LINEAR в предложение PARTITION BY, как показано здесь:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(30),

lname VARCHAR(30),

hired DATE NOT NULL DEFAULT '1970-01-01',

separated DATE NOT NULL DEFAULT '9999-12-31',

job_code INT, store_id INT)

PARTITION BY LINEAR HASH(YEAR(hired)) PARTITIONS 4;

Данный выражением expr раздел, в котором запись сохранена, когда линейное хэширование используется, представляет собой номер раздела N из числа разделов num, где N получен согласно следующему алгоритму:

Находят следующую степень 2 большую, чем num. Назовем это значение V, это может быть вычислено как:V=POWER(2, CEILING(LOG(2, num)))

Например, предположите, что num=13.

Тогда LOG(2,13)=3.7004397181411.

CEILING(3.7004397181411) 4, а V = POWER(2,4) = 3.

Берется N = F(column_list) (V – 1).

Пока N >= num:

Берется V=CEIL(V/2)

Берется N = N (V – 1)

Например, предположите, что таблица t1 применяет линейное выделение разделов, имеет 6 разделов и создана, используя эту инструкцию:

CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)

PARTITION BY LINEAR HASH(YEAR(col3)) PARTITIONS 6;

Теперь примите, что Вы хотите вставлять две записи в t1: у одной значение столбца col3 равно '2003-04-14', а у другой составляет '1998-10-19'. Номер раздела для первой из них определен следующим образом:

V = POWER(2, CEILING( LOG(2,7) )) = 8

N = YEAR('2003-04-14') (8-1) = 2003 7 = 3

(3 >= 6 FALSE: запись сохранена в разделе #3

)

Номер раздела, где сохранена вторая запись, вычислен как показано здесь:

V = 8

N = YEAR('1998-10-19') (8-1) = 1998 7 = 6

(6 >= 6 TRUE: нужен дополнительный шаг

)

N = 6 CEILING(5 / 2) = 6 3 = 2

(2 >= 6 FALSE: запись сохранена в разделе #2

)

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

3.2.4. KEY Partitioning

Выделение разделов ключом подобно выделению разделов хэшем за исключением того, что выделение разделов хэшем использует определяемое пользователем выражение, а хэш-функция для выделения разделов ключом обеспечена MySQL. Здесь MySQL Cluster использует для этой цели MD5(), а для таблиц, использующих другие типы памяти, сервер применяет собственную внутреннюю хэш-функцию, которая основана на том же самом алгоритме, что и PASSWORD().

Правила синтаксиса для CREATE TABLE … PARTITION BY KEY подобен правилам для создания таблицы, которая разбита на разделы хэшем. Главные различия состоят в том что:

KEY используется вместо HASH.

KEY берет только список из одного или большего количества имен столбцов. Начиная с MySQL 5.1.5, если таблица имеет первичный ключ, столбцы, по которым происходит выделение разделов, должны включать хотя бы его часть (или весь ключ).

Начиная с MySQL 5.1.6, KEY берет список из нуля или большего количества имен столбца. Если никакое имя столбца не определено как ключ выделения разделов, используется первичный ключ таблицы, если он имеется. Например, следующая инструкция CREATE TABLE допустима в MySQL 5.1.6 или позже:

CREATE TABLE k1 (id INT NOT NULL PRIMARY KEY, name VARCHAR(20))

PARTITION BY KEY() PARTITIONS 2;

Если не имеется никакого первичногоключа, но имеется уникальный ключ, то именно уникальный ключ используется для выделения разделов:

CREATE TABLE k1 (id INT NOT NULL, name VARCHAR(20),

UNIQUE KEY (id))

PARTITION BY KEY() PARTITIONS 2;

Однако, если уникальный столбец ключа не был определен как NOT NULL, то предыдущая инструкция будет терпеть неудачу.

В обоих из этих случаев ключом выделения разделов является столбец id, даже при том, что это не показывается в выводе SHOW CREATE TABLE или в столбце PARTITION_EXPRESSION таблицы INFORMATION_SCHEMA.PARTITIONS.

В отличие от случая с другими типами выделения разделов, столбцы, используемые для выделения разделов KEY, не ограничены значениями NULL или целым числом. Например, следующая инструкция CREATE TABLE допустима:

CREATE TABLE tm1 (s1 CHAR(32) PRIMARY KEY)

PARTITION BY KEY(s1) PARTITIONS 10;

Предшествующая инструкция не была бы допустима для любого другого типа выделения разделов. Примечание: в этом случае, простое использование PARTITION BY KEY() было бы также допустимо и имело бы тот же самый эффект. что и PARTITION BY KEY(s1), поскольку s1 является первичным ключом таблицы.

Обратите внимание: также начиная с MySQL 5.1.6, таблицы, использующие NDB Cluster неявно разбиты на разделы KEY, используя первичный ключ таблицы как ключ выделения разделов. Когда таблица кластера не имеет никакого явного первичного ключа, применяется скрытый первичный ключ, сгенерированный NDB для каждой таблицы кластера.

Важно: для таблицы с разделением по ключу, использующей любой тип памяти MySQL, кроме NDB Cluster, Вы не можете выполнять ALTER TABLE DROP PRIMARY KEY, так как это сгенерирует ошибку ERROR 1466 (HY000): Field in list of fields for partition function not found in table. Это не проблема для таблиц MySQL Cluster, которые разбиты на разделы KEY: в таких случаях, таблица реорганизована, используя скрытый первичный ключ для выделения разделов этой таблицы.

Также возможно выделить разделы таблицы линейным ключом. Имеется простой пример:

CREATE TABLE tk (col1 INT NOT NULL, col2 CHAR(5), col3 DATE)

PARTITION BY LINEAR KEY (col1) PARTITIONS 3;

Использование LINEAR имеет тот же самый эффект на KEY, как на выделении разделов HASH с номером раздела, получаемым использованием алгоритма степени двух, а не арифметикой модуля.

3.2.5. Подвыделение разделов (Subpartitioning)

Subpartitioning также известно как составное выделение разделов (composite partitioning), что является дальнейшим делением каждого раздела в разбитой на разделы таблице. Например, рассмотрите следующую инструкцию CREATE TABLE:

CREATE TABLE ts (id INT, purchased DATE)

PARTITION BY RANGE(YEAR(purchased))

SUBPARTITION BY HASH(TO_DAYS(purchased))

SUBPARTITIONS 2 (PARTITION p0 VALUES LESS THAN (1990),

PARTITION p1 VALUES LESS THAN (2000),

PARTITION p2 VALUES LESS THAN MAXVALUE);

Таблица ts имеет 3 раздела RANGE. Каждый из этих разделов p0, p1 и p2 далее разделен на 2 подраздела. В действительности вся таблица разделена на 3*2=6 разделов. Однако, из-за действия предложения PARTITION BY RANGE первые 2 хранят только записи со значением меньше, чем 1990 в столбце purchased.

В MySQL 5.1 возможно подвыделить разделы таблиц, которые разбиты на разделы RANGE или LIST. Подразделы могут использовать выделение разделов HASH или KEY. Это также известно как составное выделение разделов.

Также возможно определить подразделы, явно использующие предложения SUBPARTITION, чтобы определить параметры для индивидуальных подразделов. Например, более подробный режим создания той же самой таблицы ts, как показано в предыдущем примере был бы:

CREATE TABLE ts (id INT, purchased DATE)

PARTITION BY RANGE( YEAR(purchased) )

SUBPARTITION BY HASH( TO_DAYS(purchased) ) (

PARTITION p0 VALUES LESS THAN (1990) (

SUBPARTITION s0, SUBPARTITION s1),

PARTITION p1 VALUES LESS THAN (2000) (

SUBPARTITION s2, SUBPARTITION s3),

PARTITION p2 VALUES LESS THAN MAXVALUE (

SUBPARTITION s4, SUBPARTITION s5));

Некоторые синтаксические элементы:

Каждый раздел должен иметь то же самое число подразделов.

Если Вы явно определяете любые подразделы, использующие SUBPARTITION на любом разделе разбитой на разделы таблицы, Вы должны определить их все. Другими словами, следующая инструкция будет терпеть неудачу:

CREATE TABLE ts (id INT, purchased DATE)

PARTITION BY RANGE(YEAR(purchased))

SUBPARTITION BY HASH(TO_DAYS(purchased)) (

PARTITION p0 VALUES LESS THAN (1990) (

SUBPARTITION s0, SUBPARTITION s1),

PARTITION p1 VALUES LESS THAN (2000),

PARTITION p2 VALUES LESS THAN MAXVALUE (

SUBPARTITION s2, SUBPARTITION s3));

Эта инструкция свалится даже если добавить предложение SUBPARTITIONS 2.

Каждое предложение SUBPARTITION должно включить (как минимум) имя для подраздела. Иначе Вы можете устанавливать любую желательную опцию для подраздела или позволить принимать настройку по умолчанию для этой опции.

В MySQL 5.1.7 и ранее имена подразделов должны быть уникальны внутри каждого раздела, но не должны быть уникальны внутри таблицы в целом. Начиная с MySQL 5.1.8, имена подразделов должны быть уникальны для всей таблицы. Например, следующая инструкция CREATE TABLE допустима в MySQL 5.1.8 и позже:

CREATE TABLE ts (id INT, purchased DATE)

PARTITION BY RANGE(YEAR(purchased))

SUBPARTITION BY HASH(TO_DAYS(purchased)) (

PARTITION p0 VALUES LESS THAN (1990) (

SUBPARTITION s0, SUBPARTITION s1),

PARTITION p1 VALUES LESS THAN (2000) (

SUBPARTITION s2, SUBPARTITION s3),

PARTITION p2 VALUES LESS THAN MAXVALUE (

SUBPARTITION s4, SUBPARTITION s5));

Предыдущая инструкция также допустима для версий MySQL до 5.1.8.

Подразделы могут использоваться с особенно большими таблицами, чтобы распределить данные и индексы на много дисков. Предположите, что Вы имеете 6 дисков, установленные как /disk0, /disk1, /disk2 и т. д. Теперь рассмотрите следующий пример:

CREATE TABLE ts (id INT, purchased DATE) PARTITION BY RANGE(YEAR(purchased))

SUBPARTITION BY HASH(TO_DAYS(purchased)) (

PARTITION p0 VALUES LESS THAN (1990) (

SUBPARTITION s0 DATA DIRECTORY = '/disk0/data'

INDEX DIRECTORY = '/disk0/idx',

SUBPARTITION s1 DATA DIRECTORY = '/disk1/data'

INDEX DIRECTORY = '/disk1/idx'),

PARTITION p1 VALUES LESS THAN (2000) (

SUBPARTITION s2 DATA DIRECTORY = '/disk2/data'

INDEX DIRECTORY = '/disk2/idx',

SUBPARTITION s3 DATA DIRECTORY = '/disk3/data'

INDEX DIRECTORY = '/disk3/idx'),

PARTITION p2 VALUES LESS THAN MAXVALUE (SUBPARTITION s4

DATA DIRECTORY = '/disk4/data'

INDEX DIRECTORY = '/disk4/idx',

SUBPARTITION s5 DATA DIRECTORY = '/disk5/data'

INDEX DIRECTORY = '/disk5/idx'));

В этом случае отдельный диск используется для данных и индексов каждого RANGE. Много других разновидностей возможны, другой пример мог бы быть таким:

CREATE TABLE ts (id INT, purchased DATE) PARTITION BY RANGE(YEAR(purchased))

SUBPARTITION BY HASH(TO_DAYS(purchased)) (

PARTITION p0 VALUES LESS THAN (1990) (

SUBPARTITION s0a DATA DIRECTORY = '/disk0' INDEX DIRECTORY='/disk1',

SUBPARTITION s0b DATA DIRECTORY = '/disk2' INDEX DIRECTORY='/disk3'),

PARTITION p1 VALUES LESS THAN (2000) (

SUBPARTITION s1a DATA DIRECTORY = '/disk4/data'

INDEX DIRECTORY = '/disk4/idx',

SUBPARTITION s1b DATA DIRECTORY = '/disk5/data'

INDEX DIRECTORY = '/disk5/idx'),

PARTITION p2 VALUES LESS THAN MAXVALUE (

SUBPARTITION s2a, SUBPARTITION s2b));

Здесь хранение следующее:

Строки с датами purchased до 1990 занимают обширное количество места, поэтому поделены 4 путями: с отдельным диском, специализированным для данных, и с дополнительным диском для индексов для каждого из двух подразделов (s0a и s0b), входящих в раздел p0. Другими словами:

Данные для подраздела s0a сохранены на /disk0.

Индексы для подраздела s0a сохранены на /disk1.

Данные для подраздела s0b сохранены на /disk2.

Индексы для подраздела s0b сохранены на /disk3.

Строки, содержащие даты в пределах от 1990 до 1999 (раздел p1) не требуют так много памяти, как даты до 1990. Они размазаны между 2 дисками (/disk4 и /disk5):

Данные и индексы, принадлежащие первому подразделу (s1a) раздела p1, сохранены на /disk4: данные в /disk4/data, а индексы в /disk4/idx.

Данные и индексы, принадлежащие второму подразделу (s1b) раздела p1, сохранены на /disk5: данные в /disk5/data, а индексы в /disk5/idx.

Строки, отражающие даты с года 2000 до текущей (раздел p2), не занимают так много места, как любой из двух предыдущих диапазонов. В настоящее время достаточно сохранить всех их в заданном по умолчанию расположении.

В будущем, когда число purchases в течение десятилетия, начинающегося годом 2000, вырастет до отметки, где заданное по умолчанию расположение больше не обеспечивает достаточного места, соответствующие строки могут перемещаться, используя ALTER TABLE … REORGANIZE PARTITION.

3.2.6. Как выделитель разделов в MySQL обрабатывает значения NULL

Выделение разделов в MySQL не делает ничего, чтобы отвергнуть NULL как значение выражения выделения разделов независимо от того, является ли это значением столбца или обеспеченного пользователем выражения. Даже разрешается использовать NULL как значение выражения, которое должно выдать целое число, но важно иметь в виду, что NULL числом не является. Начиная с версии 5.1.8, MySQL обрабатывает NULL как будто он меньше, чем любое не нулевое значение, точно как делает ORDER BY.

Из-за этого эта обработка NULL изменяется при выделении разделов различных типов, и может производить поведение, которое Вы не ожидаете. Если Вы вставляете строку в таблицу, разбитую на разделы RANGE так, что значение столбца, используемое, чтобы определить раздел, является NULL, строка вставлена в самый нижний раздел. Например, рассмотрите эти две таблицы, созданные и заполняемые следующим образом:

mysql> CREATE TABLE t1 (c1 INT, c2 VARCHAR(20))

– > PARTITION BY RANGE(c1) (

– > PARTITION p0 VALUES LESS THAN (0),

– > PARTITION p1 VALUES LESS THAN (10),

– > PARTITION p2 VALUES LESS THAN MAXVALUE);

Query OK, 0 rows affected (0.09 sec)

mysql> CREATE TABLE t1 (c1 INT, c2 VARCHAR(20))

– > PARTITION BY RANGE(c1) (

– > PARTITION p0 VALUES LESS THAN (-5),

– > PARTITION p1 VALUES LESS THAN (0),

– > PARTITION p1 VALUES LESS THAN (10),

– > PARTITION p2 VALUES LESS THAN MAXVALUE);

Query OK, 0 rows affected (0.09 sec)

mysql> INSERT INTO t1 VALUES (NULL, 'mothra');

Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO t2 VALUES (NULL, 'mothra');

Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM t1;

+------+--------+

| id | name |

+------+--------+

| NULL | mothra |

+------+--------+

1 row in set (0.00 sec)

mysql> SELECT * FROM t2;

+------+--------+

| id | name |

+------+--------+

| NULL | mothra |

+------+--------+

1 row in set (0.00 sec)

Вы можете видеть, в который раздел строки сохранены, осматривая файловую систему и сравнивая размеры .MYD-файлов:

/var/lib/mysql/test> ls -l *.MYD

– rw-rw---- 1 mysql mysql 20 2006-03-10 03:27 t1#P#p0.MYD

– rw-rw---- 1 mysql mysql 0 2006-03-10 03:17 t1#P#p1.MYD

– rw-rw---- 1 mysql mysql 0 2006-03-10 03:17 t1#P#p2.MYD

– rw-rw---- 1 mysql mysql 20 2006-03-10 03:27 t2#P#p0.MYD

– rw-rw---- 1 mysql mysql 0 2006-03-10 03:17 t2#P#p1.MYD

– rw-rw---- 1 mysql mysql 0 2006-03-10 03:17 t2#P#p2.MYD

– rw-rw---- 1 mysql mysql 0 2006-03-10 03:17 t2#P#p3.MYD

Файлы разделов именованы согласно формату table_name#P#partition_name .extension так, чтобы t1#P#p0.MYD был файлом, в котором сохранены данные, принадлежащие к разделу p0 таблицы t1. Обратите внимание: до MySQL 5.1.5, эти файлы были бы именованы соответственно t1_p0.MYD и t2_p0.MYD.

Вы можете также показывать, что эти строки были сохранены в самом низком разделе каждой таблицы, удаляя эти разделы, а затем делая повторный запуск инструкций SELECT:

mysql> ALTER TABLE t1 DROP PARTITION p0;

Query OK, 0 rows affected (0.16 sec)

mysql> ALTER TABLE t2 DROP PARTITION p0;

Query OK, 0 rows affected (0.16 sec)

mysql> SELECT * FROM t1;

Empty set (0.00 sec)

mysql> SELECT * FROM t2;

Empty set (0.00 sec)

Такая обработка также верна для выделения разделов с помощью выражений через использование функций SQL. Предположите, что мы имеем таблицу:

CREATE TABLE tndate (id INT, dt DATE) PARTITION BY RANGE(YEAR(dt)) (

PARTITION p0 VALUES LESS THAN (1990),

PARTITION p1 VALUES LESS THAN (2000),

PARTITION p2 VALUES LESS THAN MAXVALUE);

Как с другими функциями MySQL, YEAR(NULL) вернет NULL. Строка со значением NULL столбца dt обрабатывается, как если бы выражение выделения разделов было оценено к значению меньше, чем любое другое значение, и так вставлено в раздел p0.

Таблица, которая разбита на разделы LIST допускает значения NULL если (и только если!) один из разделов определен, используя список значений, который содержит NULL. Таблица, разбитая на разделы LIST, которая явно не использует NULL в списке значений, отклоняет строки, приводящие к значению NULL для выражения выделения разделов, как показано в этом примере:

mysql> CREATE TABLE ts1 (c1 INT, c2 VARCHAR(20))

– > PARTITION BY LIST(c1) (

– > PARTITION p0 VALUES IN (0, 3, 6),

– > PARTITION p1 VALUES IN (1, 4, 7),

– > PARTITION p2 VALUES IN (2, 5, 8));

Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO ts1 VALUES (9, 'mothra');

ERROR 1504 (HY000): Table has no partition for value 9

mysql> INSERT INTO ts1 VALUES (NULL, 'mothra');

ERROR 1504 (HY000): Table has no partition for value NULL

Только строки, имеющие значение c1 между 0 и 8 включительно, могут быть вставлены в ts1. NULL выходит за пределы этого диапазона точно так же, как число 9. Мы можем создавать таблицы ts2 и ts3 и списки значений, содержащие NULL, как показано здесь:

mysql> CREATE TABLE ts2 (c1 INT, c2 VARCHAR(20))

– > PARTITION BY LIST(c1) (

– > PARTITION p0 VALUES IN (0, 3, 6),

– > PARTITION p1 VALUES IN (1, 4, 7),

– > PARTITION p2 VALUES IN (2, 5, 8),

– > PARTITION p3 VALUES IN (NULL));

Query OK, 0 rows affected (0.01 sec)

mysql> CREATE TABLE ts3 (c1 INT, c2 VARCHAR(20))

– > PARTITION BY LIST(c1) (

– > PARTITION p0 VALUES IN (0, 3, 6),

– > PARTITION p1 VALUES IN (1, 4, 7, NULL),

– > PARTITION p2 VALUES IN (2, 5, 8));

Query OK, 0 rows affected (0.01 sec)

При определении значения для выделения разделов, Вы можете обрабатывать NULL точно как любое другое значение, и допустимы VALUES IN (NULL) и VALUES IN (1, 4, 7, NULL) (равно как и VALUES IN (1, NULL, 4, 7), VALUES IN (NULL, 1, 4, 7) и тому подобное). Вы можете вставлять строку, имеющую NULL для столбца c1 в каждую из таблиц ts2 и ts3:

mysql> INSERT INTO ts2 VALUES (NULL, 'mothra');

Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO ts3 VALUES (NULL, 'mothra');

Query OK, 1 row affected (0.00 sec)

Осматривая файловую систему, Вы можете проверить, что первая из этих инструкций вставила новую строку в раздел p3 таблицы ts2, а вторая инструкция вставила новую строку в раздел p1 таблицы ts3:

/var/lib/mysql/test> ls -l ts2*.MYD

– rw-rw---- 1 mysql mysql 0 2006-03-10 10:35 ts2#P#p0.MYD

– rw-rw---- 1 mysql mysql 0 2006-03-10 10:35 ts2#P#p1.MYD

– rw-rw---- 1 mysql mysql 0 2006-03-10 10:35 ts2#P#p2.MYD

– rw-rw---- 1 mysql mysql 20 2006-03-10 10:35 ts2#P#p3.MYD

/var/lib/mysql/test> ls -l ts3*.MYD

– rw-rw---- 1 mysql mysql 0 2006-03-10 10:36 ts3#P#p0.MYD

– rw-rw---- 1 mysql mysql 20 2006-03-10 10:36 ts3#P#p1.MYD

– rw-rw---- 1 mysql mysql 0 2006-03-10 10:36 ts3#P#p2.MYD

Как в более ранних примерах, мы принимаем использование оболочки bash в операционной системе для Unix для списка файлов. Например, если Вы используете оболочку DOS в операционной системе Windows эквивалент последнего вывода мог быть получен, выполняя команду dir ts3*.MYD в каталоге C:\Program Files\MySQL\MySQL Server 5.1\data\test.

Как показано ранее в этом разделе, Вы можете также проверять, которые разделы использовались для сохранения значений удаляя их, а затем выполняя SELECT.

NULL обработан несколько по-другому для таблиц, разбитых на разделы HASH или KEY. В этих случаях любое выражение раздела, которое выдает значение NULL, обрабатывается, как если бы возвращаемое значение было нулевым. Мы можем проверять это поведение, исследуя эффекты в файловой системе от создания таблицы, разбитой на разделы HASH и начальной загрузкой с записью, содержащей соответствующие значения. Предположите, что Вы имеете таблицу th, созданную в базе данных test, используя эту инструкцию:

mysql> CREATE TABLE th (c1 INT, c2 VARCHAR(20))

– > PARTITION BY HASH(c1) PARTITIONS 2;

Query OK, 0 rows affected (0.00 sec)

При принятии установки RPM MySQL под Linux, эта инструкция создает два .MYD-файла в /var/lib/mysql/test, которые могут просматриваться в оболочке bash следующим образом:

/var/lib/mysql/test> ls th*.MYD -l

– rw-rw---- 1 mysql mysql 0 2005-11-04 18:41 th#P#p0.MYD

– rw-rw---- 1 mysql mysql 0 2005-11-04 18:41 th#P#p1.MYD

Обратите внимание, что размер каждого файла 0 байтов. Теперь вставьте в th строку, чей столбец c1 является NULL, и проверьте, что эта строка была вставлена:

mysql> INSERT INTO th VALUES (NULL, 'mothra');

Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM th;

+------+---------+

| c1 | c2 |

+------+---------+

| NULL | mothra |

+------+---------+

1 row in set (0.01 sec)

Заметьте, что для любого целого числа N значение NULL MOD N всегда NULL. Для таблиц, которые разбиты на разделы HASH илм KEY, этот результат обрабатывается для определения правильного раздела как 0. При возврате к оболочке системы, мы можем видеть, что значение было вставлено в первый раздел (по умолчанию p0), выводя файлы данных еще раз:

var/lib/mysql/test> ls *.MYD -l

– rw-rw---- 1 mysql mysql 20 2005-11-04 18:44 th#P#p0.MYD

– rw-rw---- 1 mysql mysql 0 2005-11-04 18:41 th#P#p1.MYD

Вы можете видеть, что инструкция INSERT изменила только файл th#P#p0.MYD (увеличение размера на диске) без того, чтобы воздействовать на другой файл данных.

Важно: до MySQL 5.1.8 выделение разделов по RANGE значение выражения выделения разделов NULL работало как 0 (единственный способ обходить это должен был разработать таблицы так, чтобы не позволить пустые указатели, обычно объявляя столбцы NOT NULL). Если Вы имеете схему выделения разделов RANGE, которая зависит от этого более раннего поведения, Вы будете должны заново выполнить это при обновлении до MySQL 5.1.8 или позже.

3.3. Управление разделами

MySQL 5.1 обеспечивает ряд способов изменить разбитые на разделы таблицы. Возможно добавлять, удалять, переопределять, объединять или расчленять существующие разделы. Все эти действия могут быть выполнены, используя расширения выделения разделов к команде ALTER TABLE. Имеются также способы получить информацию относительно разбитых на разделы таблиц и разделов.

Обратите внимание: в MySQL 5.1 все разделы разбитой на разделы таблицы должны иметь то же самое число подразделов, и невозможно изменить подвыделение разделов, если только таблица была создана.

Инструкция ALTER TABLE … PARTITION BY … доступна с MySQL 5.1.6, предварительно, в MySQL 5.1, это было принято как допустимый синтаксис, но инструкция не делала ничего.

Чтобы изменять схему выделения разделов таблицы, необходимо использовать команду ALTER TABLE с предложением partition_options. Это предложение имеет тот же самый синтаксис, как то, что используется с CREATE TABLE для создания разбитой на разделы таблицы, и всегда начинается с ключевых слов PARTITION BY. Например, предположите, что Вы имеете таблицу, разбитую на разделы диапазоном, использующим следующую инструкцию CREATE TABLE:

CREATE TABLE trb3 (id INT, name VARCHAR(50), purchased DATE)

PARTITION BY RANGE(YEAR(purchased)) (

PARTITION p0 VALUES LESS THAN (1990),

PARTITION p1 VALUES LESS THAN (1995),

PARTITION p2 VALUES LESS THAN (2000),

PARTITION p3 VALUES LESS THAN (2005));

Чтобы заново выделять разделы этой таблицы так, чтобы это было разбито на разделы ключом на два раздела, использующие значение столбца id как основание для ключа, Вы можете использовать эту инструкцию:

ALTER TABLE trb3 PARTITION BY KEY(id) PARTITIONS 2;

Это имеет тот же самый эффект на структуре таблицы как удаление таблицы и создания ее вновь, используя CREATE TABLE trb3 PARTITION BY KEY(id) PARTITIONS 2;.

Важно: в MySQL 5.1.7 и ранее ALTER TABLE … ENGINE = … удаляет все выделение разделов из обрабатываемой таблицы. Начиная с MySQL 5.1.8, этот оператор меняет только тип памяти, используемый таблицей, и оставляет схему выделения разделов таблицы неповрежденной. С MySQL 5.1.8 применяйте ALTER TABLE … REMOVE PARTITIONING, чтобы удалить выделение разделов таблицы.

3.3.1. Управление разделами RANGE и LIST

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

Удаление раздела из таблицы, которая разбита на разделы RANGE или LIST может быть выполнено, используя инструкцию ALTER TABLE с предложением DROP PARTITION. Имеется базисный пример, который предполагает, что Вы уже создали таблицу, которая разбита на разделы диапазоном и затем заполняется 10 записями, использующими следующие инструкции CREATE TABLE и INSERT:

mysql> CREATE TABLE tr (id INT, name VARCHAR(50), purchased DATE)

– > PARTITION BY RANGE(YEAR(purchased)) (

– > PARTITION p0 VALUES LESS THAN (1990),

– > PARTITION p1 VALUES LESS THAN (1995),

– > PARTITION p2 VALUES LESS THAN (2000),

– > PARTITION p3 VALUES LESS THAN (2005));

Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO tr VALUES

– > (1, 'desk organiser', '2003-10-15'),

– > (2, 'CD player', '1993-11-05'),

– > (3, 'TV set', '1996-03-10'),

– > (4, 'bookcase', '1982-01-10'),

– > (5, 'exercise bike', '2004-05-09'),

– > (6, 'sofa', '1987-06-05'),

– > (7, 'popcorn maker', '2001-11-22'),

– > (8, 'aquarium', '1992-08-04'),

– > (9, 'study desk', '1984-09-16'),

– > (10, 'lava lamp', '1998-12-25');

Query OK, 10 rows affected (0.01 sec)

Вы можете видеть, которые элементы должны быть вставлены в раздел p2 как показано здесь:

mysql> SELECT * FROM tr WHERE purchased BETWEEN '1995-01-01' AND '1999-12-31';

+----+-----------+------------+

| id | name | purchased |

+----+-----------+------------+

| 3 | TV set | 1996-03-10 |

| 10 | lava lamp | 1998-12-25 |

+----+-----------+------------+

2 rows in set (0.00 sec)

Чтобы удалить раздел p2, выполните следующую команду:

mysql> ALTER TABLE tr DROP PARTITION p2;

Query OK, 0 rows affected (0.03 sec)

Обратите внимание: в MySQL 5.1 NDB Cluster не поддерживает ALTER TABLE … DROP PARTITION. Это, однако, поддерживает другие связанные с выделением разделов расширения ALTER TABLE, которые описаны в этой главе.

Очень важно не забыть, что, когда Вы удаляете раздел, Вы также удаляете все данные, которые был сохранены в этом разделе. Вы можете видеть, что дело обстоит именно так, делая повторный запуск предыдущего запроса SELECT:

SELECT * FROM tr WHERE purchased BETWEEN '1995-01-01' AND '1999-12-31';

Empty set (0.00 sec)

Из-за этого в MySQL 5.1.10 было добавлено требование, что Вы имеете привилегию DROP для таблицы прежде, чем Вы сможете выполнять ALTER TABLE … DROP PARTITION на этой таблице.

Если Вы желаете удалить все данные из всех разделов при сохранении определения таблицы и схемы выделения разделов, используйте команду TRUNCATE TABLE.

Если Вы предполагаете изменять выделение разделов таблицы без потерь данных, используйте вместо этого ALTER TABLE … REORGANIZE PARTITION.

Если Вы теперь выполняете команду SHOW CREATE TABLE, Вы можете видеть, как выделение разделов таблицы было изменено:

mysql> SHOW CREATE TABLE tr\G

*************************** 1. row ***************************

Table: tr

Create Table: CREATE TABLE `tr` (`id` int(11) default NULL,

`name` varchar(50) default NULL,

`purchased` date default NULL)

ENGINE=MyISAM DEFAULT CHARSET=latin1

PARTITION BY RANGE (YEAR(purchased)) (

PARTITION p0 VALUES LESS THAN (1990) ENGINE = MyISAM,

PARTITION p1 VALUES LESS THAN (1995) ENGINE = MyISAM,

PARTITION p3 VALUES LESS THAN (2005) ENGINE = MyISAM)

1 row in set (0.01 sec)

Когда Вы вставляете новые строки в измененную таблицу со значениями столбца purchased между '1995-01-01' и '2004-12-31' включительно, те строки будут сохранены в разделе p3. Вы можете проверять этот факт следующим образом:

mysql> INSERT INTO tr VALUES (11, 'pencil holder', '1995-07-12');

Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM tr WHERE purchased

– > BETWEEN '1995-01-01' AND '2004-12-31';

+----+----------------+------------+

| id | name | purchased |

+----+----------------+------------+

| 11 | pencil holder | 1995-07-12 |

| 1 | desk organiser | 2003-10-15 |

| 5 | exercise bike | 2004-05-09 |

| 7 | popcorn maker | 2001-11-22 |

+----+----------------+------------+

4 rows in set (0.00 sec)

mysql> ALTER TABLE tr DROP PARTITION p3;

Query OK, 0 rows affected (0.03 sec)

mysql> SELECT * FROM tr WHERE purchased

– > BETWEEN '1995-01-01' AND '2004-12-31';

Empty set (0.00 sec)

Обратите внимание, что число строк, удаленных из таблицы в результате ALTER TABLE … DROP PARTITION не сообщено сервером, поскольку это было бы эквивалентом запроса DELETE.

Удаление разделов LIST использует такой же синтаксис same ALTER TABLE … DROP PARTITION, как и для RANGE. Однако, имеется одно важное различие в эффекте, который это имеет на вашем использовании таблицы позже: Вы больше не можете вставлять в таблицу никакие строки, имеющие любое из значений, которые были включены в список значения, определяющие удаленный раздел.

Чтобы добавлять новый диапазон или раздел списка к предварительно разбитой на разделы таблице, используйте инструкцию ALTER TABLE … ADD PARTITION. Для таблиц, которые разбиты на разделы RANGE, это может использоваться, чтобы добавить новый диапазон к концу списка существующих разделов. Например, предположите, что Вы имеете разбитую на разделы таблицу, содержащую данные членства для Вашей организации, которая определена следующим образом:

CREATE TABLE members (id INT, fname VARCHAR(25), lname VARCHAR(25), dob DATE)

PARTITION BY RANGE(YEAR(dob)) (PARTITION p0 VALUES LESS THAN (1970),

PARTITION p1 VALUES LESS THAN (1980),

PARTITION p2 VALUES LESS THAN (1990));

Предположите далее, что минимальный возраст для элементов 3. Поскольку календарь приближается к концу 2005, Вы понимаете, что Вы будете скоро допускать элементы, которые были рождены в 1990 (и позже в последующих годах). Вы можете изменять таблицу элементов, чтобыразместить новые элементы members, рожденные в годах 1990-1999 как показано здесь:

ALTER TABLE ADD PARTITION (PARTITION p3 VALUES LESS THAN (2000));

Важно: с таблицами, которые разбиты на разделы диапазоном, Вы можете использовать ADD PARTITION, чтобы добавить новые разделы только к верхнему концу списка разделов. Попытки добавлять новый раздел этим способом между или прежде, чем существующие разделы, приведут к ошибке, как показано здесь:

mysql> ALTER TABLE members

– > ADD PARTITION (PARTITION p3 VALUES LESS THAN (1960));

ERROR 1463 (HY000): VALUES LESS THAN value must be strictly

increasing for each partition

В подобном режиме Вы можете добавлять новые разделы к таблице, которая разбита на разделы LIST. Например, данная таблица определена подобно этому:

CREATE TABLE tt (id INT, data INT)

PARTITION BY LIST(data) (PARTITION p0 VALUES IN (5, 10, 15),

PARTITION p1 VALUES IN (6, 12, 18));

Вы можете добавлять новый раздел, чтобы сохранить строки, имеющие значения столбца data 7, 14 и 21 как показано здесь:

ALTER TABLE tt ADD PARTITION (PARTITION p2 VALUES IN (7, 14, 21));

Обратите внимание, что Вы не можете добавлять новый раздел LIST, включающий любые значения, которые уже включены в список значений существующего раздела (сервер не поймет, в какой именно раздел ему дописывать данные). Если Вы пытаетесь сделать так, выйдет ошибка:

mysql> ALTER TABLE tt ADD PARTITION

– > (PARTITION np VALUES IN (4, 8, 12));

ERROR 1465 (HY000): Multiple definition of same constant ┬╗

in list partitioning

Потому что любые строки со значением столбца data 12 уже были назначены в раздел p1, Вы не можете создавать новый раздел в таблице tt, который включает 12 в список значения. Чтобы выполнять это, Вы могли бы удалить p1, добавить np, а затем новый p1 с изменяемым определением. Однако, как сказано ранее, это привело бы к потере всех данных, сохраненных в p1, и это часто имеет место. Другое решение: сделать копию таблицы с новым выделением разделов и скопировать данные в нее, используя CREATE TABLE … SELECT …, затем удалить старую таблицу и переименовать новую, но это могло бы быть очень долго, когда имеешь дело с большими количествами данных. Это также не может быть возможно в ситуациях, где высокая доступность является требованием.

Начиная с MySQL 5.1.6, Вы можете добавлять много разделов в одиночной команде ALTER TABLE … ADD PARTITION, как показано здесь:

CREATE TABLE employees (id INT NOT NULL, fname VARCHAR(50) NOT NULL,

lname VARCHAR(50) NOT NULL, hired DATE NOT NULL)

PARTITION BY RANGE(YEAR(hired)) (

PARTITION p1 VALUES LESS THAN (1991),

PARTITION p2 VALUES LESS THAN (1996),

PARTITION p3 VALUES LESS THAN (2001),

PARTITION p4 VALUES LESS THAN (2005));

ALTER TABLE employees ADD PARTITION (PARTITION p5 VALUES LESS THAN (2010),

PARTITION p6 VALUES LESS THAN MAXVALUE);

Реализация выделения разделов в MySQL обеспечивает способы переопределить разделы без потерь данных. Выберите таблицу элементов members, которая теперь определена как показано здесь:

mysql> SHOW CREATE TABLE members\G

*************************** 1. row ***************************

Table: members

Create Table: CREATE TABLE `members` (`id` int(11) default NULL,

`fname` varchar(25) default NULL,

`lname` varchar(25) default NULL,

`dob` date default NULL)

ENGINE=MyISAM DEFAULT CHARSET=latin1

PARTITION BY RANGE (YEAR(dob)) (

PARTITION p0 VALUES LESS THAN (1970) ENGINE = MyISAM,

PARTITION p1 VALUES LESS THAN (1980) ENGINE = MyISAM,

PARTITION p2 VALUES LESS THAN (1990) ENGINE = MyISAM.

PARTITION p3 VALUES LESS THAN (2000) ENGINE = MyISAM)

Предположите, что Вы хотели бы переместить все строки, представляющие элементы, рожденные перед 1960 в отдельный раздел. Мы уже видели, что это не может быть выполнено, используя ALTER TABLE … ADD PARTITION. Однако, Вы можете использовать другое связанное с разделом расширение ALTER TABLE, чтобы выполнить это:

ALTER TABLE members REORGANIZE PARTITION p0 INTO (

PARTITION s0 VALUES LESS THAN (1960),

PARTITION s1 VALUES LESS THAN (1970));

В действительности эти команды разделяют раздел p0 на два новых раздела s0 и s1. Это также перемещает данные, которые были сохранены в p0, в новые разделы согласно правилам, воплощенным в двух предложениях PARTITION … VALUES …, так, чтобы s0 содержал только те записи, для которых YEAR(dob) меньше, чем 1960 и s1 хранил те строки, в которых YEAR(dob) является большим чем или равным 1960, но меньше чем 1970.

Предложение REORGANIZE PARTITION может также использоваться для объединения смежных разделов. Вы можете возвращать таблицу элементов members к предыдущему выделению разделов, как показано здесь:

ALTER TABLE members REORGANIZE PARTITION s0,s1 INTO (

PARTITION p0 VALUES LESS THAN (1970));

Никакие данные не потеряны при разбиении или объединении разделов, использующих REORGANIZE PARTITION. При выполнении вышеупомянутой инструкции MySQL перемещает все записи, которые были сохранены в разделах s0 и s1 в раздел p0.

Общий синтаксис для REORGANIZE PARTITION:

ALTER TABLE tbl_name

REORGANIZE PARTITION partition_list

INTO (partition_definitions);

Здесь tbl_name имя разбитой на разделы таблицы, partition_list разделяемый запятыми список имен одного или большего количества существующих разделов, которые будут изменены. partition_definitions разделяемый запятыми список новых определений разделов, которые следуют тем же самым правилам, что касаются списка partition_definitions, используемого в CREATE TABLE. Должно быть отмечено, что Вы не ограничены объединением нескольких разделов в один или разбиением одного раздела на много, когда используете REORGANIZE PARTITION. Например, Вы можете реорганизовать все четыре раздела таблицы элементов members в два следующим образом:

ALTER TABLE members REORGANIZE PARTITION p0,p1,p2,p3 INTO (

PARTITION m0 VALUES LESS THAN (1980),

PARTITION m1 VALUES LESS THAN (2000));

Вы можете также использовать REORGANIZE PARTITION с таблицами, которые разбиты на разделы LIST. Вернемся к проблеме добавления нового раздела к разбитой на разделы списком таблице tt и тому, что новый раздел имел значение, которое было уже представлено в списке значений одного из существующих разделов. Мы можем обрабатывать это, добавляя раздел, который содержит только не находящиеся в противоречии значения, а затем реорганизуя новый и существующий разделы так, чтобы значение, которое было сохранено в существующем, переместилось в новый:

ALTER TABLE tt ADD PARTITION (PARTITION np VALUES IN (4, 8));

ALTER TABLE tt REORGANIZE PARTITION p1,np INTO (

PARTITION p1 VALUES IN (6, 18),

PARTITION np VALUES in (4, 8, 12));

Имеются некоторые ключевые точки, которые следует иметь в виду, когда используете ALTER TABLE … REORGANIZE PARTITION, чтобы заново выделить разделы таблиц, которые разбиты на разделы RANGE или LIST:

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

Наиболее важно, Вы должны не забыть, что новая схема выделения разделов не может иметь любые диапазоны перекрывания (применяется к таблицам, разбитым на разделы RANGE) или наборов значений (при реорганизации таблиц, разбитых на разделы LIST).

Обратите внимание: до MySQL 5.1.4 Вы не могли бы многократно использовать имена существующих разделов в предложении INTO, даже когда те разделы удалялись удалялись или переопределялись.

Комбинация разделов в списке partition_definitions должна объявить тот же самый диапазон или полный набор значений, что и объединенные разделы, именованные в partition_list.

Например, в таблице элементов members, используемой в этом разделе, выделяются разделы p1 и p2, которые вместе покрывают годы с 1980 по 1999. Следовательно, любая реорганизация этих двух разделов должна покрыть тот же самый диапазон полных лет.

Для таблиц, разбитых на разделы RANGE Вы можете реорганизовать только смежные разделы. Вы не можете перескакивать над разделами диапазона.

Например, Вы не могли бы реорганизовать таблицу элементов members, используемую в этом разделе, используя инструкцию, начинающуюся ALTER TABLE members REORGANIZE PARTITION p0, p2 INTO …, поскольку p0 покрывает годы до 1970, а p2 годы с 1990 по 1999 включительно, и таким образом это не смежные разделы.

Вы не можете использовать REORGANIZE PARTITION, чтобы изменить тип выделения разделов таблицы, то есть Вы не можете (например) изменять разделы RANGE на HASH или наоборот. Вы также не можете использовать эту команду, чтобы изменить выражение выделения разделов или столбец. Чтобы выполнять любую из этих задач без того, чтобы удалить и вновь создать таблицу, Вы можете использовать ALTER TABLE … PARTITION BY …. Например:

ALTER TABLE members PARTITION BY HASH(YEAR(dob)) PARTITIONS 8;

3.3.2. Управление разделами KEY и HASH

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

Вы не можете удалять разделы из таблиц, которые разбиты на разделы HASH или KEY таким же образом, каким Вы можете удалять их из таблиц, которые разбиты на разделы RANGE или LIST. Однако, Вы можете объединять разделы HASH или KEY, используя команду ALTER TABLE … COALESCE PARTITION. Например, предположите, что Вы имеете таблицу, содержащую данные относительно клиентуры, которая разделена на двенадцать разделов. Таблица clients определена как показано здесь:

CREATE TABLE clients (id INT, fname VARCHAR(30),

lname VARCHAR(30), signed DATE)

PARTITION BY HASH(MONTH(signed)) PARTITIONS 12;

Чтобы уменьшить число разделов с двенадцати до восьми, выполните следующую команду ALTER TABLE:

mysql> ALTER TABLE clients COALESCE PARTITION 4;

Query OK, 0 rows affected (0.02 sec)

COALESCE работает одинаково хорошо с таблицами, которые разбиты на разделы HASH, KEY, LINEAR HASH или LINEAR KEY. Имеется пример, подобный предыдущему, отличаясь только тем, что таблица разбита на разделы LINEAR KEY:

mysql> CREATE TABLE clients_lk (id INT, fname VARCHAR(30),

– > lname VARCHAR(30), signed DATE)

– > PARTITION BY LINEAR KEY(signed) PARTITIONS 12;

Query OK, 0 rows affected (0.03 sec)

mysql> ALTER TABLE clients_lk COALESCE PARTITION 4;

Query OK, 0 rows affected (0.06 sec)

Records: 0 Duplicates: 0 Warnings: 0

Обратите внимание, что число, следующее за COALESCE PARTITION являются числом разделов, которое надлежит удалить из таблицы.

Если Вы пытаетесь удалить большее количество разделов, чем таблица имеет, результатом будет ошибка:

mysql> ALTER TABLE clients COALESCE PARTITION 18;

ERROR 1478 (HY000): Cannot remove all partitions, use DROP TABLE instead

Чтобы увеличить число разделов для таблицы clients с 12 до 18, скомандуйте ALTER TABLE … ADD PARTITION:

ALTER TABLE clients ADD PARTITION PARTITIONS 6;

3.3.3. Сопровождение разделов

Ряд задач сопровождения выделения разделов может быть выполнен в MySQL 5.1. MySQL не поддерживает команды CHECK TABLE, OPTIMIZE TABLE, ANALYZE TABLE или REPAIR TABLE для разбитых на разделы таблиц. Вместо этого Вы можете использовать ряд расширений ALTER TABLE, которые были выполнены в MySQL 5.1.5.

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

Rebuilding partitions

: восстанавливает раздел: это имеет тот же самый эффект, что и удаление всех записей, сохраненных в разделе, с последующей перевставкой их. Это может быть полезно с целью дефрагментации. Пример:

ALTER TABLE t1 REBUILD PARTITION p0, p1;

Optimizing partitions: если Вы удалили большое количество строк из раздела или сделали много изменений для разбитой на разделы таблицы со строками переменной длины (то есть, имея столбцы VARCHAR, BLOB или TEXT), Вы можете использовать ALTER TABLE … OPTIMIZE PARTITION, чтобы восстановить неиспользуемое место и дефрагментировать файл данных раздела:

ALTER TABLE t1 OPTIMIZE PARTITION p0, p1;

Использование OPTIMIZE PARTITION на данном разделе эквивалентно выполнению CHECK PARTITION, ANALYZE PARTITION и REPAIR PARTITION.

Analyzing partitions: читает и сохраняет распределения ключа для разделов. Пример:

ALTER TABLE t1 ANALYZE PARTITION p3;

Repairing partitions: это восстанавливает разрушенные разделы. Пример:

ALTER TABLE t1 REPAIR PARTITION p0,p1;

Checking partitions: Вы можете проверять раздел на ошибки способом, которым Вы можете использовать CHECK TABLE с не разбитыми на разделы таблицами:

ALTER TABLE trb3 CHECK PARTITION p1;

Эта команда сообщит Вам, если данные или индексы в разделе p1 таблицы t1 разрушены. Если дело обстоит так, используйте ALTER TABLE … REPAIR PARTITION для ремонта раздела.

Вы можете также использовать утилиту mysqlcheck или myisamchk, чтобы выполнить эти задачи, действуя на отдельных .MYI-файлах, сгенерированных, выделяя разделы таблицы.

3.3.4. Получение информации относительно разделов

Этот раздел обсуждает получение информации относительно существующих разделов, что может быть выполнено несколькими способами. Они включают:

Использование инструкции SHOW CREATE TABLE, чтобы просмотреть предложения выделения разделов, используемые в создании разбитой на разделы таблицы.

Использование инструкции SHOW TABLE STATUS, чтобы определить, разбита ли таблица на разделы вообще.

Запрос таблицы INFORMATION_SCHEMA.PARTITIONS.

Использование инструкции EXPLAIN PARTITIONS SELECT, чтобы видеть, которые разделы используются данным SELECT.

SHOW CREATE TABLE включает в вывод предложение PARTITION BY, используемое, чтобы создать разбитую на разделы таблицу. Например:

mysql> SHOW CREATE TABLE trb3\G

*************************** 1. row ***************************

Table: trb3

Create Table: CREATE TABLE `trb3` (`id` int(11) default NULL,

`name` varchar(50) default NULL,

`purchased` date default NULL)

ENGINE=MyISAM DEFAULT CHARSET=latin1

PARTITION BY RANGE (YEAR(purchased)) (

PARTITION p0 VALUES LESS THAN (1990) ENGINE = MyISAM,

PARTITION p1 VALUES LESS THAN (1995) ENGINE = MyISAM,

PARTITION p2 VALUES LESS THAN (2000) ENGINE = MyISAM,

PARTITION p3 VALUES LESS THAN (2005) ENGINE = MyISAM)

1 row in set (0.00 sec)

Обратите внимание: в ранних версиях MySQL 5.1 предложение PARTITIONS не показывалось для

таблиц, разбитых на разделы HASH или KEY. Эта проблема была отфиксирована в MySQL 5.1.6.

SHOW TABLE STATUS работает с разбитыми на разделы таблицами. Начиная с MySQL 5.1.9, вывод такой же, как для не разбитых на разделы таблиц за исключением того, что столбец Create_options содержит строку partitioned. В MySQL 5.1.8 и ранее столбец Engine всегда содержал значение PARTITION. Начиная с MySQL 5.1.9, этот столбец содержит имя типа памяти, используемого всеми разделами таблицы.

Вы можете также получать информацию относительно разделов из INFORMATION_SCHEMA, которая содержит таблицу PARTITIONS.

Начиная с MySQL 5.1.5, можно определить, которые разделы разбитой на разделы таблицы включаются в данном запросе SELECT, применяя EXPLAIN PARTITIONS. Ключевое слово PARTITIONS

добавляет столбец partitions к выводу EXPLAIN, перечисляющего столбцы, из которых записи соответствуют запросу.

Предположите, что Вы имеете таблицу trb1 определенную и заполняемую следующим образом:

CREATE TABLE trb1 (id INT, name VARCHAR(50), purchased DATE)

PARTITION BY RANGE(id) (PARTITION p0 VALUES LESS THAN (3),

PARTITION p1 VALUES LESS THAN (7),

PARTITION p2 VALUES LESS THAN (9),

PARTITION p3 VALUES LESS THAN (11));

INSERT INTO trb1 VALUES (1, 'desk organiser', '2003-10-15'),

(2, 'CD player', '1993-11-05'),

(3, 'TV set', '1996-03-10'),

(4, 'bookcase', '1982-01-10'),

(5, 'exercise bike', '2004-05-09'),

(6, 'sofa', '1987-06-05'),

(7, 'popcorn maker', '2001-11-22'),

(8, 'aquarium', '1992-08-04'),

(9, 'study desk', '1984-09-16'),

(10, 'lava lamp', '1998-12-25');

Вы можете видеть, которые разделы используются в запросе типа SELECT * FROM trb1;, как показано здесь:

mysql> EXPLAIN PARTITIONS SELECT * FROM trb1\G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: trb1

partitions: p0,p1,p2,p3

type: ALL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: 10

Extra: Using filesort

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

mysql> EXPLAIN PARTITIONS SELECT * FROM trb1 WHERE id < 5\G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: trb1

partitions: p0, p1

type: ALL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: 10

Extra: Using where

EXPLAIN PARTITIONS обеспечивают информацию относительно используемых и возможных ключей, точно как со стандартной инструкцией EXPLAIN SELECT:

mysql> ALTER TABLE trb1 ADD PRIMARY KEY (id);

Query OK, 10 rows affected (0.03 sec)

Records: 10 Duplicates: 0 Warnings: 0

mysql> EXPLAIN PARTITIONS SELECT * FROM trb1 WHERE id < 5\G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: trb1

partitions: p0, p1

type: range

possible_keys: PRIMARY

key: PRIMARY

key_len: 4

ref: NULL

rows: 7

Extra: Using where

Вы должны принять во внимание следующие ограничения на EXPLAIN PARTITIONS:

Вы не можете использовать ключевые слова PARTITIONS и EXTENDED вместе в том же самом запросе EXPLAIN … SELECT. Попытка сделать так производит синтаксическую ошибку.

Если EXPLAIN PARTITIONS используется, чтобы исследовать запрос для не разбитой на разделы таблицы, никакая ошибка не будет произведена, но значение столбца partitions всегда NULL.

3.4. Сокращение раздела

Этот раздел обсуждает сокращение раздела (partition pruning), оптимизацию, которая была выполнена для разбитых на разделы таблиц в MySQL 5.1.6.

Основное понятие сокращения раздела относительно просто, и может быть описано как "не просматриваются разделы, где не может иметься никаких значений соответствия". Например, предположите, что Вы имеете разбитую на разделы таблицу t1, определенную этой инструкцией:

CREATE TABLE t1 (fname VARCHAR(50) NOT NULL, lname VARCHAR(50) NOT NULL,

region_code TINYINT UNSIGNED NOT NULL, dob DATE NOT NULL)

PARTITION BY RANGE(region_code) (

PARTITION p0 VALUES LESS THAN (64),

PARTITION p1 VALUES LESS THAN (128),

PARTITION p2 VALUES LESS THAN (192)

PARTITION p3 VALUES LESS THAN MAXVALUE);

Рассмотрите случай, где Вы желаете получить результат запроса типа этого:

SELECT fname, lname, postcode, dob FROM t1

WHERE region_code > 125 AND

region_code < 130;

Просто видеть, что ни одна из строк, которые должны быть возвращены, не будет в разделе p0 или p3. То есть, мы должны искать данные только в разделах p1 и p2, чтобы найти строки соответствий. Делая так, можно расходовать намного меньше времени и усилий в нахождении строк соответствий, чем при просмотре всех разделов в таблице. Это и известно как сокращение (pruning). Когда оптимизатор может использовать сокращение раздела, выполнение запроса может быть на порядок быстрее, чем тот же самый запрос на не разбитой на разделы таблицы, содержащей те же самые определения столбца и данные.

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

partition_column = constant

partition_column IN (constant1, constant2, …, constantN)

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

Сокращение может также применяться к коротким диапазонам, которые оптимизатор может преобразовывать в эквивалентные списки значений. Например, в предыдущем примере, предложение WHERE может быть преобразовано в WHERE region_code IN (125, 126, 127, 128, 129, 130). Затем оптимизатор может определять, что первые три значения в списке найдены в разделе p1, следующие три значения в разделе p2 и что другие разделы не содержат никаких релевантных значений.

Этот тип оптимизации может применяться всякий раз, когда выражение выделения разделов состоит из равенства или диапазона, который может быть уменьшен до набора равенств, или же когда выражение выделения разделов представляет связь уменьшения или увеличение. Сокращение может также быть применено для таблиц, разбитых на разделы на основании столбцов DATE или DATETIME, когда выражение выделения разделов использует функцию YEAR() или TO_DAYS().

Обратите внимание: в будущих версиях MySQL планируется добавлять поддержку сокращения для дополнительных функций, которые действуют на значения DATE или DATETIME, возвращают целое число и увеличиваются или уменьшаются. Например, предположите, что таблица t2, определенная как показано здесь, разбита на разделы на столбце DATE:

CREATE TABLE t2 (fname VARCHAR(50) NOT NULL,

lname VARCHAR(50) NOT NULL,

region_code TINYINT UNSIGNED NOT NULL,

dob DATE NOT NULL)

PARTITION BY RANGE(YEAR(dob)) (

PARTITION d0 VALUES LESS THAN (1970),

PARTITION d1 VALUES LESS THAN (1975),

PARTITION d2 VALUES LESS THAN (1980),

PARTITION d3 VALUES LESS THAN (1985),

PARTITION d4 VALUES LESS THAN (1990),

PARTITION d5 VALUES LESS THAN (2000),

PARTITION d6 VALUES LESS THAN (2005),

PARTITION d7 VALUES LESS THAN MAXVALUE);

Следующие запросы к t2 могут использовать сокращение:

SELECT * FROM t2 WHERE dob = '1982-06-23';

SELECT * FROM t2 WHERE dob BETWEEN '1991-02-15' AND '1997-04-25';

SELECT * FROM t2 WHERE YEAR(dob) IN (1979, 1980, 1983, 1985, 1986, 1988);

SELECT * FROM t2 WHERE dob >= '1984-06-21' AND dob <= '1999-06-21'

В случае последнего запроса оптимизатор может также действовать следующим образом:

Найти раздел, содержащий нижний конец диапазона..

YEAR('1984-06-21') выдает значение 1984, которое найдено в разделе d3.

Найти раздел, содержащий верхний конец диапазона..

YEAR('1999-06-21') оценивается к 1999, которое найдено в разделе d5.

Просмотреть только эти два раздела и любые разделы, которые могут находиться между ними.

В этом случае, это означает, что просмотрены только разделы d3, d4 и d5. Остающиеся разделы могут безопасно игнорироваться (и игнорируются).

Пока мы смотрели только на примеры, использующие выделение разделов RANGE, но сокращение может применяться также и с другими типами выделения разделов.

Рассмотрите таблицу, которая разбита на разделы LIST, где выражение выделения разделов увеличивается или уменьшается, типа таблицы t3, показанной здесь. В этом примере мы принимаем для краткости, что столбец region_code ограничен значениями от 1 до 10.

CREATE TABLE t3 (fname VARCHAR(50) NOT NULL, lname VARCHAR(50) NOT NULL, region_code TINYINT UNSIGNED NOT NULL, dob DATE NOT NULL)

PARTITION BY LIST(region_code) (

PARTITION r0 VALUES IN (1, 3),

PARTITION r1 VALUES IN (2, 5, 8),

PARTITION r2 VALUES IN (4, 9),

PARTITION r3 VALUES IN (6, 7, 10));

Для запроса типа

SELECT * FROM t3 WHERE region_code BETWEEN 1 AND 3

оптимизатор определяет, в которых разделах значения 1, 2 и 3 найдены (r0 и r1) и пропускает остающиеся (r2 и r3).

Для таблиц, которые разбиты на разделы HASH или KEY, сокращение раздела также возможно в случаях, в которых предложение WHERE использует простое отношение = против столбца, используемого в выражении выделения разделов. Рассмотрите таблицу, созданную подобно этому:

CREATE TABLE t4 (fname VARCHAR(50) NOT NULL, lname VARCHAR(50) NOT NULL,

region_code TINYINT UNSIGNED NOT NULL,

dob DATE NOT NULL)

PARTITION BY KEY(region_code) PARTITIONS 8;

Любой запрос типа этого может быть сокращен:

SELECT * FROM t4 WHERE region_code = 7;

Сокращение также может быть использовано для коротких диапазонов, потому что оптимизатор может направлять такие условия в отношениях IN. Например, при использовании той же самой таблицы t4 как определено ранее, запросы типа этих могут быть сокращены:

SELECT * FROM t4 WHERE region_code > 2 AND region_code < 6;

SELECT * FROM t4 WHERE region_code BETWEEN 3 AND 5;

В обеих случаях, предложения WHERE преобразованы оптимизатором в WHERE region_code IN (3, 4, 5).

Важно: эта оптимизация используется только, если размер диапазона меньший, чем число разделов.

Рассмотрите этот запрос:

SELECT * FROM t4 WHERE region_code BETWEEN 4 AND 8;

Диапазон в предложении WHERE покрывает 5 значений (4, 5, 6, 7, 8), но t4 имеет только 4 раздела. Это означает, что предыдущий запрос никак не может быть сокращен.

Сокращение может использоваться только на целочисленных столбцах таблиц, разбитых на разделы HASH или KEY. Например, этот запрос на таблице t4 не может использовать сокращение, потому что dob столбец типа DATE:

SELECT * FROM t4 WHERE dob >=- '2001-04-14' AND dob <= '2005-10-15';

Однако, если таблица сохраняет значения года в столбце типа INT, то запрос WHERE year_col >= 2001 AND year_col <= 2005 может быть сокращен.

3.5. Ограничения выделения разделов

Этот раздел обсуждает текущие ограничения поддержки выделения разделов MySQL:

Начиная с MySQL 5.1.12, следующие конструкции не разрешаются в выражениях выделения разделов:

Вложенные обращения к функциям (то есть, конструкции типа func1(func2(col_name))).

Сохраненные процедуры, функции, UDF или plugins.

Объявленные переменные или переменные пользователя.

Начиная с MySQL 5.1.12, следующие функции MySQL специально не позволяются в выражениях выделения разделов:

GREATEST()

ISNULL()

LEAST()

CASE()

IFNULL()

NULLIF()

BIT_LENGTH()

CHAR_LENGTH()

CHARACTER_LENGTH()

FIND_IN_SET()

INSTR()

LENGTH()

LOCATE()

OCTET_LENGTH()

POSITION()

STRCMP()

CRC32()

ROUND()

SIGN()

DATEDIFF()

PERIOD_ADD()

PERIOD_DIFF()

TIMESTAMPDIFF()

UNIX_TIMESTAMP()

WEEK()

CAST()

CONVERT()

BIT_COUNT()

INET_ATON()

Использование арифметических операторов +, -, * и / разрешается в выражениях выделения разделов. Однако, результат должен быть целочисленным значением или NULL (за исключением [LINEAR] KEY).

Начиная с MySQL 5.1.12, разрядные операторы |, , ^, <<, >> и ~ не разрешаются в выражениях выделения разделов.

Начиная с MySQL 5.1.12, только следующие функции MySQL поддерживаются в выражениях выделения разделов:

ABS()

ASCII()

CEILING()

DAY()

DAYOFMONTH()

DAYOFWEEK()

DAYOFYEAR()

EXTRACT()

FLOOR()

HOUR()

MICROSECOND()

MINUTE()

MOD()

MONTH()

ORD()

QUARTER()

SECOND()

TIME_TO_SEC()

TO_DAYS()

WEEKDAY()

WEEKOFYEAR()

YEAR()

YEARWEEK()

Важно: Вы должны иметь в виду, что результаты многих функций MySQL и операторов могут изменять SQL-режим сервера. По этой причине нежелательно изменять этот режим после создания разбитых на разделы таблиц.

Использование функций ASCII() или ORD(), чтобы преобразовать строковое значение (столбца типа CHAR или VARCHAR) к целому числу работает только, когда строка использует 8-разрядный набор символов. Объединение, используемое для строки, может быть любым объединением для связанного набора символов. Однако, объединения latin1_german2_ci, latin2_czech_cs и cp1250_czech_cs не могут использоваться, вследствие того, что эти объединения требуют символьных преобразований "один ко многим".

Если при создании таблиц с очень большим количеством разделов Вы сталкиваетесь с сообщением об ошибках типа Got error 24 from storage engine, Вы должны увеличить значение переменной системы open_files_limit.

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

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

Разбитые на разделы таблицы не поддерживают столбцы GEOMETRY.

Начиная с MySQL 5.1.8, временные таблицы не могут быть разбиты на разделы ().

Таблицы, использующие тип памяти MERGE, не могут быть разбиты на разделы.

Разбитые на разделы таблицы, использующие тип памяти CSV, не обеспечиваются. Начиная с MySQL 5.1.12, невозможно создать разбитые на разделы таблицы CSV вообще.

До MySQL 5.1.6 таблицы, использующие тип памяти BLACKHOLE, также не могли быть разбиты на разделы.

Выделение разделов KEY (или LINEAR KEY) представляет собой единственный тип выделения разделов обеспечиваемого для типа памяти NDB. Начиная с MySQL 5.1.12, невозможно создать таблицу Cluster, использующую любое выделение разделов, кроме [LINEAR] KEY, а попытка это сделать вызывает ошибку.

При выполнении обновления, таблицы, использующие любой тип памяти (кроме NDBCLUSTER), которые разбиты на разделы KEY, должны разгрузиться и перезагрузиться.

Все разделы таблицы и подразделы (если имеется любой из последних) должны использовать тот же самый тип памяти.

Ключ выделения разделов должен быть целочисленным столбцом или выражением, которое решается к целому числу. Столбец или значение выражения может также быть NULL.

Одна исключительная ситуация к этому ограничению происходит при выделении разделов [LINEAR] KEY, где возможно использовать столбцы других типов как ключи выделения разделов потому, что MySQL с помощью хэш-функции производит внутренний ключ правильного типа данных из этих типов.

Например, следующая инструкция CREATE TABLE допустима:

CREATE TABLE tkc (c1 CHAR) PARTITION BY KEY(c1) PARTITIONS 4;

Эта исключительная ситуация не относится к типам столбцов BLOB или TEXT.

Ключ выделения разделов не может быть подзапросом, даже если этот подзапрос решается к целочисленному значению или NULL.

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

Например, каждая из следующих инструкций создания таблицы недопустима:

CREATE TABLE t1 (col1 INT NOT NULL, col2 DATE NOT NULL,

col3 INT NOT NULL, col4 INT NOT NULL,

UNIQUE KEY (col1, col2))

PARTITION BY HASH(col3) PARTITIONS 4;

CREATE TABLE t2 (col1 INT NOT NULL, col2 DATE NOT NULL,

col3 INT NOT NULL, col4 INT NOT NULL,

UNIQUE KEY (col1), UNIQUE KEY (col3))

PARTITION BY HASH(col1 + col3) PARTITIONS 4;

CREATE TABLE t3 (col1 INT NOT NULL, col2 DATE NOT NULL,

col3 INT NOT NULL, col4 INT NOT NULL,

UNIQUE KEY (col1, col2), UNIQUE KEY (col3))

PARTITION BY HASH(col1 + col3) PARTITIONS 4;

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

Каждая из следующих инструкций допустима и представляет один способ, которым соответствующая недопустимая инструкция создания таблицы могла бы быть сделана рабочей:

CREATE TABLE t1 (col1 INT NOT NULL, col2 DATE NOT NULL,

col3 INT NOT NULL, col4 INT NOT NULL,

UNIQUE KEY (col1, col2, col3))

PARTITION BY HASH(col3) PARTITIONS 4;

CREATE TABLE t2 (col1 INT NOT NULL, col2 DATE NOT NULL,

col3 INT NOT NULL, col4 INT NOT NULL,

UNIQUE KEY (col1, col3))

PARTITION BY HASH(col1 + col3) PARTITIONS 4;

CREATE TABLE t3 (col1 INT NOT NULL, col2 DATE NOT NULL,

col3 INT NOT NULL, col4 INT NOT NULL,

UNIQUE KEY (col1, col2, col3), UNIQUE KEY (col3))

PARTITION BY HASH(col3) PARTITIONS 4;

Так как каждый первичный ключ по определению уникальный ключ, это ограничение также включает первичный ключ таблицы, если он есть. Например, следующие две инструкции недопустимы:

CREATE TABLE t4 (col1 INT NOT NULL, col2 DATE NOT NULL,

col3 INT NOT NULL, col4 INT NOT NULL,

PRIMARY KEY(col1, col2))

PARTITION BY HASH(col3) PARTITIONS 4;

CREATE TABLE t5 (col1 INT NOT NULL, col2 DATE NOT NULL,

col3 INT NOT NULL, col4 INT NOT NULL,

PRIMARY KEY(col1, col3), UNIQUE KEY(col2))

PARTITION BY HASH(YEAR(col2)) PARTITIONS 4;

В обоих случаях первичный ключ не включает все столбцы, названные в выражении выделения разделов. Однако, обе из следующих двух инструкций допустимы:

CREATE TABLE t6 (col1 INT NOT NULL, col2 DATE NOT NULL,

col3 INT NOT NULL, col4 INT NOT NULL,

PRIMARY KEY(col1, col2))

PARTITION BY HASH(col1 + YEAR(col2)) PARTITIONS 4;

CREATE TABLE t7 (col1 INT NOT NULL, col2 DATE NOT NULL,

col3 INT NOT NULL, col4 INT NOT NULL,

PRIMARY KEY(col1, col2, col4), UNIQUE KEY(col2, col1))

PARTITION BY HASH(col1 + YEAR(col2)) PARTITIONS 4;

Если таблица не имеет никакого уникального или первичного ключа, то это ограничение не применяется, и Вы можете использовать любой столбец или столбцы в выражении выделения разделов, пока тип столбца совместим с типом выделения разделов.

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

CREATE TABLE t_no_pk (c1 INT, c2 INT)

PARTITION BY RANGE(c1) (PARTITION p0 VALUES LESS THAN (10),

PARTITION p1 VALUES LESS THAN (20),

PARTITION p2 VALUES LESS THAN (30),

PARTITION p3 VALUES LESS THAN (40));

Возможно добавить первичный ключ к t_no_pk, используя любую из этих инструкций ALTER TABLE:

# possible PK

ALTER TABLE t_no_pk ADD PRIMARY KEY(c1);

# also a possible PK

ALTER TABLE t_no_pk ADD PRIMARY KEY(c1, c2);

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

# fails with ERROR 1482

ALTER TABLE t_no_pk ADD PRIMARY KEY(c2);

С тех пор как t_no_pk имеет только c1 в

выражении выделения разделов, попытка добавления уникального ключа на c2 всегда провалится. Однако, Вы можете добавлять уникальный ключ, который использует c1 и c2.

Эти правила также относятся к существующим не разбитым на разделы таблицам, в которых Вы желаете выделить разделы используя ALTER TABLE … PARTITION BY. Рассмотрите таблицу np_pk:

CREATE TABLE np_pk (

id INT NOT NULL AUTO_INCREMENT,

name VARCHAR(50),

added DATE, PRIMARY KEY (id)

);

Следующяя инструкция ALTER TABLE потерпит неудачу с ошибкой, потому что столбец added не является частью любого

уникального ключа в таблице:

ALTER TABLE np_pk PARTITION BY HASH(TO_DAYS(added)) PARTITIONS 4;

Эта инструкция, однако, была бы полностью допустима:

ALTER TABLE np_pk PARTITION BY HASH(id) PARTITIONS 4;

В случае np_pk единственный столбец, который может использоваться как часть выражения выделения разделов, id. Если Вы желаете выделить разделы этой таблицы, использующие любой другой столбец или столбцы в выражении выделения разделов, Вы должны сначала изменить таблицу, добавляя желательный столбец или столбцы на первичный ключ или удаляя первичный ключ в целом.

Подразделы ограничены выделением разделов HASH или KEY. Разделы HASH и KEY не могут быть

подразбиты на разделы.

Глава 4. Пространственные расширения

MySQL поддерживает пространственные расширения, чтобы позволить хранение и анализ географических свойств. Эти свойства доступны для таблиц типов MyISAM, InnoDB, NDB и ARCHIVE. Однако, тип ARCHIVE не поддерживает индексацию, так что пространственные столбцы в столбцах ARCHIVE не могут быть индексированы. MySQL Cluster также не поддерживает индексацию пространственных столбцов.

Хотя пространственные расширения обеспечиваются в таблицах InnoDB, использование пространственных индексов может вызывать аварийный отказ ().

Эта глава покрывает следующие темы:

Основание этих пространственных расширений в модели геометрии OpenGIS.

Форматы для представления пространственных данных.

Как использовать пространственные данные в MySQL.

Использование индексации для пространственных данных.

Отличия MySQL от спецификации OpenGIS.

Дополнительные ресурсы

Open Geospatial Consortium издает OpenGIS Simple Features Specifications For SQL, документ, который предлагает несколько концептуальных способов для распространения SQL RDBMS, чтобы поддерживать пространственные данные. Эта спецификация доступна на .

Если Вы имеете вопросы или интересы относительно использования пространственных расширений MySQL, Вы можете обсуждать их на форуме GIS: .

4.1. Введение в пространственную поддержку MySQL

MySQL осуществляет пространственные расширения по спецификации Open Geospatial Consortium (OGC). Это международный консорциум более, чем 250 компаний, агентств и университетов, участвующих в разработке публично доступных концептуальных решений, которые могут быть полезны со всеми видами прикладных программ, которые управляют пространственными данными. OGC поддерживает Web-сайт .

В 1997 Open Geospatial Consortium опубликовал OpenGIS Simple Features Specifications For SQL. Эта спецификация доступна на .

MySQL осуществляет подмножество типов SQL with Geometry Types, среду, предложенную OGC. Этот термин относится к SQL-среде, которая была расширена с набором типов геометрии. Оцененный геометрией SQL столбец выполнен как столбец, который имеет тип геометрии. Спецификация описывает набор SQL-типов геометрии также, как функций на этих типах, чтобы создавать и анализировать значения геометрии.

Географическее свойство состоит в том, что есть что-нибудь в мире, имеющее расположение. Свойство может быть:

Объект. Например, гора, водоем, город.

Пустота. Например, область почтового индекса, тропики.

Определимое расположение. Например, дорога, как специфическое место, где два прохода пересекаются.

Некоторые документы используют термин geospatial feature, чтобы обратиться к географическим свойствам.

Geometry другое слово, которое обозначает географическее свойство. Первоначально геометрия означала измерение земли. Другое значение исходит от картографии, оно касается геометрических свойств, которые картографы используют, чтобы отобразить мир.

Эта глава использует все эти условия синонимично: geographic feature, geospatial feature, feature или geometry. Обычно используется геометрия, определенная как отметка или набор пунктов (точек), представляющих что-нибудь в мире, что имеет расположение.

4.2. Модель геометрии OpenGIS

Набор типов геометрии, предложенных окружением OGC SQL with Geometry Types основан на OpenGIS Geometry Model. В этой модели каждый геометрический объект имеет следующие общие реквизиты:

Это связано с пространственной системой ссылки, которая описывает координаты места, в котором объект определен.

Это принадлежит некоторому классу геометрии.

4.2.1. Иерархия класса геометрии

Классы геометрии определяют свою иерархию следующим образом:

Geometry (non-instantiable)

Point (instantiable)

Curve (non-instantiable)

LineString (instantiable)

Line

LinearRing

Surface (non-instantiable)

Polygon (instantiable)

GeometryCollection (instantiable)

MultiPoint (instantiable)

MultiCurve (non-instantiable)

MultiLineString (instantiable)

MultiSurface (non-instantiable)

MultiPolygon (instantiable)

Невозможно создать объекты в non-instantiable классах. Возможно создать объекты в классах instantiable. Все классы имеют реквизиты, и классы instantiable могут также иметь утверждения (правила, которые определяют допустимые образцы класса).

Geometry базовый класс. Это абстрактный класс. Подклассы Geometry ограничены нуль-, одно- и двумерными геометрическими объектами, которые существуют в двумерном координатном пространстве. Все instantiable классы геометрии определены так, чтобы допустимые образцы класса были закрытой топологии (то есть, все определенные конфигурации включают их границу).

Основной класс Geometry имеет подклассы для Point, Curve, Surface и GeometryCollection:

Point представляет нуль-мерные объекты.

Curve представляет одномерные объекты и имеет подкласс LineString с под-подклассами Line и LinearRing.

Surface разработан для двумерных объектов и имеет подкласс Polygon.

GeometryCollection имеет специальные коллекции для нуль-, одно- и двумерных объектов, известные как MultiPoint, MultiLineString и MultiPolygon для конфигураций моделирования, соответствующих совокупностям Points, LineStrings и Polygons, соответственно. MultiCurve и MultiSurface представляются как абстрактные суперклассы, которые обобщают интерфейсы совокупности, чтобы обработать Curves и Surfaces.

Geometry, Curve, Surface, MultiCurve и MultiSurface определены как non-instantiable классы. Они определяют общий набор методов для их подклассов и включены для расширяемости.

Point, LineString, Polygon, GeometryCollection, MultiPoint, MultiLineString и MultiPolygon instantiable классы.

4.2.2. Класс Geometry

Geometry представляет собой корневой класс иерархии. Это non-instantiable класс, но имеет ряд реквизитов, которые являются общими для всех значении геометрии, созданных любым из подклассов Geometry. Эти реквизиты описаны в следующем списке. Специфические подклассы имеют их собственные специфические реквизиты, описанные позже.

Реквизиты геометрии

Значение геометрии имеет следующие реквизиты:

type. Каждая геометрия принадлежит одному из instantiable классов в иерархии.

SRID или Spatial Reference Identifier (пространственный идентификатор ссылки). Это значение идентифицирует связанную пространственную систему ссылки геометрии, которая описывает координатное пространство, в котором объект геометрии определен. В MySQL значение SRID только целое число, связанное со значением геометрии. Все вычисления выполнены, принимая Евклидову (плоскую) геометрию.

Координата в пространственной системе ссылки, представляемая как числа двойной точности (с восьмью байтами). Все не пустые конфигурации включают по крайней мере одну пару координат (X,Y). Пустые конфигурации не содержат никаких координат.

Координаты связаны со SRID. Например, в различных системах координат расстояние между двумя объектами может отличаться даже, когда объекты имеют те же самые координаты потому, что расстояние на плоской системе координат и расстояния на геоцентрической системе (на поверхности Земли) разные вещи.

Внутренний, граничный и внешний.

Каждая геометрия занимает некоторую позицию. Внешнее, с точки зрения геометрии, это все место, не занятое геометрией. Внутреннее, соответственно, место, занятое геометрией. Граница находится между внутренним и внешним.

MBR (Minimum Bounding Rectangle) или Envelope (минимальный ограничительный прямоугольник, конверт). Это геометрия ограничения, сформированная минимумом и максимумом (X,Y):((MINX MINY, MAXX MINY, MAXX MAXY, MINX MAXY, MINX MINY))

Является ли значение простым или нет. Значения геометрии типов (LineString, MultiPoint, MultiLineString) являются простыми или не простыми. Каждый тип определяет собственные утверждения, будучи простым или не простым.

Закрыто ли значение или нет. Значения геометрии типов (LineString, MultiString) закрыты или не закрыты. Каждый тип определяет собственные утверждения.

Является ли значение пустым или не пустым: геометрия пуста, если не имеет никаких точек. Внешний, внутренний и граница пустой геометрии не определены (то есть они представляются значением NULL). Пустая геометрия определена, чтобы быть всегда простой и имеет область 0.

Размерность. Геометрия может иметь размерность 0, 1 или 2:

0 для геометрии без длины и никакой области.

1 для геометрии с ненулевой длиной и нулевой областью, а также для пустой геометрии.

2 для геометрии с ненулевой областью.

Объекты Point имеют размерность 0. Объекты LineString имеют размерность 1. Объекты Polygon имеют размерность 2. Размерности объектов MultiPoint, MultiLineString и MultiPolygon такие же, как размерности тех элементов, из которых они состоят.

4.2.3. Класс Point

Point геометрия, которая представляет одиночное расположение в координатном пространстве.

Примеры Point

Вообразите крупномасштабную карту мира с многими городами. Объект Point мог бы представлять каждый город.

На городской карте объект Point мог бы представлять автобусную остановку (Stylus советует "bus stop" писать как "останов шины", зараза с русскими программистами).

Свойства Point

Значение X.

Значение Y.

Point определена как нуль-мерная геометрия.

Границей Point является пустой набор.

4.2.4. Класс Curve

Curve одномерная геометрия, обычно представляемая последовательностью точек. Специфические подклассы Curve определяют тип интерполяции между пунктами (точками). Curve non-instantiable.

Свойства Curve

Curve имеет координаты пунктов.

Curve определена как одномерная геометрия.

Curve проста, если не проходит через ту же самую отметку дважды.

Curve закрыта, если отметка начала равна оконечной точке.

Граница закрытой Curve пуста.

Граница не закрытой Curve состоит из двух оконечных точек.

Curve, которая является простой и закрытой, LinearRing.

4.2.5. Класс LineString

LineString это Curve с линейной интерполяцией между пунктами (точками).

Примеры LineString:

На всемирной карте объекты LineString могли бы представлять реки.

В городской карте объекты LineString могли бы представлять любые проходы.

Свойства LineString

LineString имеет координаты сегментов, определенных каждой последовательной парой пунктов.

LineString является Line, если это состоит из точно двух пунктов.

LineString является LinearRing, если закрыта и проста.

4.2.6. Класс Surface

Surface двумерная геометрия. Это non-instantiable класс. Есть instantiable подкласс: Polygon.

Свойства Surface

Surface определен как двумерная геометрия.

OpenGIS определяет простой Surface как геометрию, которая состоит из одиночной заплаты, связанной с одной внешней границей и нулем или более внутренними границами.

Граница простого Surface представляет собой набор закрытых кривых, соответствующих внешним и внутренним границам.

4.2.7. Класс Polygon

Polygon плоский вариант Surface, представляющий многостороннюю геометрию. Это определено одиночной внешней границей и нулем или более внутренними границами, где каждая внутренняя граница определяет отверстие в Polygon.

Пример Polygon.

На карте области объекты Polygon могли бы представлять леса, районы и так далее.

Утверждения Polygon.

Граница Polygon состоит из набора объектов LinearRing (то есть, объектов LineString, которые являются простыми и закрытыми), которые составляют внешние и внутренние границы.

Polygon не имеет никаких пересечений. Кольца в границе Polygon могут пересекаться в Point, но только как тангенс.

Polygon не имеет никаких строк, выбросов или проколов.

Polygon имеет внутреннюю структуру, которая является связанным набором отметок.

Polygon может иметь отверстия. Внешний Polygon с отверстиями не связан. Каждое отверстие определяет связанный компонент внешних.

Предшествующие утверждения делают Polygon простой геометрией.

4.2.8. Класс GeometryCollection

GeometryCollection геометрия, которая является совокупностью одной или большего количества конфигураций любого класса.

Все элементы в GeometryCollection должны быть в той же самой пространственной системе ссылки (то есть, в той же самой системе координат). Не имеется никаких других ограничений на элементы GeometryCollection, хотя подклассы GeometryCollection, описанных в следующих разделах могут ограничивать членство. Ограничения могут быть основаны на:

Тип элемента (например, MultiPoint может содержать только элементы Point).

Размерность.

Ограничения на степень пространственного перекрытия между элементами.

4.2.9. Класс MultiPoint

MultiPoint совокупность геометрии, составленная из элементов Point. Пункты (точки) всегда не связаны или упорядочены.

Примеры MultiPoint:

На всемирной карте MultiPoint мог бы представлять цепочку маленьких изолированных островов.

На городской карте MultiPoint мог бы представлять выходы.

Свойства MultiPoint

MultiPoint нульмерная геометрия.

MultiPoint прост, если никакие два из значений Point не равны (имеют идентичные координатные значения).

Граница MultiPoint пустой набор.

4.2.10. Класс MultiCurve

MultiCurve совокупность геометрии, составленная из элементов Curve. MultiCurve non-instantiable класс.

Свойства MultiCurve

MultiCurve одномерная геометрия.

MultiCurve проста, если (и только если) все элементы просты. Единственные пересечения между любыми двумя элементами происходят в пунктах (точках), которые находятся на границах обоих элементов.

Граница MultiCurve получена, применяя правило mod 2 union (также известно как правило odd-even): точка находится в границе MultiCurve, если она находится в границах нечетного числа элементов MultiCurve.

MultiCurve закрыта, если все элементы закрыты.

Граница закрытой MultiCurve всегда пуста.

4.2.11. Класс MultiLineString

MultiLineString совокупность геометрии MultiCurve, составленная из элементов LineString.

Примеры MultiLineString

На карте области MultiLineString мог бы представлять систему рек или систему дорог.

4.2.12. Класс MultiSurface

MultiSurface совокупность геометрии, составленная из поверхностных элементов. MultiSurface non-instantiable класс. Есть только instantiable подкласс MultiPolygon.

Утверждения MultiSurface

Две поверхности MultiSurface не имеют никаких внутренностей, которые пересекаются.

Два элемента MultiSurface имеют границы, которые пересекаются в конечном числе пунктов (точек).

4.2.13. Класс MultiPolygon

MultiPolygon объект MultiSurface, составленный из элементов Polygon.

Примеры MultiPolygon

На карте области MultiPolygon мог бы представлять систему озер.

Утверждения MultiPolygon

MultiPolygon не имеет никаких двух элементов Polygon с внутренностями, которые пересекаются.

MultiPolygon не имеет никаких двух элементов Polygon, которые пересекаются (пересечение также запрещается предыдущим утверждением), или же касаются в бесконечном числе (точек).

MultiPolygon, возможно, имеет вырезы, выбросы или проколы. MultiPolygon регулярен, закрытый набор отметок.

MultiPolygon, который имеет больше чем один Polygon, имеет внутренности, которые не связаны. Число связанных внутренних компонентов MultiPolygon равно числу значений Polygon в MultiPolygon.

Свойства MultiPolygon

MultiPolygon двумерная геометрия.

Граница MultiPolygon набор закрытых кривых (значения LineString), соответствующих границам элементов Polygon.

Каждая Curve в границе MultiPolygon находится в границе точно одного элемента Polygon.

Каждая Curve в границе элемента Polygon находится в границе MultiPolygon.

4.3. Обеспечиваемые пространственные форматы данных

Этот раздел описывает стандартные пространственные форматы данных, которые используются, чтобы представить объекты геометрии в запросах. Это:

Well-Known Text (WKT).

Well-Known Binary (WKB).

Внутренне MySQL сохраняет значения геометрии в формате, который не идентичен любому формату WKT или WKB.

4.3.1. Well-Known Text (WKT)

Представление геометрии Well-Known Text (WKT) разработано, чтобы обмениваться данными геометрии в форме ASCII.

Примеры WKT представлений объектов геометрии:

Point:POINT(15 20)

Обратите внимание, что отметка определена без отделения запятой.

LineString с четырьмя пунктами:LINESTRING(0 0, 10 10, 20 25, 50 60)

Обратите внимание, что пары координат отделяются запятыми.

Polygon с одним внешним кольцом и одним внутренним кольцом:POLYGON((0 0,10 0,10 10,0 10,0 0),(5 5,7 5,7 7,5 7, 5 5))

MultiPoint с тремя значениями Point:MULTIPOINT(0 0, 20 20, 60 60)

MultiLineString с двумя значениями LineString:MULTILINESTRING((10 10, 20 20), (15 15, 30 15))

MultiPolygon с двумя значениями Polygon:MULTIPOLYGON(((0 0,10 0,10 10,0 10,0 0)),((5 5,7 5,7 7,5 7, 5 5)))

GeometryCollection, состоящий из двух значений Point и одного LineString:GEOMETRYCOLLECTION(POINT(10 10), POINT(30 30), LINESTRING(15 15, 20 20))

Грамматика Backus-Naur, которая определяет формальные правила вывода для записи значений WKT, может быть найдена в спецификации OpenGIS.

4.3.2. Well-Known Binary (WKB)

Представление геометрии Well-Known Binary (WKB) определено спецификацией OpenGIS. Это также определено в ISO SQL/MM Part 3: Spatial standard.

WKB используется, чтобы обмениваться данными геометрии как двоичными потоками, представляемыми значениями BLOB, содержащими геометрическую информацию WKB.

WKB использует однобайтовые целые числа без знака, целые числа без знака с четырьмя байтами и числа двойной точности с восемью байтами (IEEE 754). Байт равен восьми битам.

Например, значение WKB, которое соответствует POINT(1 1) состоит из этой последовательности 21 байтов (каждый представляется здесь двумя шестнадцатеричными цифрами):0101000000000000000000F03F000000000000F03F

Последовательность может быть разделена на эти компоненты:Byte order : 01

WKB type : 01000000

X: 000000000000F03F

Y: 000000000000F03F

Представление компонента следующее:

Byte order может быть 0 или 1, чтобы указать little-endian или big-endian формат хранения. little-endian и big-endian также известны как Network Data Representation (NDR) и External Data Representation (XDR), соответственно.

WKB type задает код, который указывает тип геометрии. Значения от 1 до 7 указывают Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon и GeometryCollection.

Значение Point имеет координаты X и Y, каждпя представляемая как значение двойной точности.

WKB-значения для более сложных значений геометрии представляются более сложными структурами данных, как детализировано в спецификации OpenGIS.

4.4. Создание пространственной базы данных MySQL

Этот раздел описывает типы данных, которые Вы можете использовать для представления пространственных данных в MySQL и функции, доступные для создания и поиска пространственных значений.

4.4.1. Пространственные типы данных в MySQL

MySQL имеет типы данных, которые соответствуют классам OpenGIS. Часть этих типов хранит одиночные значения геометрии:

GEOMETRY

POINT

LINESTRING

POLYGON

GEOMETRY может сохранять значения геометрии любого типа. Другие типы с одиночным значением (POINT, LINESTRING и POLYGON) ограничивают их значения специфическим типом геометрии.

Другие типы данных хранят совокупности значений:

MULTIPOINT

MULTILINESTRING

MULTIPOLYGON

GEOMETRYCOLLECTION

GEOMETRYCOLLECTION может сохранять совокупность объектов любого типа. Другие типы совокупности (MULTIPOINT, MULTILINESTRING, MULTIPOLYGON и GEOMETRYCOLLECTION) ограничивают элементы совокупности имеющими специфический тип геометрии.

4.4.2. Создание пространственных значений

Этот раздел описывает, как создать пространственные значения, использующие функции Well-Known Text и Well-Known Binary, которые определены в стандарте OpenGIS, и применить MySQL-функции.

4.4.2.1. Создание значений геометрии через функции WKT

MySQL обеспечивает ряд функций, которые берут как входные параметры представление Well-Known Text и, факультативно, пространственный идентификатор системы ссылки (SRID). Они возвращают соответствующую геометрию.

GeomFromText() принимает WKT любого типа геометрии как первый параметр. Реализация также обеспечивает специфические для типа функции для конструкции значений геометрии каждого типа.

GeomCollFromText(wkt[,srid]), GeometryCollectionFromText(wkt[,srid])

Создает значение GEOMETRYCOLLECTION, использующее WKT представление и SRID.

GeomFromText(wkt[,srid]), GeometryFromText(wkt[,srid])

Создает значение геометрии из любого типа, использующего WKT представление и SRID.

LineFromText(wkt[,srid]), LineStringFromText(wkt[,srid])

Создает значение LINESTRING, использующее WKT представление и SRID.

MLineFromText(wkt[,srid]), MultiLineStringFromText(wkt[,srid])

Создает значение MULTILINESTRING, использующее WKT представление и SRID.

MPointFromText(wkt[,srid]), MultiPointFromText(wkt[,srid])

Создает значение MULTIPOINT, использующее WKT представление и SRID.

MPolyFromText(wkt[,srid]), MultiPolygonFromText(wkt[,srid])

Создает значение MULTIPOLYGON, использующее WKT представление и SRID.

PointFromText(wkt[,srid])

Создает значение POINT, использующее WKT представление и SRID.

PolyFromText(wkt[,srid]), PolygonFromText(wkt[,srid])

Создает значение POLYGON, использующее WKT представление и SRID.

Спецификация OpenGIS также определяет следующие факультативные функции, которые MySQL не выполняет. Эти функции создают значения Polygon или MultiPolygon, основанные на WKT представлении совокупности колец или закрытых значений LineString. Эти значения могут пересекаться.

BdMPolyFromText(wkt,srid)

Создает значение MultiPolygon из MultiLineString в формате WKT, содержащем произвольную совокупность закрытых значений LineString.

BdPolyFromText(wkt,srid)

Создает значение Polygon из MultiLineString в формате WKT, содержащем произвольную совокупность закрытых значенийLineString.

4.4.2.2. Создание значенией геометрии с помощью функций WKB

MySQL обеспечивает ряд функций, которые берут как входные параметры BLOB, содержащий представление Well-Known Binary и, факультативно, пространственный идентификатор системы ссылки (SRID). Они возвращают соответствующую геометрию.

GeomFromWKB() принимает WKB любого типа геометрии как первый параметр. Реализация также обеспечивает специфические для типа функции для конструкции значений геометрии каждого типа геометрии.

GeomCollFromWKB(wkb[,srid]), GeometryCollectionFromWKB(wkb[,srid])

Создает значение GEOMETRYCOLLECTION, использующее WKB представление и SRID.

GeomFromWKB(wkb[,srid]), GeometryFromWKB(wkb[,srid])

Создает значение геометрии из любого типа, использующего WKB представление и SRID.

LineFromWKB(wkb[,srid]), LineStringFromWKB(wkb[,srid])

Создает значение LINESTRING, использующее WKB представление и SRID.

MLineFromWKB(wkb[,srid]), MultiLineStringFromWKB(wkb[,srid])

Создает значение MULTILINESTRING, использующее WKB представление и SRID.

MPointFromWKB(wkb[,srid]), MultiPointFromWKB(wkb[,srid])

Создает значение MULTIPOINT, использующее WKB представление и SRID.

MPolyFromWKB(wkb[,srid]), MultiPolygonFromWKB(wkb[,srid])

Создает значение MULTIPOLYGON, использующее WKB представление и SRID.

PointFromWKB(wkb[,srid])

Создает значение POINT, использующее WKB представление и SRID.

PolyFromWKB(wkb[,srid]), PolygonFromWKB(wkb[,srid])

Создает значение POLYGON, использующее WKB представление и SRID.

Спецификация OpenGIS также описывает факультативные функции для построения значений Polygon или MultiPolygon, основанных на WKB представлении совокупности колец или закрытых значений LineString. Эти значения могут пересекаться. MySQL не выполняет эти функции:

BdMPolyFromWKB(wkb,srid)

Создает значение MultiPolygon из значения MultiLineString в формате WKB, содержащем произвольную совокупность закрытых значений LineString.

BdPolyFromWKB(wkb,srid)

Создает значение Polygon из значения MultiLineString в формате WKB, содержащем произвольную совокупность закрытых значений LineString.

4.4.2.3. Создание геометрии с использованием MySQL-специфических функций

MySQL обеспечивает набор полезных ненормативных функций для создания геометрии с WKB представлениями. Функции, описанные в этом разделе, MySQL-расширения спецификации OpenGIS. Результатами этих функций будут значения BLOB, содержащие WKB-представления значений геометрии без SRID. Результаты этих функций могут заменяться как первый параметр любой функции в функциональном семействе GeomFromWKB().

GeometryCollection(g1,g2,…)

Создает значение WKB GeometryCollection. Если параметры не задают правильно построенное WKB представление геометрии, возвращаемое значение NULL.

LineString(pt1,pt2,…)

Создает значение WKB LineString из ряда WKB параметров Point. Если любой аргумент не задает правильный WKB Point, вернется NULL. Если число параметров Point меньше чем два, возвращаемое значение NULL.

MultiLineString(ls1,ls2,…)

Создает значение WKB MultiLineString, использующее WKB параметры LineString. Если любой параметр не WKB LineString, возвращаемое значение NULL.

MultiPoint(pt1,pt2,…)

Создает значение WKB MultiPoint, использующее WKB параметры Point. Если любой параметр не WKB Point, возвращаемое значение NULL.

MultiPolygon(poly1,poly2,…)

Создает значение WKB MultiPolygon из набора WKB параметров Polygon. Если любой параметр не WKB Polygon, возвращаемое значение NULL.

Point(x,y)

Создает значение WKB Point, используя координаты.

Polygon(ls1,ls2,…)

Создает значение WKB Polygon из ряда WKB параметров LineString. Если любой параметр не представляет WKB LinearRing (то есть не закрытый и простой LineString), возвращаемое значение NULL.

4.4.3. Создание пространственных столбцов

MySQL обеспечивает стандартный способ создания пространственных столбцов для типов геометрии, например, через CREATE TABLE или ALTER TABLE. В настоящее время пространственные столбцы обеспечиваются для таблиц типов MyISAM, InnoDB, NDB и ARCHIVE.

Используйте инструкцию CREATE TABLE, чтобы создать таблицу с пространственным столбцом:CREATE TABLE geom (g GEOMETRY);

Используйте инструкцию ALTER TABLE, чтобы добавлять или удалять пространственный столбец в существующей таблице:ALTER TABLE geom ADD pt POINT;

ALTER TABLE geom DROP pt;

4.4.4. Начальная загрузка пространственных столбцов

После того, как Вы создали пространственные столбцы, Вы можете заполнять их пространственными данными.

Значения должны быть сохранены во внутреннем формате геометрии, но Вы можете преобразовывать их в этот формат из Well-Known Text (WKT) или из Well-Known Binary (WKB). Следующие примеры показывают, как вставить значения геометрии в таблицу, преобразуя значения WKT во внутренний формат геометрии:

Выполните преобразование непосредственно в инструкции INSERT:INSERT INTO geom VALUES (GeomFromText('POINT(1 1)'));

SET @g = 'POINT(1 1)';

INSERT INTO geom VALUES (GeomFromText(@g));

Выполните преобразование до INSERT:SET @g = GeomFromText('POINT(1 1)');

INSERT INTO geom VALUES (@g);

Следующие примеры вставляют более сложные конфигурации в таблицу:SET @g = 'LINESTRING(0 0,1 1,2 2)';

INSERT INTO geom VALUES (GeomFromText(@g));

SET @g = 'POLYGON((0 0,10 0,10 10,0 10,0 0),(5 5,7 5,7 7,5 7, 5 5))';

INSERT INTO geom VALUES (GeomFromText(@g));

SET @g = 'GEOMETRYCOLLECTION(POINT(1 1),LINESTRING(0 0,1 1,2 2,3 3,4 4))';

INSERT INTO geom VALUES (GeomFromText(@g));

Предшествующие примеры применяют GeomFromText(), чтобы создать значения геометрии. Вы можете также использовать специфические для типа функции:SET @g = 'POINT(1 1)';

INSERT INTO geom VALUES (PointFromText(@g));

SET @g = 'LINESTRING(0 0,1 1,2 2)';

INSERT INTO geom VALUES (LineStringFromText(@g));

SET @g = 'POLYGON((0 0,10 0,10 10,0 10,0 0),(5 5,7 5,7 7,5 7, 5 5))';

INSERT INTO geom VALUES (PolygonFromText(@g));

SET @g = 'GEOMETRYCOLLECTION(POINT(1 1),LINESTRING(0 0,1 1,2 2,3 3,4 4))';

INSERT INTO geom VALUES (GeomCollFromText(@g));

Обратите внимание, что, если прикладная программа пользователя хочет использовать WKB-представления значений геометрии, она ответственна за посылку правильно сформированных WKB в запросах на сервер. Однако, имеются несколько способов удовлетворения этого требования. Например:

Вставка значения POINT(1 1) с шестнадцатеричным литеральным синтаксисом:mysql> INSERT INTO geom VALUES

– > (GeomFromWKB(0x0101000000000000000000F03F000000000000F03F));

ODBC-прикладная программа может посылать WKB-представление, привязывая его к метке-заполнителю, использующей параметр типа BLOB:INSERT INTO geom VALUES (GeomFromWKB(?))

Другие интерфейсы программирования могут поддерживать подобный механизм метки-заполнителя.

В программе на C Вы можете выходить из двоичного значения, используя mysql_real_escape_string() и включать результат в строку запроса, которая послана серверу.

4.4.5. Выборка пространственных данных

Значения геометрии, сохраненные в таблице, могут быть выбраны во внутреннем формате. Вы можете также преобразовывать их в формат WKT или WKB.

Выборка пространственных данных во внутреннем формате:

Выборка геометрии с использованием внутреннего формата, может быть полезна в передачах из таблицы в таблицу:CREATE TABLE geom2 (g GEOMETRY) SELECT g FROM geom;

Выборка пространственных данных в формате WKT:

Функция AsText() преобразовывает геометрию из внутреннего формата в строку WKT.SELECT AsText(g) FROM geom;

Выборка пространственных данных в формате WKB:

Функция AsBinary() преобразовывает геометрию из внутреннего формата в BLOB WKB.SELECT AsBinary(g) FROM geom;

4.5. Анализ пространственной информации

После начальной загрузки пространственных столбцов со значениями, Вы готовы сделать запрос и анализировать их. MySQL обеспечивает набор функций, чтобы выполнить различные операции на пространственных данных. Эти функции могут быть сгруппированы в четыре главных категории согласно типу операции, которую они выполняют:

Функции, которые преобразовывают конфигурации между различными форматами.

Функции, которые обеспечивают доступ к качественным или количественным реквизитам геометрии.

Функции, которые описывают отношения между двумя конфигурациями.

Функции, которые создают новые конфигурации из существующих.

Пространственные функции анализа могут использоваться во многих контекстах, типа:

Любая интерактивная программа SQL, типа mysql или MySQL Query Browser.

Прикладные программы, написанные на любом языке, который поддерживает клиентский MySQL API.

4.5.1. Функции преобразования формата геометрии

MySQL поддерживает следующие функции для преобразования значений геометрии между внутренним форматом и форматом WKT или WKB:

AsBinary(g)

Преобразовывает значение во внутреннем формате геометрии к представлению WKB и возвращает двоичный результат.SELECT AsBinary(g) FROM geom;

AsText(g)

Преобразовывает значение во внутреннем формате геометрии к представлению WKT и возвращает строковый результат.mysql> SET @g = 'LineString(1 1,2 2,3 3)';

mysql> SELECT AsText(GeomFromText(@g));

+--------------------------+

| AsText(GeomFromText(@g)) |

+--------------------------+

| LINESTRING(1 1,2 2,3 3) |

+--------------------------+

GeomFromText(wkt[,srid])

Преобразовывает строковое значение из WKT-представления во внутренний формат геометрии и возвращает результат. Ряд специфических для типа функций также обеспечивается, типа PointFromText() и LineFromText().

GeomFromWKB(wkb[,srid])

Преобразовывает двоичное значение из WKB-представления во внутренний формат геометрии и возвращает результат. Ряд специфических для типа функций также обеспечивается, типа PointFromWKB() и LineFromWKB().

Функции 4.5.2. Geometry

Каждая функция, которая принадлежит к этой группе, берет значение геометрии как параметр и возвращает некоторое количественное или качественное свойство геометрии. Некоторые функции ограничивают их тип параметра. Такие функции возвращают NULL, если параметр имеет неправильный тип геометрии. Например, Area() возвращает NULL, если тип объекта не является ни Polygon, ни MultiPolygon.

4.5.2.1. Общие функции геометрии

Функции, перечисленные в этом разделе, не ограничивают их параметр и принимают значение геометрии любого типа.

Dimension(g)

Возвращается свойственная размерность геометрии g. Результат может быть 0, 1 или 2. Смысл этих значений дан в разделе "".mysql> SELECT Dimension(GeomFromText('LineString(1 1,2 2)'));

+------------------------------------------------+

| Dimension(GeomFromText('LineString(1 1,2 2)')) |

+------------------------------------------------+

| 1 |

+------------------------------------------------+

Envelope(g)

Возвращается минимальный ограничительный прямоугольник (MBR) для геометрии g. Результат возвращен как значение Polygon.

Многоугольник определен пунктами (точками) угла блока ограничения:POLYGON((MINX MINY, MAXX MINY, MAXX MAXY, MINX MAXY, MINX MINY))

mysql> SELECT AsText(Envelope(GeomFromText('LineString(1 1,2 2)')));

+-------------------------------------------------------+

| AsText(Envelope(GeomFromText('LineString(1 1,2 2)'))) |

+-------------------------------------------------------+

| POLYGON((1 1,2 1,2 2,1 2,1 1)) |

+-------------------------------------------------------+

GeometryType(g)

Возвращает как строку имя типа геометрии, образец которой является членом g. Имя соответствует одному из instantiable подклассов Geometry.mysql> SELECT GeometryType(GeomFromText('POINT(1 1)'));

+------------------------------------------+

| GeometryType(GeomFromText('POINT(1 1)')) |

+------------------------------------------+

| POINT |

+------------------------------------------+

SRID(g)

Возвращается целое число, указывающее пространственный ID системы ссылки для геометрии g.

В MySQL значение SRID только целое число, связанное со значением геометрии. Все вычисления выполнены, принимая евклидову (плоскую) геометрию. mysql> SELECT SRID(GeomFromText('LineString(1 1,2 2)',101));

+-----------------------------------------------+

| SRID(GeomFromText('LineString(1 1,2 2)',101)) |

+-----------------------------------------------+

| 101 |

+-----------------------------------------------+

Спецификация OpenGIS также определяет следующие функции, которые MySQL не выполняет:

Boundary(g)

Возвращает геометрию, которая является замкнутым выражением комбинаторной границы геометрии g.

IsEmpty(g)

Возвращается 1, если геометрия g пустая геометрия, 0, если это не пусто, и 1, если параметр NULL. Если геометрия пуста, это представляет пустой набор точек.

IsSimple(g)

В настоящее время эта функция не должна использоваться. Если выполнено, поведение будет как описано в следующем параграфе.

Возвращается 1, если геометрия g не имеет никаких аномальных геометрических пунктов (точек), типа самопересечения или самокасания. IsSimple() возвращает 0, если параметр не прост, и 1, если он NULL.

Описание каждого instantiable геометрического класса, данного ранее в главе включает специфические условия, которые заставляют образец того класса быть классифицированными как не простой.

4.5.2.2. Функции Point

Point состоит из координат X и Y, которые могут быть получены, используя следующие функции:

X(p)

Возвращает значение X-координаты для p как число двойной точности.mysql> SET @pt = 'Point(56.7 53.34)';

mysql> SELECT X(GeomFromText(@pt));

+----------------------+

| X(GeomFromText(@pt)) |

+----------------------+

| 56.7 |

+----------------------+

Y(p)

Возвращает значение Y-координаты для p как число двойной точности.mysql> SET @pt = 'Point(56.7 53.34)';

mysql> SELECT Y(GeomFromText(@pt));

+----------------------+

| Y(GeomFromText(@pt)) |

+----------------------+

| 53.34 |

+----------------------+

4.5.2.3. Функции LineString

LineString состоит из значений Point. Вы можете извлекать специфические пункты (точки) LineString, считать число точек объекта или получать длину.

EndPoint(ls)

Возвращает Point, которая является оконечной точкой значения LineString ls.mysql> SET @ls = 'LineString(1 1,2 2,3 3)';

mysql> SELECT AsText(EndPoint(GeomFromText(@ls)));

+-------------------------------------+

| AsText(EndPoint(GeomFromText(@ls))) |

+-------------------------------------+

| POINT(3 3) |

+-------------------------------------+

GLength(ls)

Возвращает как число двойной точности длина значение LineString ls в связанной пространственной ссылке.mysql> SET @ls = 'LineString(1 1,2 2,3 3)';

mysql> SELECT GLength(GeomFromText(@ls));

+----------------------------+

| GLength(GeomFromText(@ls)) |

+----------------------------+

| 2.8284271247462 |

+----------------------------+

GLength() ненормативное имя. Это передает данные функции OpenGIS Length().

NumPoints(ls)

Возвращает число объектов Point в the LineString ls.mysql> SET @ls = 'LineString(1 1,2 2,3 3)';

mysql> SELECT NumPoints(GeomFromText(@ls));

+------------------------------+

| NumPoints(GeomFromText(@ls)) |

+------------------------------+

| 3 |

+------------------------------+

PointN(ls,N)

Возвращает N-ый Point в Linestring ls. Точки пронумерованы, начиная с 1.mysql> SET @ls = 'LineString(1 1,2 2,3 3)';

mysql> SELECT AsText(PointN(GeomFromText(@ls),2));

+-------------------------------------+

| AsText(PointN(GeomFromText(@ls),2)) |

+-------------------------------------+

| POINT(2 2) |

+-------------------------------------+

StartPoint(ls)

Возвращает Point, которая является отметкой начала значения point of the LineString ls.mysql> SET @ls = 'LineString(1 1,2 2,3 3)';

mysql> SELECT AsText(StartPoint(GeomFromText(@ls)));

+---------------------------------------+

| AsText(StartPoint(GeomFromText(@ls))) |

+---------------------------------------+

| POINT(1 1) |

+---------------------------------------+

Спецификация OpenGIS также определяет следующую функцию, которую MySQL не выполняет:

IsRing(ls)

Возвращает 1, если значение LineString value ls закрыто (то есть, значения StartPoint() и EndPoint() те же самые) и просто (не проходит через ту же самую точку больше, чем один раз). Возвращается 0, если ls не кольцо, и 1, если это NULL.

4.5.2.4. Функции MultiLineString

GLength(mls)

Возвращает как число двойной точности длину значения MultiLineString mls. Длина mls равна сумме длин элементов.mysql> SET @mls = 'MultiLineString((1 1,2 2,3 3),(4 4,5 5))';

mysql> SELECT GLength(GeomFromText(@mls));

+-----------------------------+

| GLength(GeomFromText(@mls)) |

+-----------------------------+

| 4.2426406871193 |

+-----------------------------+

GLength() ненормативное имя. Это передает данные функции OpenGIS Length().

IsClosed(mls)

Возвращает 1, если значение MultiLineString mls закрыто (то есть, значения StartPoint() и EndPoint() равны для каждого LineString в mls). Возвращает 0, если mls не закрыт, и 1, если это NULL.mysql> SET @mls = 'MultiLineString((1 1,2 2,3 3),(4 4,5 5))';

mysql> SELECT IsClosed(GeomFromText(@mls));

+------------------------------+

| IsClosed(GeomFromText(@mls)) |

+------------------------------+

| 0 |

+------------------------------+

4.5.2.5. Функции Polygon

Area(poly)

Возвращает как число двойной точности область значения Polygon poly, как измеряется в пространственной системе ссылки.mysql> SET @poly = 'Polygon((0 0,0 3,3 0,0 0),(1 1,1 2,2 1,1 1))';

mysql> SELECT Area(GeomFromText(@poly));

+---------------------------+

| Area(GeomFromText(@poly)) |

+---------------------------+

| 4 |

+---------------------------+

ExteriorRing(poly)

Возвращает внешнее кольцо значения Polygon poly как LineString.mysql> SET @poly = 'Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))';

mysql> SELECT AsText(ExteriorRing(GeomFromText(@poly)));

+-------------------------------------------+

| AsText(ExteriorRing(GeomFromText(@poly))) |

+-------------------------------------------+

| LINESTRING(0 0,0 3,3 3,3 0,0 0) |

+-------------------------------------------+

InteriorRingN(poly,N)

Возвращает N-ное внутреннее кольцо для значения Polygon poly как LineString. Кольца пронумерованы, начиная с 1.mysql> SET @poly =

– > 'Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))';

mysql> SELECT AsText(InteriorRingN(GeomFromText(@poly),1));

+----------------------------------------------+

| AsText(InteriorRingN(GeomFromText(@poly),1)) |

+----------------------------------------------+

| LINESTRING(1 1,1 2,2 2,2 1,1 1) |

+----------------------------------------------+

NumInteriorRings(poly)

Возвращает число внутренних колец в значении Polygon poly.mysql> SET @poly =

– > 'Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))';

mysql> SELECT NumInteriorRings(GeomFromText(@poly));

+---------------------------------------+

| NumInteriorRings(GeomFromText(@poly)) |

+---------------------------------------+

| 1 |

+---------------------------------------+

4.5.2.6. Функции MultiPolygon

Area(mpoly)

Возвращает как число двойной точности область значения MultiPolygon mpoly, как измеряется в пространственной системе ссылки.mysql> SET @mpoly =

– > 'MultiPolygon(((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1)))';

mysql> SELECT Area(GeomFromText(@mpoly));

+----------------------------+

| Area(GeomFromText(@mpoly)) |

+----------------------------+

| 8 |

+----------------------------+

Спецификация OpenGIS также определяет следующие функции, которые MySQL не выполняет:

Centroid(mpoly)

Возвращает математический центр для значения MultiPolygon mpoly как Point. Не гарантируется, что результат будет в MultiPolygon.

PointOnSurface(mpoly)

Возвращает значение Point, которое гарантированно будет в значении MultiPolygon mpoly.

4.5.2.7. Функции GeometryCollection

GeometryN(gc,N)

Возвращает N-ую геометрию в значении GeometryCollection gc. Конфигурации пронумерованы, начиная с 1.mysql> SET @gc = 'GeometryCollection(Point(1 1), LineString(2 2, 3 3))';

mysql> SELECT AsText(GeometryN(GeomFromText(@gc), 1));

+----------------------------------------+

| AsText(GeometryN(GeomFromText(@gc), 1))|

+----------------------------------------+

| POINT(1 1) |

+----------------------------------------+

NumGeometries(gc)

Возвращает число конфигураций в значении GeometryCollection gc.mysql> SET @gc = 'GeometryCollection(Point(1 1), LineString(2 2, 3 3))';

mysql> SELECT NumGeometries(GeomFromText(@gc));

+----------------------------------+

| NumGeometries(GeomFromText(@gc)) |

+----------------------------------+

| 2 |

+----------------------------------+

4.5.3. Функции, которые создают новые конфигурации из существующих

4.5.3.1. Функции геометрии, которые производят новые конфигурации

Раздел " обсуждает несколько функций, которые создают новые конфигурации из существующих.

Envelope(g)

StartPoint(ls)

EndPoint(ls)

PointN(ls,N)

ExteriorRing(poly)

InteriorRingN(poly,N )

GeometryN(gc,N)

4.5.3.2. Пространственные операторы

OpenGIS предлагает ряд других функций, которые могут производить конфигурации. Они разработаны, чтобы выполнить пространственные операторы.

Эти функции не выполнены в MySQL. Они могут появляться в будущих выпусках.

Buffer(g,d)

Возвращает геометрию, которая представляет все пункты (точки), чьи расстояния от геометрии g меньше или равны расстоянию d.

ConvexHull(g)

Возвращает геометрию, которая представляет выпуклую оболочку геометрии g.

Difference(g1,g2)

Возвращает геометрию, которая представляет разность множеств точек значения геометрий g1 и g2.

Intersection(g1,g2)

Возвращает геометрию, которая представляет пересечение набора точек геометрий g1 и g2.

SymDifference(g1,g2)

Возвращает геометрию, которая представляет набор точек, симметричных разнице значений геометрий g1 и g2.

Union(g1,g2)

Возвращает геометрию, которая представляет объединение набора точек значений геометрии g1 и g2.

4.5.4. Функции для тестирования пространственных отношений между геометрическими объектами

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

4.5.5. Отношения на геометрии: минимальные ограничительные прямоугольники (MBR)

MySQL обеспечивает несколько функций, которые проверяют отношения между минимальными ограничительными прямоугольниками двух конфигураций g1 и g2. Возвращаемые значения 1 и 0 указывают истину и ложь соответственно.

MBRContains(g1,g2)

Возвращает 1 или 0, чтобы указать, содержит ли минимальный ограничительный прямоугольник g1 минимальный ограничительный прямоугольник g2.mysql> SET @g1 = GeomFromText('Polygon((0 0, 0 3, 3 3, 3 0, 0 0))');

mysql> SET @g2 = GeomFromText('Point(1 1)');

mysql> SELECT MBRContains(@g1, @g2), MBRContains(@g2, @g1);

+----------------------+----------------------+

| MBRContains(@g1, @g2)| MBRContains(@g2, @g1)|

+----------------------+----------------------+

| 1 | 0 |

+----------------------+----------------------+

MBRDisjoint(g1,g2)

Возвращает 1 или 0, чтобы указать, являются ли минимальные ограничительные прямоугольники двух конфигураций g1 и g2 непересекающимися.

MBREqual(g1,g2)

Возвращает 1 или 0, чтобы указать, являются ли минимальные ограничительные прямоугольники двух конфигураций g1 и g2 тем же самым.

MBRIntersects(g1,g2)

Возвращает 1 или 0, чтобы указать, пересекаются ли минимальные ограничительные прямоугольники двух конфигураций g1 и g2.

MBROverlaps(g1,g2)

Возвращает 1 или 0, чтобы указать, накладываются ли минимальные ограничительные прямоугольники g1 и g2.

MBRTouches(g1,g2)

Возвращает 1 или 0, чтобы указать, касаются ли минимальные ограничительные прямоугольники g1 и g2.

MBRWithin(g1,g2)

Возвращает 1 или 0, чтобы указать, является ли минимальный ограничительный прямоугольник g1 внутренним для минимального ограничительного прямоугольника g2.mysql> SET @g1 = GeomFromText('Polygon((0 0, 0 3, 3 3, 3 0, 0 0))');

mysql> SET @g2 = GeomFromText('Polygon((0 0, 0 5, 5 5, 5 0, 0 0))');

mysql> SELECT MBRWithin(@g1, @g2), MBRWithin(@g2, @g1);

+--------------------+--------------------+

| MBRWithin(@g1, @g2)| MBRWithin(@g2, @g1)|

+--------------------+--------------------+

| 1 | 0 |

+--------------------+--------------------+

4.5.6. Функции, которые проверяют пространственные связи между конфигурациями

Спецификация OpenGIS определяет следующие функции. Они проверяют связь между двумя значениями геометрии g1 и g2.

В настоящее время MySQL не выполняет эти функции согласно спецификации. Которые выполнены, возвратят тот же самый результат, что и соответствующие MBR-функции. Это включает функции в следующем списке. Эти функции могут быть выполнены в будущих выпусках с полной поддержкой для пространственного анализа, а не только MBR-поддержки.

Contains(g1,g2)

Возвращает 1 или 0, чтобы указать, содержит ли g1 полностью g2.

Crosses(g1,g2)

Возвращает 1, если g1 пространственно пересекает g2. Возвращает NULL, если g1 Polygon или MultiPolygon, либо если g2 Point или MultiPoint. Иначе возвращает 0.

Термин "пространственно пересекается", обозначает пространственное отношение между двумя данными конфигурациями, которые имеют следующие реквизиты:

Две конфигурации пересекаются.

Их пересечение приводит к геометрии, которая имеет размерность, которая на единицу меньше, чем максимальная размерность двух данных конфигураций.

Их пересечение не равно любой из двух данных конфигураций.

Disjoint(g1,g2)

Возвращается 1 или 0, чтобы указать, является ли g1 пространственно непересекающейся с g2.

Distance(g1,g2)

Возвращает как число двойной точности самое короткое расстояние между любыми двумя точками в двух конфигурациях.

Equals(g1,g2)

Возвращает 1 или 0, чтобы указать, является ли g1 пространственно равной g2.

Intersects(g1,g2)

Возвращает 1 или 0, чтобы указать, пересекает ли g1 пространственно g2.

Overlaps(g1,g2)

Возвращает 1 или 0, чтобы указать, накладывается ли g1 пространственно на g2. Термин "пространственно накладывается" используется, если две конфигурации пересекаются, и их пересечение приводит к геометрии той же самой размерности, но не равной любой из данных конфигураций.

Related(g1,g2,pattern_matrix )

Возвращает 1 или 0, чтобы указать, существует ли пространственная связь, определенная pattern_matrix между g1 и g2. Возвращает 1, если параметры NULL. Матрица образцов является строкой. Спецификация будет отмечена здесь, если эта функция выполнена.

Touches(g1,g2)

Возвращается 1 или 0, чтобы указать, касается ли g1 пространственно g2. Две конфигурации пространственно касаются, если внутренности конфигураций не пересекаются, но граница одной из конфигураций пересекает границу или внутренность другой.

Within(g1,g2)

Возвращается 1 или 0, чтобы указать, является ли g1 пространственно внутри g2.

4.6. Оптимизация пространственного анализа

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

Запросы точки, которые ищут все объекты, которые содержат данную точку.

Запросы области, которые ищут все объекты, которые накладываются на данную область.

MySQL использует R-деревья с квадратным разбиением, чтобы индексировать пространственные столбцы. Пространственный индекс сформирован, используя MBR геометрии. Для большинства конфигураций MBR минимальный прямоугольник, который окружает конфигурацию. Для горизонтальных или вертикальных linestring MBR прямоугольник, вырождающийся в linestring. Для point MBR является точкой.

Также возможно создать нормальные индексы на пространственных столбцах. Вам надо объявить префикс для любого непространственного индекса на пространственном столбце, кроме столбцов POINT.

4.6.1. Создание пространственных индексов

MySQL может создавать пространственные индексы, использующие синтаксис, подобный аналогичному для создания регулярных индексов, но расширенный с ключевым словом SPATIAL. В настоящее время пространственные столбцы, которые индексированы, должны быть объявлены как NOT NULL. Следующие примеры показывают, как создавать пространственные индексы:

С CREATE TABLE:CREATE TABLE geom (g GEOMETRY NOT NULL, SPATIAL INDEX(g));

С ALTER TABLE:ALTER TABLE geom ADD SPATIAL INDEX(g);

С CREATE INDEX:CREATE SPATIAL INDEX sp_index ON geom (g);

Для таблиц MyISAM SPATIAL INDEX создает индекс R-tree. Для других типов памяти, которые поддерживают пространственную индексацию, SPATIAL INDEX создает индекс B-tree. B-tree на пространственных значениях будет полезен для поисковых таблиц с точным значением, но не для диапазона.

Для удаления пространственного индекса, используйте ALTER TABLE или DROP INDEX:

С ALTER TABLE:ALTER TABLE geom DROP INDEX g;

С DROP INDEX:DROP INDEX sp_index ON geom;

Пример: Предположите, что таблица geom содержит больше, чем 32000 конфигурации, которые сохранены в столбце g типа GEOMETRY. Таблица также имеет столбец AUTO_INCREMENT fid для сохранения значений объекта ID.mysql> DESCRIBE geom;

+-------+----------+------+-----+---------+----------------+

+-------+----------+------+-----+---------+----------------+

| fid | int(11) | | PRI | NULL | auto_increment |

| g | geometry | | | | |

+-------+----------+------+-----+---------+----------------+

2 rows in set (0.00 sec)

mysql> SELECT COUNT(*) FROM geom;

+----------+

| count(*) |

+----------+

| 32376 |

+----------+

1 row in set (0.00 sec)

Чтобы добавлять пространственный индекс на столбце g, используйте эту инструкцию:mysql> ALTER TABLE geom ADD SPATIAL INDEX(g);

Query OK, 32376 rows affected (4.05 sec)

Records: 32376 Duplicates: 0 Warnings: 0

4.6.2. Использование пространственного индекса

Оптимизатор исследует, могут ли доступные пространственные индексы включаться в поиск для запросов, которые используют функцию типа MBRContains() или MBRWithin() в предложении WHERE. Следующий запрос находит все объекты, которые находятся в данном прямоугольнике:mysql> SET @poly = 'Polygon((30000 15000, 31000 15000, 31000 16000,

– > 30000 16000, 30000 15000))';

mysql> SELECT fid, AsText(g) FROM geom WHERE

– > MBRContains(GeomFromText(@poly), g);

+-----+---------------------------------------------------------------+

| fid | AsText(g) |

+-----+---------------------------------------------------------------+

| 21 | LINESTRING(30350.4 15828.8,30350.6 15845,30333.8 15845,30 … |

| 22 | LINESTRING(30350.6 15871.4,30350.6 15887.8,30334 15887.8, … |

| 23 | LINESTRING(30350.6 15914.2,30350.6 15930.4,30334 15930.4, … |

| 24 | LINESTRING(30290.2 15823,30290.2 15839.4,30273.4 15839.4, … |

| 25 | LINESTRING(30291.4 15866.2,30291.6 15882.4,30274.8 15882. … |

| 26 | LINESTRING(30291.6 15918.2,30291.6 15934.4,30275 15934.4, … |

| 249 | LINESTRING(30337.8 15938.6,30337.8 15946.8,30320.4 15946. … |

| 1 | LINESTRING(30250.4 15129.2,30248.8 15138.4,30238.2 15136. … |

| 2 | LINESTRING(30220.2 15122.8,3024.2 15137.8,30207.6 15136, … |

| 3 | LINESTRING(30179 15114.4,30176.6 15129.4,30167 15128,3016 … |

| 4 | LINESTRING(30155.2 15121.4,30140.4 15118.6,30142 15109,30 … |

| 5 | LINESTRING(30192.4 15085,30177.6 15082.2,30179.2 15072.4, … |

| 6 | LINESTRING(30244 15087,30229 15086.2,30229.4 15076.4,3024 … |

| 7 | LINESTRING(30200.6 15059.4,30185.6 15058.6,30186 15048.8, … |

| 10 | LINESTRING(30179.6 1504.8,30181 15002.8,30190.8 15003.6, … |

| 11 | LINESTRING(30154.2 15000.4,30168.6 15004.8,30166 15014.2, … |

| 13 | LINESTRING(30105 15065.8,30108.4 15050.8,30118 15053,3011 … |

| 154 | LINESTRING(30276.2 15143.8,30261.4 15141,30263 15131.4,30 … |

| 155 | LINESTRING(30269.8 15084,30269.4 15093.4,30258.6 15093,30 … |

| 157 | LINESTRING(30128.2 15011,30113.2 15010.2,30113.6 15000.4, … |

+-----+---------------------------------------------------------------+

20 rows in set (0.00 sec)

Использование EXPLAIN показывает, каким способом этот запрос выполнен:mysql> SET @poly = 'Polygon((30000 15000, 31000 15000,

– > 31000 16000, 30000 16000, 30000 15000))';

mysql> EXPLAIN SELECT fid, AsText(g) FROM geom WHERE

– > MBRContains(GeomFromText(@poly), g)\G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: geom

type: range

possible_keys: g

key: g

key_len: 32

ref: NULL

rows: 50

Extra: Using where

1 row in set (0.00 sec)

Проверьте, что случилось бы без пространственного индекса:mysql> SET @poly = 'Polygon((30000 15000, 31000 15000,

– > 31000 16000, 30000 16000, 30000 15000))';

mysql> EXPLAIN SELECT fid,AsText(g) FROM g IGNORE INDEX (g) WHERE

– > MBRContains(GeomFromText(@poly), g)\G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: geom

type: ALL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: 32376

Extra: Using where

1 row in set (0.00 sec)

Выполнение инструкции SELECT без пространственного индекса выдает тот же самый результат, но заставляет время выполнения повышаться с 0.00 до 0.46 секунды:mysql> SET @poly = 'Polygon((30000 15000, 31000 15000,

– > 31000 16000, 30000 16000, 30000 15000))';

mysql> SELECT fid, AsText(g) FROM geom IGNORE INDEX (g) WHERE