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

mysql> CREATE VIEW v AS SELECT CHARSET(CHAR(65)), COLLATION(CHAR(65));

Query OK, 0 rows affected (0.00 sec)

mysql> SET NAMES 'latin1';

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM v;

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

| CHARSET(CHAR(65)) | COLLATION(CHAR(65)) |

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

| latin1 | latin1_swedish_ci |

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

1 row in set (0.00 sec)

mysql> SET NAMES 'utf8';

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM v;

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

| CHARSET(CHAR(65)) | COLLATION(CHAR(65)) |

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

| utf8 | utf8_general_ci |

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

1 row in set (0.00 sec)

Предложения DEFINER и SQL SECURITY определяют контекст защиты, который нужно использовать при проверке привилегий доступа при вызове view. Они были добавлены в MySQL 5.0.13, но реально работают с MySQL 5.0.16.

CURRENT_USER также известен как CURRENT_USER().

Внутри сохраненной подпрограммы, которая определена с характеристикой SQL SECURITY DEFINER, CURRENT_USER возвращает создателя подпрограммы. Это также воздействует на view, определенный внутри такой подпрограммы, если определение view содержит значение DEFINER для CURRENT_USER.

Заданное по умолчанию значение DEFINER: пользователь, который выполняет инструкцию CREATE VIEW (поскольку DEFINER = CURRENT_USER). Если задано значение user , это должно быть логином MySQL в формате ' user_name '@' host_name ' (тот же самый формат, используется в инструкции GRANT). Требуются значения user_name и host_name .

Если Вы определяете предложение DEFINER, Вы не можете устанавливать значение к любому пользователю, если не имеете привилегии SUPER. Эти правила определяют допустимые значения пользователя для предложения DEFINER:

Если Вы не имеете привилегии SUPER, единственное допустимое значение user : Ваш собственный логин, определенный буквально или используя CURRENT_USER. Вы не можете устанавливать DEFINER к некоторому другому логину.

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

Характеристика SQL SECURITY определяет, который логин MySQL использовать при проверке привилегий доступа для view. Допустимые значения: DEFINER и INVOKER. Они указывают, что view должен быть выполним пользователем, который определил или вызвал его, соответственно. Заданное по умолчанию значение для SQL SECURITY: DEFINER.

Начиная с MySQL 5.0.16 (когда были введены в строй DEFINER и SQL SECURITY), привилегии view проверяются следующим образом:

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

Во время выполнения view, привилегии для объектов, к которым обращается view, проверены относительно привилегий создателя или исполнителя view, в зависимости от того, является ли характеристика SQL SECURITY равной DEFINER или INVOKER.

Если выполнение view вызывает выполнение сохраненной функции, инструкции прверки привилегии, выполненные внутри функции, зависят от того, определена ли функция с характеристикой SQL SECURITY, равной DEFINER или INVOKER. Если характеристика защиты DEFINER, функция выполняется с привилегиями создателя. Если характеристика INVOKER, функция выполняется с привилегиями, определенными в соответствии с характеристикой SQL SECURITY для view.

До MySQL 5.0.16 привилегии, требуемые для объектов, используемых в view, проверялись при создании view.

Пример: view мог бы зависеть от сохраненной функции, и та функция могла бы вызывать другие сохраненные подпрограммы. Например, следующий view вызывает сохраненную функцию f():

CREATE VIEW v AS SELECT * FROM t WHERE t.id = f(t.name);

Предположим, что f() содержит инструкцию типа этого:

IF name IS NULL then CALL p1();

ELSE CALL p2();

END IF;

Привилегии, требуемые для выполнения инструкций внутри f(), должны быть проверены, когда f() выполняется. Это могло бы означать, что привилегии необходимы для p1() или p2(), в зависимости от пути выполнения внутри f(). Те привилегии должны быть проверены во время выполнения, а пользователь, который должен обладать привилегиями, определен значениями SQL SECURITY функции f() и view v.

DEFINER и предложение SQL SECURITY для views представляют собой расширения к стандарту SQL. В обычном SQL views обработаны, используя правила для SQL SECURITY INVOKER.

Если Вы вызываете view, который был создан до MySQL 5.0.13, это обрабатывается, как если бы это было создано с предложением SQL SECURITY DEFINER и со значением DEFINER, равным Вашему логину. Однако, потому что фактический definer неизвестен, MySQL выдает предупреждение. Чтобы обойти предупреждение, достаточно вновь создать view, так чтобы определение view включило предложение DEFINER.

Факультативное предложение ALGORITHM задает расширение MySQL для стандартного SQL. ALGORITHM берет три значения: MERGE, TEMPTABLE или UNDEFINED. Заданный по умолчанию UNDEFINED, если никакое предложение ALGORITHM не присутствует. Алгоритм воздействует на то, как MySQL обрабатывает view.

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

Для TEMPTABLE результаты из просмотра view помещаются во временную таблицу, которая затем используется, чтобы выполнить инструкцию.

Для UNDEFINED MySQL выбирает, который алгоритм использовать. Это предпочитает MERGE варианту TEMPTABLE, если возможно, поскольку MERGE обычно более эффективен и потому, что view не может быть обновляемым, если временная таблица используется.

Причина выбирать TEMPTABLE явно: блокировки на основных таблицах могут быть сняты после того, как временная таблица была создана, но прежде, чем это используется, чтобы закончить обрабатывать инструкцию. Это могло бы привести к более быстрому снятию блокировки, чем алгоритм MERGE так, чтобы другая клиентура, которая использует view, не была блокирована очень долго.

Алгоритм view может быть UNDEFINED по трем причинам:

Никакое предложение ALGORITHM не присутствует в инструкции CREATE VIEW.

Инструкция CREATE VIEW имеет явное предложение ALGORITHM = UNDEFINED.

ALGORITHM = MERGE определен для view, который может быть обработан только с временной таблицей. В этом случае MySQL генерирует предупреждение и устанавливает алгоритм к UNDEFINED (не к TEMPTABLE!).

Как упомянуто ранее, MERGE обработан, объединяя соответствующие части определения view в инструкцию, которая обращается к view. Следующие примеры кратко иллюстрируют, как работает алгоритм MERGE. Примеры принимают, что имеется view v_merge, который имеет это определение:

CREATE ALGORITHM = MERGE VIEW v_merge (vc1, vc2) AS

SELECT c1, c2 FROM t WHERE c3 > 100;

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

SELECT * FROM v_merge;

MySQL обрабатывает инструкцию следующим образом: