Spec-Zone .ru
спецификации, руководства, описания, API

B.5. FAQ MySQL 5.7: Триггеры

Вопросы

Вопросы и Ответы

B.5.1: Где я могу найти документацию для триггеров MySQL 5.7?

См. Раздел 18.3, "Используя Триггеры".

B.5.2: есть ли дискуссионный форум для MySQL Triggers?

Да. Это доступно в http://forums.mysql.com/list.php?99.

B.5.3: у MySQL 5.7 есть триггеры на уровне строки или на уровне оператора?

В MySQL 5.7 все триггеры FOR EACH ROW— то есть, триггер активируется для каждой строки, которая вставляется, обновляется, или удаляется. MySQL 5.7 не поддерживает триггерное использование FOR EACH STATEMENT.

B.5.4: Есть ли какие-либо триггеры значения по умолчанию?

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

B.5.5: Как триггеры, которыми управляют в MySQL?

В MySQL 5.7 триггеры могут быть созданы, используя CREATE TRIGGER оператор, и отброшенное использование DROP TRIGGER. См. Раздел 13.1.15,"CREATE TRIGGER Синтаксис", и Раздел 13.1.24,"DROP TRIGGER Синтаксис", для больше об этих операторах.

Информация о триггерах может быть получена, запрашивая INFORMATION_SCHEMA.TRIGGERS таблица. См. Раздел 19.27," INFORMATION_SCHEMA TRIGGERS Таблица".

B.5.6: есть ли способ просмотреть все триггеры в данной базе данных?

Да. Можно получить перечисление всех триггеров, определенных на базе данных dbname использование запроса на INFORMATION_SCHEMA.TRIGGERS таблица такой как один показанный здесь:

SELECT TRIGGER_NAME, EVENT_MANIPULATION, EVENT_OBJECT_TABLE, ACTION_STATEMENT    FROM INFORMATION_SCHEMA.TRIGGERS    WHERE TRIGGER_SCHEMA='dbname';

Для получения дополнительной информации об этой таблице, см. Раздел 19.27," INFORMATION_SCHEMA TRIGGERS Таблица".

Можно также использовать SHOW TRIGGERS оператор, который является определенным для MySQL. См. Раздел 13.7.5.37,"SHOW TRIGGERS Синтаксис".

B.5.7: Где сохраненные триггеры?

Триггеры для таблицы в настоящий момент сохранены в .TRG файлы, с одним таким файлом один на таблицу.

B.5.8: триггер может вызвать хранимую процедуру?

Да.

B.5.9: действительно ли триггеры могут получить доступ к таблицам?

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

B.5.10: триггеры могут вызвать внешнее приложение через UDF?

Да. Например, триггер мог вызвать sys_exec() UDF.

B.5.11: для триггера действительно ли возможно обновить таблицы на удаленном сервере?

Да. Таблица на удаленном сервере могла быть обновлена, используя FEDERATED механизм хранения. (См. Раздел 14.9," FEDERATED Механизм хранения").

B.5.12: триггеры работают с репликацией?

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

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

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

Для получения дополнительной информации см. Раздел 16.4.1.31, "Репликация и Триггеры".

B.5.13: То, как действия выполняются через, включает ведущее устройство, тиражированное в ведомое устройство?

Снова, это зависит от того, используете ли Вы основанную на операторе или построчную репликацию.

Основанная на операторе репликация. Во-первых, триггеры, которые существуют на ведущем устройстве, должны быть воссозданы на ведомом сервере. Как только это делается, работы потока репликации как любой другой стандартный оператор DML, который участвует в репликации. Например, рассмотрите таблицу EMP это имеет AFTER вставьте триггер, который существует на основном сервере MySQL. То же самое EMP таблица и AFTER вставьте триггер, существуют на ведомом сервере также. Поток репликации был бы:

  1. INSERT оператор делается к EMP.

  2. AFTER включить EMP активируется.

  3. INSERT оператор пишется двоичному журналу.

  4. Ведомое устройство репликации поднимает INSERT оператор к EMP и выполняет это.

  5. AFTER включить EMP это существует на ведомом устройстве, активируется.

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

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

Для получения дополнительной информации см. Раздел 16.4.1.31, "Репликация и Триггеры".