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; .
Top Related