Capítulo 19. Extensiones espaciales de MySQLTabla de contenidos      [ + / - ]

19.1.   Definición de programas almacenados

19.2.   Uso de procedimientos almacenados (procedimientos y funciones)       [ + / - ]

19.3.   Utilización de disparadores       [ + / - ]

19,4.   Usando el Programador de eventos       [ + / - ]

19,5.   Uso de las vistas       [ + / - ]

19.6.   Control de acceso para los programas almacenados y vistas

19.7.   Registro binario de programas almacenados

Este capítulo trata de los programas almacenados y vistas, que son objetos de bases de datos

definidas en términos de código SQL que se almacenan en el servidor para su posterior

ejecución.

Los programas almacenados incluyen estos objetos:

Los procedimientos almacenados, es decir, procedimientos almacenados y funciones. Un

procedimiento almacenado se invoca utilizando el LLAMADA comunicado. Un procedimiento

no tiene un valor de retorno, pero puede modificar sus parámetros para una inspección

posterior por la persona que llama. También puede generar conjuntos de resultados que se

devuelve al programa cliente. Una función almacenada se utiliza mucho como una función

integrada. lo invoque en una expresión y devuelve un valor al evaluar una expresión.

Triggers. Un disparador es un objeto de base de datos con nombre que se asocia con una

mesa y que se activa cuando ocurre un evento particular para la mesa, como una inserción

o actualización.

Eventos. Un evento es una tarea que el servidor se ejecuta de acuerdo a lo programado.

Las vistas se almacenan las consultas que se hace referencia cuando se producen un

conjunto de resultados.Una vista actúa como una tabla virtual.

En este capítulo se describe cómo utilizar los programas almacenados y vistas. Las siguientes

secciones proporcionan información adicional acerca de la sintaxis SQL para comandos

relacionados con estos objetos:

Para cada tipo de objeto, hay CREATE , ALTER y DROP estados que controlan los objetos

que existen y cómo se definen. Vea la Sección 13.1, "Instrucciones de definición de

datos" .

La LLAMADA declaración se utiliza para llamar a procedimientos almacenados. Vea la

sección 13.2.1, "   LLAME sintaxis "  .

Almacenados definiciones del programa incluyen un cuerpo que se pueden utilizar

sentencias compuestas, bucles, condicionales, y las variables

declaradas. Consulte Sección 13.6, "MySQL compuesto-Declaración de sintaxis" .

19.1. Definición de programas almacenadosCada programa almacenado contiene un cuerpo que consiste en una sentencia SQL. Esta

afirmación puede ser una instrucción compuesta formada por varias declaraciones separadas

por punto y coma ( ; ) caracteres. Por ejemplo, el siguiente procedimiento almacenado tiene

un cuerpo formado por un BEGIN ...   FIN  bloque que contiene un SET declaración y

un REPEAT bucle que sí contiene otro SET declaración:

CREATE PROCEDURE dorepeat (p1 INT)

COMENZAR

SET @ x = 0;

REPEAT SET @ x = @ x + 1, hasta que @ x> REPEAT END P1;

END;

Si utiliza el mysql programa cliente para definir un programa almacenado que contiene los

caracteres punto y coma dentro de su definición, surge un problema. Por defecto, MySQL se

reconoce punto y coma como delimitador de una declaración, por lo que debe redefinir el

delimitador de forma temporal para causar mysql para pasar toda la definición de programa

almacenado en el servidor.

Para redefinir el mysql delimitador, utilice el delimitador de comando. El siguiente ejemplo

muestra cómo hacer esto para el dorepeat () el procedimiento se acaba de mostrar. El

delimitador se cambia a / / para permitir que toda la definición que se pasa al servidor como

una sola instrucción, y luego restaurada , antes de invocar el procedimiento. Esto permite que

el ; delimitador utilizado en el cuerpo del procedimiento a través del servidor en lugar de ser

interpretado por MySQL sí mismo.

mysql> delimitador / /

mysql> CREATE PROCEDURE dorepeat (p1 INT)

-> INICIO

-> SET @ x = 0;

-> REPEAT SET @ x = @ x + 1, hasta que @ x> p1 final de la repetición;

-> END

-> / /

Query OK, 0 rows affected (0.00 sec)

mysql> delimitador;

mysql> LLAMADA dorepeat (1000);

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @ x;

+ ------ +

| @ X |

+ ------ +

| 1001 |

+ ------ +

1 row in set (0.00 sec)

Puede redefinir el delimitador de una cadena que no sea / / , y el delimitador puede consistir

en un solo carácter o varios caracteres. Usted debe evitar el uso de la barra invertida (" \ ") ya

que es el carácter de escape para MySQL.

El siguiente es un ejemplo de una función que toma un parámetro, realiza una operación con

una función de SQL, y devuelve el resultado. En este caso, es innecesario

utilizar delimitador porque la definición de función no contiene interna ; delimitadores

declaración:mysql> CREATE FUNCTION hola (s CHAR (20))

mysql> RETURNS CHAR (50) determinista TIC

-> CONCAT RETURN ('Hola', s, '!');

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT hello ("mundo");

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

| Hola ("mundo") |

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

| Hola, mundo! |

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

1 row in set (0.00 sec)

19.2. Uso de procedimientos almacenados (procedimientos y funciones)[ + / - ]

19.2.1.   Sintaxis de procedimientos almacenados

19.2.2.   Procedimientos almacenados y privilegios de MySQL

19.2.3.   Los metadatos de procedimientos almacenados

19.2.4.   Procedimientos almacenados, funciones, disparadores, y   LAST_INSERT_ID ()

Las rutinas almacenadas (procedimientos y funciones) se soportan en MySQL 5.5. Una rutina

de almacenamiento es un conjunto de sentencias SQL que se pueden almacenar en el

servidor. Una vez hecho esto, los clientes no es necesario para mantener la reemisión de los

estados individuales, sino que puede referirse a la rutina de almacenamiento en su lugar.

Los procedimientos almacenados requieren el proc tabla en el mysql base de datos. Esta

tabla se crea durante el procedimiento de instalación de MySQL 5.5. Si está actualizando a

MySQL 5.5 desde una versión anterior, asegúrese de actualizar sus tablas de permisos para

asegurarse de que el proc tabla existe. Vea la Sección 4.4.7, "   mysql_fix_privilege_tables   -

Comprobar las tablas de actualización de MySQL " .

Los procedimientos almacenados pueden ser particularmente útiles en ciertas situaciones:

Cuando múltiples aplicaciones cliente se escriben en diferentes idiomas o trabajar en

diferentes plataformas, pero es necesario para realizar las operaciones de base de datos

misma.

Cuando la seguridad es primordial. Los bancos, por ejemplo, utilizar procedimientos

almacenados y funciones para todas las operaciones comunes. Esto proporciona un

ambiente seguro y consistente, y las rutinas se puede asegurar que cada operación está

correctamente conectado. En tal configuración, las aplicaciones y los usuarios no tendrían

acceso a las tablas de base de datos directamente, sino que sólo pueden ejecutar

determinados procedimientos almacenados.

Los procedimientos almacenados pueden proporcionar un mejor rendimiento ya que menos

información tiene que ser enviado entre el servidor y el cliente. La desventaja es que esto no

aumenta la carga en el servidor de base de datos porque la mayoría del trabajo se lleva a

cabo en el servidor y se hace menos en el cliente (aplicación) lado. Considere esto si muchas

máquinas cliente (por ejemplo, servidores web) son atendidos por sólo uno o unos pocos

servidores de bases de datos.

Los procedimientos almacenados también le permiten tener bibliotecas de funciones en el

servidor de base de datos. Esta es una característica compartida por las lenguas modernas

que permitan la aplicación de diseño como a nivel interno (por ejemplo, mediante el uso de las

clases). El uso de estas características de la aplicación cliente del idioma es beneficioso para

el programador, incluso fuera del ámbito de uso de base de datos.

MySQL sigue el SQL: 2003 sintaxis para procedimientos almacenados, que también es

utilizado por DB2 de IBM.Toda la sintaxis descrita aquí con el apoyo y las limitaciones y las

extensiones están documentadas en su caso.

Recursos adicionales

Usted puede encontrar el Foro de procedimientos almacenados de usuario de uso cuando

se trabaja con procedimientos almacenados y funciones.

Para obtener respuestas a algunas preguntas frecuentes con respecto a los

procedimientos almacenados en MySQL, consulte Sección B.4, "MySQL 5.5 FAQ:

Procedimientos almacenados y funciones" .

Hay algunas restricciones en el uso de procedimientos almacenados. Consulte Sección

D.1, "Restricciones a programas almacenados" .

Registro binario de procedimientos almacenados se lleva a cabo como se describe en la

Sección 19.7, "Registro binario de programas almacenados" .

19.2.1. Sintaxis de procedimientos almacenadosUna rutina de almacenado es un procedimiento o una función. Los procedimientos

almacenados se crean con losCREATE PROCEDURE y CREATE FUNCTION declaraciones

(véase la Sección 13.1.15, "   CREATE PROCEDURE   y CREATE FUNCTION   sintaxis "  ). Un

procedimiento se invoca usando un CONVOCATORIA declaración (véase la Sección 13.2.1,

"   CONVOCATORIA   sintaxis "  ), y sólo puede pasar valores usando variables de salida. Una

función puede ser llamada desde el interior de una declaración como cualquier otra función

(es decir, invocando el nombre de la función), y puede devolver un valor escalar. El cuerpo de

una rutina almacenada puede utilizar sentencias compuestas (véase la Sección 13.6, "MySQL

compuesto-Declaración de la sintaxis" ).

Los procedimientos almacenados se puede quitar con la DROP PROCEDURE y DROP

FUNCTION declaraciones (véase la Sección 13.1.26, "   DROP PROCEDURE   y   DROP

FUNCTION   sintaxis "  ), y modificado con la sentencia ALTER PROCEDURE y ALTER

FUNCTION declaraciones (véase la Sección 13.1.5, "   ALTER PROCEDURE   Sintaxis "  ).

Un procedimiento almacenado o función está asociada con una base de datos en

particular. Esto tiene varias implicaciones:

Cuando se invoca la rutina, una implícita USO db_name se lleva a cabo (y se deshace

cuando la rutina). USEdentro de procedimientos almacenados no se permiten.

Puede calificar los nombres de rutina con el nombre de base de datos. Esto puede ser

utilizado para hacer referencia a una rutina que no está en la base de datos actual. Por

ejemplo, para invocar un procedimiento almacenado p o de la función f que se asocia con

la prueba de base de datos, se puede decir test.p LLAMADA () o test.f () .

Cuando se quita una base, todas las rutinas almacenados asociados con ella se eliminan

también.

Funciones almacenados no pueden ser recursivos.

La recursividad en los procedimientos almacenados se permite, pero deshabilitado por

defecto. Para habilitar la recursión, establezca la max_sp_recursion_depth variable de

servidor del sistema a un valor mayor que cero.Repetición del procedimiento almacenado

aumenta la demanda de espacio de hilo de pila. Si aumenta el valor

demax_sp_recursion_depth , puede ser necesario aumentar el tamaño del hilo de la pila

mediante el aumento del valor de thread_stack al iniciar el servidor. Consulte Sección 5.1.3,

"Variables de sistema del servidor" , para más información.

MySQL soporta una extensión muy útil que permite el uso de regulares SELECT declaraciones

(es decir, sin necesidad de utilizar los cursores o variables locales) dentro de un procedimiento

almacenado. El conjunto de resultados de este tipo de consultas se envía directamente al

cliente. Múltiples SELECT declaraciones generan varios conjuntos de resultados, por lo que el

cliente debe usar una biblioteca cliente de MySQL que soporta varios conjuntos de

resultados. Esto significa que el cliente debe usar una biblioteca cliente de una versión de

MySQL por lo menos tan reciente como 4.1. El cliente también debe especificar

el CLIENT_MULTI_RESULTSopción cuando se conecta. Para programas de C, esto puede

hacerse con la mysql_real_connect () función C API. Vea la Sección 22.8.3.52,

"   mysql_real_connect   ()   "  , y la Sección 22.8.13, "la API C para la ejecución de múltiples" .

19.2.2. Procedimientos almacenados y privilegios de MySQLEl sistema de permisos de MySQL tiene las rutinas almacenadas en cuenta lo siguiente:

La RUTINA CREATE privilegio es necesario para crear rutinas almacenadas.

El ALTER ROUTINE privilegio que se necesita para alterar o borrar procedimientos

almacenados. Este permiso se otorga automáticamente al creador de la rutina si es

necesario, y se dejó caer desde el creador cuando la rutina se ha caído.

El EXECUTE privilegio se requiere para ejecutar las rutinas almacenadas. Sin embargo, este

permiso se otorga automáticamente al creador de la rutina si es necesario (y se dejó caer

desde el creador cuando la rutina se ha caído). Además, el valor por defecto de

seguridad de SQL característico de una rutina es DEFINER , que permite a los usuarios

que tienen acceso a la base de datos con la que la rutina está asociada para ejecutar la

rutina.

Si el automatic_sp_privileges variable del sistema es 0, el EXECUTE y ALTER DE

RUTINA privilegios que no se conceden automáticamente a y se dejó caer desde el creador

de la rutina.

El creador de la rutina es la cuenta utilizada para ejecutar la sentencia

CREATE declaración por ello. Esto podría no ser la misma que la cuenta denominada como

la DEFINER en la definición de la rutina.

El servidor manipula la mysql.proc mesa en respuesta a las declaraciones que crean,

modificar o quitar las rutinas almacenadas. No se admite que el servidor se dará cuenta de la

manipulación manual de esta tabla.

19.2.3. Los metadatos de procedimientos almacenadosMetadatos sobre las rutinas almacenadas se puede obtener como sigue:

Consultar el RUTINAS mesa del INFORMATION_SCHEMA base de datos. Vea la Sección

20.17, "La INFORMATION_SCHEMA RUTINAS   tabla "  .

Utilice el SHOW CREATE PROCEDIMIENTO y SHOW CREATE FUNCTION declaraciones para

ver definiciones de rutina. Vea la Sección 13.7.5.11, "   SHOW CREATE

PROCEDIMIENTO   sintaxis "  .

Utilice el Estado PROCEDIMIENTO ESPECTACULO y muestran una función

ESTADO declaraciones para ver las características de rutina. Vea la Sección 13.7.5.29,

"   PROCEDIMIENTO DE SHOW STATUS   Sintaxis "  

19.2.4. Procedimientos almacenados, funciones, disparadores, yLAST_INSERT_ID ()Dentro del cuerpo de una rutina almacenada (procedimiento o función) o un gatillo, el valor

de LAST_INSERT_ID () cambia la misma manera que para instrucciones ejecutadas fuera

del cuerpo de estos tipos de objetos (véasela Sección 12.14, "Funciones de información" ). El

efecto de una rutina almacenada o gatillo en el valor deLAST_INSERT_ID () que se ve

siguiendo estados depende del tipo de rutina:

Si un procedimiento almacenado ejecuta sentencias que cambian el valor

de LAST_INSERT_ID () , el valor de cambio es visto por las declaraciones que siguen la

llamada de procedimiento.

Para las funciones almacenados y disparadores que cambian el valor, el valor se restaura

cuando los extremos de la función o el gatillo, por lo que tras las declaraciones no veo un

valor cambiado.

19.3. Utilización de disparadores[ + / - ]

19.3.1.   Sintaxis de disparo

19.3.2.   Disparo de metadatos

Un disparador es un objeto de base de datos con nombre que se asocia con una tabla, y que

se activa cuando ocurre un evento particular de la tabla. Algunos de los usos para los

disparadores es verificar valores que se inserta en una tabla o para realizar cálculos sobre los

valores involucrados en una actualización.

Un disparador se define para activarse cuando un INSERT , DELETE ,

o ACTUALIZACIÓN sentencia se ejecuta de la tabla asociada. Un disparador se puede

configurar para activar ya sea antes o después de la instrucción de disparo. Por ejemplo,

usted puede tener un gatillo antes de activar cada fila que se inserta en una tabla o después

de cada fila que se actualiza.

Importante

Factores desencadenantes de MySQL son activados por las sentencias de SQL sólo . Ellos no

son activados por cambios en la vista, ni por cambios en las tablas hechas por API que no

transmiten las sentencias SQL al servidor MySQL. Esto significa que:

Los desencadenadores no se activan por cambios en INFORMATION_SCHEMA tablas, ya

que estas tablas son en realidad puntos de vista.

Los desencadenadores no se activan las actualizaciones realizadas mediante el NDB de la

API.

Para utilizar dispara si se ha actualizado a MySQL 5.5 desde una versión anterior que no

apoyó activa, debe actualizar las tablas de permisos para que contengan los privilegios

relacionados con el gatillo. Vea la Sección 4.4.7, "   mysql_fix_privilege_tables   -

Comprobar las tablas de actualización de MySQL " .

La discusión siguiente describe la sintaxis para crear y eliminar disparadores, y muestra

algunos ejemplos de cómo usarlos.

Recursos adicionales

Usted puede encontrar el foro de usuarios desencadenantes de uso cuando se trabaja con

puntos de vista.

Para obtener respuestas a algunas preguntas frecuentes con respecto a disparadores en

MySQL, consulte la sección B.5, "MySQL 5.5: Preguntas Frecuentes: disparadores" .

Hay algunas restricciones en el uso de disparadores, véase la Sección D.1, "Restricciones

a programas almacenados" .

El registro binario para disparadores se lleva a cabo como se describe en la Sección 19.7,

"Registro binario de programas almacenados" .

Para crear un disparador o quitar un desencadenador, utilice el CREATE TRIGGER o DROP

TRIGGER comunicado.La sintaxis de las mismas se describe en la Sección 13.1.19, "   CREATE

TRIGGER   Sintaxis "  , y la Sección 13.1.30, " DROP TRIGGER   Sintaxis "  .

Aquí está un ejemplo simple que asocia un disparador con una tabla

para INSERT declaraciones. El disparador actúa como un acumulador, la suma de los valores

insertados en una de las columnas de la tabla.mysql> CREATE TABLE cuenta (acct_num int, decimal cantidad (10,2));

Query OK, 0 filas afectadas (0,03 segundos)

mysql> CREATE TRIGGER ins_sum ANTES DE INSERTAR EN la cuenta

-> Para cada conjunto ROW @ @ = suma suma + NEW.amount;

Query OK, 0 filas afectadas (0,06 seg)

La CREATE TRIGGER sentencia crea un disparador llamado ins_sum que está asociada con

la cuenta de la tabla. También se incluyen cláusulas que especifican el momento de

activación, el evento desencadenante, y qué hacer luego de la activación:

La palabra clave ANTES indica el tiempo de la acción de disparo. En este caso, el gatillo

debe activar antes de cada fila se inserta en la tabla. La palabra clave aquí es admisible

otra DESPUÉS .

La palabra clave INSERT indica el evento que activa el disparador. En el

ejemplo, INSERT declaraciones causará la activación. También pueden crearse

disparadores para BORRAR y ACTUALIZAR declaraciones.

La instrucción que sigue PARA CADA FILA define lo que se ejecutará cada vez que se

activa el disparador, que se produce una vez por cada fila afectada por la sentencia en

cuestión. En el ejemplo, la sentencia activada es un sencillo SET que acumula los valores

insertados en la cantidad de la columna. La instrucción se refiere a la columna

como NEW.amount que significa " el valor de la cantidad de columna para ser

insertado en la nuevafila. "

Para utilizar el disparador, establezca la variable acumulador a cero, ejecutar

un INSERT declaración, y luego ver qué valor presenta luego la variable:

mysql> SET @ suma = 0;

mysql> INSERT INTO valores de las cuentas (137,14.98), (141,1937.50), (97, -

100.00);

mysql> SELECT @ suma como «importe total inserta ';

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

| Importe total insertada |

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

| 1852,48 |

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

En este caso, el valor de @ sum después de que el INSERT declaración se ha ejecutado

es 14.98 + 1937.50 - 100 , o 1852.48 .

Para eliminar el disparador, utilice un DROP TRIGGER comunicado. Debe especificar el nombre

del esquema, si el gatillo no está en el esquema predeterminado:mysql> DROP TRIGGER test.ins_sum;

En una misma tabla también se descartan si se le cae de la mesa.

Nombres de los desencadenadores existen en el espacio de nombres de esquema, lo que

significa que todos los activadores deben tener nombres únicos dentro de un esquema. Los

disparadores de los esquemas diferentes pueden tener el mismo nombre.

Además de la exigencia de que los nombres únicos de disparador en un esquema, hay otras

limitaciones sobre los tipos de disparadores que pueden crearse. En particular, no se puede

tener dos disparadores para una tabla que tienen el mismo tiempo de activación y el evento de

activación. Por ejemplo, no se pueden definir dos BEFORE INSERT disparadores o dos AFTER

UPDATE en una misma tabla. Es improbable que esta sea una gran limitación, ya que es

posible definir un disparador que ejecute sentencias múltiples usando

la BEGIN ...   FIN  sentencia compuesta construir después de FOR EACH ROW . (Un ejemplo

aparece más adelante en esta sección.)

Los OLD y NEW palabras clave le permiten acceder a las columnas de las filas afectadas por un

factor desencadenante. ( OLD y NEW no distinguen entre mayúsculas y minúsculas). En

un INSERT gatillo, sólo NUEVA.col_name puede ser utilizado, no hay una fila de edad. En

un DELETE gatillo, solo . VIEJO col_name puede ser utilizado, no hay nueva fila. En

un ACTUALIZACIÓN gatillo, puede utilizar VIEJO. col_name para referirse a las columnas de

una fila antes de que se actualiza y NUEVO. col_name para referirse a las columnas de la fila

después de que se actualice.

Una columna precedida por OLD es de sólo lectura. Puede referirse a él (si usted tiene

la SELECT privilegio), pero no modificarlo. Una columna precedida por NEW puede ser

referenciada si usted tiene la SELECT privilegio para ella. En un ANTES gatillo, también puede

cambiar su valor con SET NEW. col_name = valor si usted tiene

laACTUALIZACIÓN privilegio para ella. Esto significa que usted puede utilizar un disparador

para modificar los valores que se inserta en una nueva fila o que se utilizan para actualizar

una fila.

En una ANTES de disparo, el NUEVO valor para una columna AUTO_INCREMENT columna es 0,

no el número de secuencia generado automáticamente que se generará cuando el registro

sea realmente insertado.

OLD y NEW son extensiones de MySQL para los disparadores.

Al utilizar el BEGIN ...   END  construir, se puede definir un disparador que ejecute sentencias

múltiples. Dentro del BEGIN bloque, también puede utilizar la sintaxis de otro tipo que se

permite dentro de procedimientos almacenados, tales como condicionales y bucles. Sin

embargo, al igual que para procedimientos almacenados, si se utiliza el mysql programa para

definir un disparador que ejecuta sentencias múltiples, es necesario redefinir

elmysql delimitador de modo que usted puede utilizar el ; delimitador de sentencias dentro de

la definición del disparador. El siguiente ejemplo ilustra estos puntos. Se define

un ACTUALIZACIÓN disparador que comprueba el valor nuevo que se utilizará para actualizar

cada columna, y modifica el valor de estar dentro del rango de 0 a 100. Este debe ser

un ANTES de disparo, porque el valor tiene que ser revisado antes de que se utiliza para

actualizar el registro:mysql> delimitador / /

mysql> CREATE TRIGGER upd_check ANTES DE ACTUALIZACIÓN SOBRE cuenta

-> FOR EACH ROW

-> INICIO

-> SI NEW.amount <0 THEN

-> SET NEW.amount = 0;

-> ELSEIF NEW.amount> 100 THEN

- > SET NEW.amount = 100;

-> END IF;

-> END ;/ /

mysql> delimitador;

Puede ser más fácil de definir una rutina almacenada e invocarla desde el disparador

utilizando una simpleLLAMADA comunicado. Esta es también una ventaja si se desea invocar la

misma rutina desde distintos disparadores.

Hay algunas limitaciones en lo que puede aparecer en las declaraciones que un disparador

ejecutará al activarse:

El disparador no puede utilizar el LLAMADA declaración para invocar procedimientos

almacenados que devuelven datos al cliente o que el uso de SQL dinámico. (Los

procedimientos almacenados se les permite devolver los datos a través del

gatillo OUT o INOUT parámetros.)

El disparador no puede utilizar sentencias que explícita o implícitamente, inicien o finalicen

una transacción, comoSTART TRANSACTION , COMMIT , o ROLLBACK .

MySQL gestiona los errores durante la ejecución del disparador de la siguiente manera:

Si un ANTES gatillo falla, la operación en la fila correspondiente no se realiza.

Un ANTES gatillo es activado por el intento para insertar o modificar la fila,

independientemente de si el intento tiene éxito posteriormente.

Un DESPUÉS disparador se ejecuta sólo si el ANTES de disparo (si existe) y la operación de

fila tanto ejecutar con éxito.

Un error durante un ANTES y DESPUÉS de los resultados de activación en el fracaso de

toda la declaración que hizo la invocación del disparador.

Para las tablas transaccionales, la falla de una declaración debería provocar el

desmantelamiento de todos los cambios realizados por esa sentencia. La falta de un

disparo hace que la instrucción a fallar, por lo que desencadenan el fracaso también causa

de reversión. Para tablas no transaccionales, tales reversión no se puede hacer, así que

aunque la declaración no, todos los cambios realizados antes de que el punto del error

permanecerá en vigor.

19.3.2. Disparo de metadatosMetadatos sobre los factores desencadenantes se pueden obtener de la siguiente manera:

Consultar el TRIGGERS mesa del INFORMATION_SCHEMA base de datos. Vea la Sección

20.25, "La INFORMATION_SCHEMA TRIGGERS   la tabla "  .

Utilice el SHOW DE DISPAROS comunicado. Vea la Sección 13.7.5.39, "   SHOW DE DISPARO

DE   Sintaxis "

19,4. Cómo usar el Programador de eventos[ + / - ]

19.4.1.   Programador de eventos Información general

19.4.2.   Programador de eventos de configuración

19.4.3.   Evento Sintaxis

19.4.4.   Evento de metadatos

19.4.5.   Programador de eventos de estado

19.4.6.   El evento de la agenda y los privilegios de MySQL

El MySQL Programador de eventos administra la planificación y ejecución de eventos: Las

tareas que se ejecutan de acuerdo a lo programado. La siguiente discusión cubre el

Programador de eventos y se divide en las siguientes secciones:

Sección 19.4.1, "Programador de eventos Información general"  , ofrece una introducción y

un resumen conceptual de Eventos de MySQL.

Sección 19.4.3, "Sintaxis de eventos"  , analiza las sentencias SQL para crear, alterar y

borrar eventos de MySQL.

Sección 19.4.4, "los metadatos de eventos"  , muestra cómo obtener información sobre los

eventos y cómo esta información se almacena en el servidor MySQL.

Sección 19.4.6, "El Programador de eventos y los privilegios de MySQL"  , habla de los

privilegios necesarios para trabajar con los eventos y las ramificaciones de los eventos que

tienen con respecto a los privilegios cuando se ejecuta.

Los procedimientos almacenados requieren el evento de la tabla en el mysql base de

datos. Esta tabla se crea durante el procedimiento de instalación de MySQL 5.5. Si está

actualizando a MySQL 5.5 desde una versión anterior, asegúrese de actualizar sus tablas de

permisos para asegurarse de que el evento de la tabla existe.Vea la Sección 4.4.7,

"   mysql_fix_privilege_tables   - Comprobar las tablas de actualización de MySQL "  .

Recursos adicionales

Usted puede encontrar el Evento MySQL Programador Foro de Usuarios de uso cuando se

trabaja con los eventos programados.

Hay algunas restricciones en el uso de eventos, ver Sección D.1, "Restricciones a

programas almacenados" .

El registro binario para los eventos se lleva a cabo como se describe en la Sección 19.7,

"Registro binario de programas almacenados" .

19.4.1. Programador de eventos Información generalEventos de MySQL son tareas que se ejecutan de acuerdo a un horario. Por lo tanto, a veces

se refieren a ellos como programar eventos. Cuando se crea un evento, que está creando un

objeto de base de datos con nombre que contiene una o más sentencias de SQL que se

ejecuta en uno o más intervalos regulares, comenzando y terminando en una fecha y hora

específicas. Conceptualmente, esto es similar a la idea de Unix crontab(también conocido

como un " cron job ") o el Programador de tareas de Windows.

Las tareas programadas de este tipo también se conoce a veces como " disparadores

temporales ", lo que implica que se trata de objetos que se activan con el paso del tiempo. Si

bien esto es esencialmente correcto, preferimos utilizar el término eventos para evitar la

confusión con los desencadenantes del tipo descrito en la Sección 19.3, "Utilización de

disparadores" . Los eventos no deben más específicamente debe confundirse con

" disparadores temporales ". Considerando que un disparador es un objeto de base de

datos cuyas declaraciones se ejecutan en respuesta a un tipo específico de evento que se

produce en una tabla determinada, un evento (programado) es un objeto cuyas sentencias se

ejecutan en respuesta a la aprobación de un intervalo de tiempo especificado.

Si bien no existe ninguna disposición en el estándar SQL para la programación de eventos,

hay precedentes en los sistemas de bases de datos, y usted puede notar algunas similitudes

entre estas implementaciones, y que se encuentran en el servidor MySQL.

Eventos de MySQL tiene las siguientes características y propiedades más importantes:

En MySQL 5.5, un evento que se identifica por su nombre y el esquema al que se le

asigna.

Un evento realiza una acción específica de acuerdo a un horario. Esta acción consiste en

una sentencia SQL, que puede ser una instrucción compuesta en

un BEGIN ...   FIN  bloque si así lo desea (véase la Sección 13.6, "MySQL compuesto-

Declaración de la sintaxis" ). Momento de un evento puede ser de una sola

vez orecurrentes . Un evento de una sola vez se ejecuta una sola vez. Un hecho

recurrente repite su acción en un intervalo regular, y el calendario de un evento recurrente

se le puede asignar un día de inicio y hora, día y hora de finalización, ambos o

ninguno. (De manera predeterminada, el calendario un evento recurrente comienza tan

pronto como se crea, y continúa de forma indefinida, hasta que se desactive o se ha

caído.)

Si un evento que se repite no termina dentro de su intervalo de programación, el resultado

puede ser varias instancias de la ejecución de eventos de manera simultánea. Si esto no

es deseable, debe establecer un mecanismo para prevenir los casos simultáneos. Por

ejemplo, usted podría utilizar el GET_LOCK () función, o bloqueo de filas o la tabla.

Los usuarios pueden crear, modificar y quitar los eventos programados mediante

instrucciones SQL destinados a estos fines. La creación de eventos sintácticamente

inválida y las instrucciones de modificación fallar con un mensaje de error adecuado. Un

usuario puede incluir las declaraciones en la acción de un evento que requieren privilegios

que el usuario no tiene realmente . La creación de eventos o instrucción de modificación de

éxito, pero no la acción del evento. Ver Sección 19.4.6, "El evento de la agenda y los

privilegios de MySQL" para más detalles.

Muchas de las propiedades de un evento se puede establecer o modificar mediante

sentencias SQL. Estas propiedades incluyen el nombre del evento, el tiempo, la

persistencia (es decir, si se conserva después de la expiración de su calendario), el estado

(activado o desactivado), acción que debe realizarse, y el esquema al que se le

asigna. Consulte Sección 13.1.2, "   ALTER EVENTO   sintaxis "  .

El definidor por defecto de un evento es el usuario que ha creado el evento, a menos que

el evento ha sido alterado, en cuyo caso el definidor es el usuario que ha emitido el

último ALTER EVENTO declaración que afecte a este evento. Un evento puede ser

modificado por cualquier usuario que disponga la EVENTO privilegios en la base de datos

que se define el evento. Ver Sección 19.4.6, "El evento de la agenda y los privilegios de

MySQL" .

La declaración de un caso de acción pueden incluir declaraciones con la mayor parte de

SQL permitidas en rutinas almacenadas. Por las restricciones, consulte la sección E.1,

"Restricciones a programas almacenados" .

Los eventos son ejecutados por un especial evento planificador de hilos , cuando nos

referimos a la agenda de eventos, que en realidad se refieren a este hilo. Cuando se ejecuta,

el hilo de eventos planificador y su estado actual puede ser visto por los usuarios que tengan

el PROCESO privilegio en la salida de SHOW PROCESSLIST , como se muestra en la discusión

que sigue.

El mundial event_scheduler variable del sistema determina si el evento de la agenda está

habilitado y en ejecución en el servidor. Cuenta con uno de estos 3 valores, que afectan a la

programación de eventos, como se describe aquí:

OFF : El evento de la agenda se ha detenido. El hilo de eventos planificador no se ejecuta,

no se muestra en la salida de SHOW PROCESSLIST , y no hay eventos programados se

ejecutan. OFF es el valor predeterminado paraevent_scheduler .

Cuando el evento de la agenda se detiene ( event_scheduler es OFF ), se puede iniciar

por establecer el valor de event_scheduler a ON . (Ver siguiente punto).

ON : El evento de la agenda se inicia, el hilo de eventos planificador ejecuta y se ejecuta

todos los eventos programados.

Cuando el evento de la agenda es ON , el hilo de eventos planificador está en la lista en la

salida de SHOW PROCESSLIST como un servicio, y su estado es representado como se

muestra aquí:

mysql> SHOW PROCESSLIST \ G

*************************** 1. fila ***************************

ID: 1

Usuario: root

Host: localhost

db: NULL

Comando: Consulta

Tiempo: 0

Estado: NULL

Información: Muestra processlist

*************************** 2. fila ***************************

Id: 2

Usuario: event_scheduler

Host: localhost

db: NULL

Comando: Daemon

Tiempo: 3

Estado: A la espera para la activación de al lado

Info: NULL

2 rows in set (0.00 sec)

Programación de eventos puede ser detenida por establecer el valor

de event_scheduler a OFF .

DISCAPACITADOS : Este valor hace que el Programador de eventos no

operacionales. Cuando el Programador de eventos está DISABLED , el hilo de eventos

planificador no funciona (y lo que no aparece en la salida de SHOW

PROCESSLIST ). Además, el estado Programador de eventos no se pueden cambiar en

tiempo de ejecución.

Si el estado de Programador de eventos no se ha establecido

en MINUSVALIDOS , event_scheduler se puede cambiar entre ON y OFF (con SET ). También

es posible utilizar 0 para OFF , y 1 para ON al establecer esta variable. Por lo tanto, cualquiera

de los siguientes 4 estados se puede utilizar en el mysql cliente para activar el evento de la

agenda:FIJAR GLOBAL event_scheduler = ON;

SET @ @ global.event_scheduler = ON;

FIJAR GLOBAL event_scheduler = 1;

SET @ @ global.event_scheduler = 1;

Del mismo modo, cualquiera de estos 4 estados se puede utilizar para apagar el Programador

de eventos:FIJAR GLOBAL event_scheduler = OFF;

SET @ @ global.event_scheduler = OFF;

FIJAR GLOBAL event_scheduler = 0;

SET @ @ global.event_scheduler = 0;

A pesar de ON y OFF tienen equivalentes numéricos, el valor mostrado para

la event_scheduler por SELECT oSHOW VARIABLES es siempre uno de OFF , ON ,

o DISABLED . MINUSVALIDOS no tiene un equivalente numérico .Por esta razón, ON y OFF se

prefiere normalmente a la 1 y el 0 al establecer esta variable.

Tenga en cuenta que se intenta establecer event_scheduler sin especificar como una

variable global produce un error:mysql < SET @ @ event_scheduler = OFF;

ERROR 1229 (HY000): Variable 'event_scheduler' es una GLOBAL

variable y puede ser configurada con SET GLOBAL

Importante

Es posible configurar el Programador de eventos para DISABLED sólo en el inicio del

servidor. Sievent_scheduler es ON o OFF , no se puede establecer en DISABLED en tiempo

de ejecución. Además, si el evento de la agenda se establece en DISABLED en el inicio, no se

puede cambiar el valor de event_scheduleren tiempo de ejecución.

Para desactivar el planificador de eventos, utilice uno de los dos métodos siguientes:

Como una opción de línea de comandos al iniciar el servidor:- Planificador de eventos = DESACTIVADO

En el archivo de configuración del servidor ( my.cnf o my.ini en los sistemas Windows),

incluya la línea, donde será leído por el servidor (por ejemplo, en un [mysqld] sección):

event_scheduler = DESACTIVADO

Para habilitar el Programador de eventos, reiniciar el servidor sin - planificador de

eventos = DISABLEDde línea de comandos, o después de retirar o marcar como comentario

la línea que contiene el planificador de eventos = DISABLED en el archivo de

configuración del servidor, según el caso. Alternativamente, puede utilizar ON (o 1 )

o apagado (o 0 ) en lugar de la MINUSVALIDOS valor al iniciar el servidor.

Nota

Puede emitir la manipulación de eventos declaraciones cuando event_scheduler se

establece en DISABLED .No hay advertencias o errores que se generan en estos casos

(siempre que los mismos estados son válidos). Sin embargo, los eventos programados no se

puede ejecutar hasta que esta variable se establece en ON (o 1 ). Una vez hecho esto, el hilo

de eventos planificador ejecuta todos los eventos cuya programación se cumplen las

condiciones.

Iniciar el servidor MySQL con la opción - skip-grant-tables opción hace

que event_scheduler se establezca en MINUSVALIDOS , anulando cualquier otro valor

establecido, ya sea en la línea de comandos o en elmy.cnf o my.ini archivo (Bug # 26807).

Para las sentencias SQL que se utilizan para crear, modificar, y los eventos de caída,

consulte la Sección 19.4.3, "Sintaxis de eventos" .

MySQL 5.5 ofrece una EVENTOS mesa en el INFORMATION_SCHEMA base de datos. En esta

tabla se puede consultar para obtener información sobre los eventos programados que se han

definido en el servidor. VerSección 19.4.4, "Los metadatos de eventos" , y la Sección 20.7,

"El   EVENTOS INFORMATION_SCHEMA   Tabla "  , para más información.

Para obtener información sobre la programación de eventos y el sistema de privilegios de

MySQL, consulteSección 19.4.6, "El evento de la agenda y los privilegios de MySQL" .

19.4.3. Evento SintaxisMySQL 5.5 ofrece varias sentencias SQL para trabajar con los eventos programados:

Nuevos eventos se definen mediante la sentencia CREATE EVENT comunicado. Vea la

sección 13.1.11, " CREATE EVENT   sintaxis "  .

La definición de un evento existente se puede cambiar por medio de la CASO

ALTER comunicado. ConsulteSección 13.1.2, "   ALTER EVENTO   sintaxis "  .

Cuando un evento programado ya no se quiere o necesita, puede ser eliminado del

servidor por su definidor con el DROP EVENT comunicado. Vea la sección 13.1.22, "   para

soltar eventos   de sintaxis "  . Ya sea un caso de que persista más allá del final de su

calendario también depende de su EJECUCIÓN DE cláusula, si tiene uno. Veala sección

13.1.11, "   CREATE EVENT   sintaxis "  .

Un evento puede ser disminuido por cualquier usuario que disponga la EVENTO privilegio

para la base de datos en la que se define el evento. Ver Sección 19.4.6, "El evento de la

agenda y los privilegios de MySQL" .

19.4.4. Evento de metadatosMetadatos sobre eventos puede obtenerse como sigue:

Consultar el caso de la tabla de MySQL base de datos.

Consultar el EVENTOS mesa del INFORMATION_SCHEMA base de datos. Vea la Sección

20.7, "El   EVENTOS INFORMATION_SCHEMA   Tabla "  .

Utilice el SHOW CREATE CASO comunicado. Vea la sección 13.7.5.9, "   SHOW CREATE

CASO   sintaxis "  .

Utilice el SHOW DE EVENTOS comunicado. Vea la Sección 13.7.5.19, "   Mostrar

eventos   de sintaxis "  .

Programador de eventos Representación Tiempo

Cada sesión en MySQL tiene una zona de tiempo de la sesión (STZ). Esta es la

sesión time_zone valor que se inicia desde el servidor mundial time_zone valor cuando

comience la sesión, pero puede ser cambiado durante la sesión.

La zona de tiempo de la sesión que es actual, cuando un CREATE EVENT o ALTER

EVENTO sentencia se ejecuta se utiliza para interpretar los tiempos especificados en la

definición del evento. Esto se convierte en la zona horaria evento (ETZ), es decir, la zona

horaria que se utiliza para la programación de eventos y es en efecto en el caso conforme se

ejecuta.

Para la representación de la información del evento en el mysql.event tabla,

el execute_at , se inicia ytermina veces se convierten en hora UTC y la almacena junto

con la zona horaria del evento. Esto permite la ejecución de eventos para proceder tal como

se define independientemente de los cambios ocurridos posteriormente a la zona horaria del

servidor o de verano los efectos del tiempo. El last_executed tiempo también se almacenan

en UTC.

Si selecciona la información de mysql.event , los tiempos se acaban de mencionar se

recuperan como valores de UTC. Estos tiempos también se puede obtener mediante la

selección de la INFORMATION_SCHEMA.EVENTStabla o de Mostrar eventos , pero se

reportan como valores ETZ. Otras veces disponibles de estas fuentes indican que un evento

se ha creado o modificado por última vez, éstos se muestran como los valores de STZ. La

siguiente tabla resume la representación de los tiempos de eventos.Valor mysql.eventINFORMATION_SCHEMA.EVENTSMostrar eventos

Ejecutar en UTC ETZ ETZ

Inicia UTC ETZ ETZ

Finaliza UTC ETZ ETZ

Última ejecutados UTC ETZ n / a

Creado STZ STZ n / a

Última alterado STZ STZ n / a

19.4.5. Programador de eventos de estadoEl Planificador de eventos escribe información sobre la ejecución de eventos que termina con

un error o una advertencia en el registro de errores del servidor de MySQL. Ver Sección

19.4.6, "El evento de la agenda y los privilegios de MySQL" para un ejemplo.

La información sobre el estado del evento de la agenda para la depuración y solución de

problemas de los propósitos se pueden obtener mediante la ejecución de mysqladmin

debug (ver Sección 4.5.2, "   mysqladmin   - Administrar un servidor MySQL "  ); después de

ejecutar este comando, el registro de errores del servidor contiene la producción en relación a

la agenda de eventos, de forma similar a lo que se muestra a continuación:Eventos de estado:

LLA = Última Cerrado En LUA = Última Desbloqueado En

WOC = Esperando A condición de DL = Datos Cerrado

Planificación de eventos de estado:

Estado: INICIALIZADA

Identificación del Tema: 0

LLA: init_scheduler: 313

LUA: init_scheduler: 318

WOC: NO

Trabajadores: 0

Ejecutado: 0

Datos bloqueado: NO

Evento estado de la cola:

Número de elementos: 1

Datos bloqueado: NO

El intento de bloqueo: NO

LLA: init_queue: 148

LUA: init_queue: 168

WOC: NO

A continuación la activación: 0000-00-00 00:00:00

En declaraciones que se producen como parte de los actos ejecutados por el evento de la

agenda, mensajes de diagnóstico (no sólo errores, sino también las advertencias) se escriben

en el registro de errores y, en Windows, en el registro de sucesos de aplicación. Para eventos

frecuentemente ejecutadas, es posible para que esto resultará en muchos mensajes

registrados. Por ejemplo, para SELECT ... EN var_list declaraciones, si la consulta no

devuelve ninguna fila, una advertencia con el código de error 1329 se produce ( No hay

datos ), y los valores de las variables permanecen sin cambios. Si la consulta devuelve varias

filas, se produce error 1172 (Resultado compuesto de mas de una fila ). Para

cualquiera de estas condiciones, usted puede evitar que las advertencias de estar conectado

al declarar un manejador de condiciones, véase la sección 13.6.7.2,

" DECLARE ...   MANIPULADOR   sintaxis "  . Por las declaraciones que pueden recuperar varias

filas, otra estrategia es utilizar LIMIT 1 para limitar el conjunto de resultados a una sola fila.

Para activar o desactivar la ejecución de los eventos programados, es necesario establecer el

valor de lo globalevent_scheduler variable del sistema. Esto requiere que

el super privilegio.

El CASO privilegio rige la creación, modificación y eliminación de los acontecimientos. Este

privilegio se le puede dar con GRANT . Por ejemplo, este GRANT declaración confiere

el CASO privilegio para el esquema nombradomyschema en el usuario jon @ ghidora :

CONCESIÓN DE EVENTOS EN myschema * a Jon @ ghidora.;

(Se supone que esta cuenta de usuario ya existe, y que deseamos que se mantenga sin

cambios lo contrario.)

Para otorgar este mismo usuario del CASO privilegios en todos los esquemas, utilice la

siguiente declaración:CONCESIÓN DE EVENTOS ON * * a Jon @ ghidora.;

El CASO privilegio tiene un alcance global o esquema de nivel. Por lo tanto, tratando de otorgar

resultados en una sola tabla en un error como se muestra:mysql> GRANT EN CASO myschema.mytable a Jon @ ghidora;

ERROR 1144 (42000): El comando ilegal GRANT / REVOKE, por favor

consulte el manual para ver qué permisos pueden ser usados

Es importante entender que un evento se ejecuta con los privilegios de su definidor, y que no

puede realizar ninguna acción por lo que su definidor no tiene los privilegios necesarios. Por

ejemplo, supongamos que jon @ ghidora tiene CASO privilegio

para myschema . Supongamos también que este usuario tiene la SELECT privilegio

para myschema , pero no otros privilegios para este esquema. Es posible que jon @

ghidora para crear un nuevo evento como este:

CREAR EVENTOS e_store_ts

EN EL HORARIO

CADA 10 segundos

HACER

INSERT INTO VALORES myschema.mytable UNIX_TIMESTAMP (());

El usuario espera un minuto o así, y luego realiza un SELECT * FROM mitabla; consulta,

esperando ver a varias nuevas filas en la tabla. En su lugar, la tabla está vacía. Dado que el

usuario no tiene el INSERT privilegio de la tabla en cuestión, el evento no tiene ningún efecto.

Si usted examina el registro de errores de MySQL ( nombre de host . err ), se puede ver

que el evento se está ejecutando, pero la acción que está intentando realizar no, según lo

indicado por retcode = 0 :

060209 22:39:44 [Nota] caso Evex EJECUTOR newdb.e [expr: 10]

060209 22:39:44 [Nota] Evex EJECUTADO caso newdb.e [expr: 10]. Retcode =

0

060209 22:39:54 [Nota] caso Evex EJECUTOR newdb.e [expr: 10]

060209 22:39:54 [Nota] Evex EJECUTADO caso newdb.e [expr: 10]. Retcode =

0

060209 22:40:04 [Nota] caso Evex EJECUTOR newdb.e [expr: 10]

060209 22:40:04 [Nota] Evex EJECUTADO caso newdb.e [expr: 10]. Retcode =

0

Dado que este usuario es muy probable que no tiene acceso al registro de error, es posible

verificar si la declaración del evento, la acción es válida si se ejecuta directamente:mysql> INSERT INTO VALORES myschema.mytable UNIX_TIMESTAMP (());

ERROR 1142 (42000): comando INSERT denegado para el usuario

'Jon' @ 'ghidora' para 'mitabla' mesa

La inspección de la INFORMATION_SCHEMA.EVENTS tabla muestra que e_store_ts existe y

está habilitado, pero su LAST_EXECUTED columna es NULL :

mysql> SELECT * FROM INFORMATION_SCHEMA.EVENTS

> DONDE EVENT_NAME = 'Los e_store_ts'

> Y EVENT_SCHEMA = 'myschema' \ G

*************************** 1. fila ***************************

EVENT_CATALOG: NULL

EVENT_SCHEMA: myschema

EVENT_NAME: e_store_ts

DEFINER: jon @ ghidora

EVENT_BODY: SQL

EVENT_DEFINITION: INSERT INTO VALORES myschema.mytable (UNIX_TIMESTAMP

())

Event_type: RECURRENTE

EXECUTE_AT: NULL

INTERVAL_VALUE: 5

INTERVAL_FIELD: SEGUNDO

Sql_mode: NULL

Inicio: 0000-00-00 00:00:00

Finaliza: 0000-00-00 00:00:00

ESTADO: HABILITADO

ON_COMPLETION: no conserva

CREADO: 02/09/2006 22:36:06

LAST_ALTERED: 02/09/2006 22:36:06

LAST_EXECUTED: NULL

EVENT_COMMENT:

1 row in set (0.00 sec)

Para rescindir el CASO privilegio, utilizar el REVOKE declaración. En este ejemplo,

el CASO privilegio en el esquemamyschema se retira de la jon @ ghidora cuenta de usuario:

CASO DE REVOCAR * myschema de jon @ ghidora.;

Importante

Revocar la EVENTO privilegios de un usuario no se elimina o desactivar los eventos que

pueden haber sido creados por el usuario.

Un evento no se migra o se ha caído como resultado del cambio de nombre o eliminar el

usuario que lo creó.

Supongamos que el usuario jon @ ghidora le ha concedido la CASO y INSERT privilegios en

el myschemaesquema. Este usuario a continuación, crea el siguiente evento:

CREATE EVENT e_insert

EN EL HORARIO

CADA SEGUNDO 7

HACER

INSERT INTO myschema.mytable;

Después de este evento se ha creado, la raíz revoca el CASO privilegio para jon @

ghidora . Sin embargo,e_insert continúa ejecutando, insertar una nueva fila

en mitabla cada siete segundos. Lo mismo sería cierto sila raíz había emitido ninguna de

estas declaraciones:

DROP USER jon @ ghidora;

Cambiar nombre de usuario jon @ ghidora A someotherguy @ ghidora;

Puede comprobar que esto es cierto, examinando la mysql.event mesa (explicado más

adelante en esta sección) o el INFORMATION_SCHEMA.EVENTS tabla (véase la Sección 20.7,

"El   EVENTOS INFORMATION_SCHEMA Tabla "  ) antes y después de la emisión de un DROP

USER o RENAME USER declaración .

Definiciones de eventos se almacenan en la mysql.event tabla. Para excluir a un evento

creado por otra cuenta de usuario, el MySQL raíz de usuario (u otro usuario con los

privilegios necesarios) puede eliminar las filas de esta tabla. Por ejemplo, para eliminar el

evento e_insert se indica anteriormente, la raíz se puede utilizar la siguiente declaración:

DELETE FROM mysql.event

Donde db = 'myschema'

Y definidor = 'jon @ ghidora'

Y el nombre = 'e_insert';

Es muy importante para que coincida con el nombre del evento, nombre de esquema de base

de datos, y la cuenta de usuario cuando se eliminan las filas de la mysql.event mesa. Esto

es porque el mismo usuario puede crear eventos diferentes con el mismo nombre en

diferentes esquemas.

De los usuarios EVENTO permisos se almacenan en los Event_priv columnas de

la mysql.user y mysql.dbtablas. En ambos casos, esta columna tiene uno de los valores

de Y 'o' N '. ' N 'es el valor predeterminado.mysql.user.Event_priv se establece en ' Y 'para

que un usuario sólo en caso de que el usuario tiene el mundial CASO privilegio (es decir, si el

privilegio fue otorgado con gran evento ON *. * ). Para un nivel de

esquema CASO privilegio GRANT crea una fila en mysql.db y establece que la fila Db columna

para el nombre del esquema, el usuario columna para el nombre del usuario, y

el Event_priv columna a ' Y '. Nunca debe haber ninguna necesidad de manipular estas

tablas directamente, ya que el gran evento y REVOKE EVENTOdeclaraciones realizar las

operaciones necesarias sobre ellos.

Cinco variables de estado de proporcionar cantidades de caso relacionados con las

operaciones (pero no de las declaraciones realizadas por los acontecimientos, ver Sección

D.1, "Restricciones a programas almacenados" ).Estos son:

Com_create_event : El número de CREATE EVENT instrucciones ejecutadas desde el

reinicio del servidor últimos.

Com_alter_event : El número de ALTER EVENT instrucciones ejecutadas desde el reinicio

del servidor últimos.

Com_drop_event : El número de evento de colocación instrucciones ejecutadas

desde el reinicio del servidor últimos.

Com_show_create_event : El número de SHOW CREATE EVENT instrucciones ejecutadas

desde el reinicio del servidor últimos.

Com_show_events : El número de Show Events instrucciones ejecutadas desde el reinicio

del servidor últimos.

Puede ver los valores actuales de todos ellos al mismo tiempo mediante la ejecución de la

sentencia SHOW STATUS LIKE '%% evento; .