La próxima versión de Microsoft SQL Server 2016 parece que se va a poder ver ya este verano, primeramente en formato preview. Con el cambio de versión se incluyen como siempre nuevas características entre las que destacan mejoras relacionadas con su integración con Microsoft Azure, integración con el lenguaje de programación estadístico R y alguna cosa más en cuanto a mejoras de rendimiento. A continuación una breve reseña..

En mysql los triggers que existen son básicos y solo a nivel de tabla. No existe como en SqlServer o Oracle un trigger que permita cazar las conexiones que se abren y obtener cierta información complementaria referente a las sesiones.
Un mal ejemplo. Se puede dar el caso que en un entorno web tengamos un granja de servidores apache y por lo que sea a alguno se le va la olla. Empieza a abrir threads en nuestro mysql de forma masiva (por el motivo que sea) y nos colapsa el servidor porque no tenemos limitidas el número de conexiones simultaneas para ese usuario. ¿Que mal rollo no? Y si encima esto pasa cuando no estamos en la oficina nos podemos encontrar que no podemos saber mucho de lo que ha pasado, por ejemplo vemos el pico en cacti pero no tenemos detalle.

Para tener algo más y poder auditar cuando y quien abre conexiones, haremos lo siguiente:  

1. Creamos schema un schema (o no).

De vez en cuando puede pasar que dos sesiones que se pisen se bloqueen al intentar hacer cambios en los mismos datos (a nivel de registro o a nivel de tabla). En sistemas no concurrentes y/o bien diseñados no tiene por que pasar ya que las aplicaciones suelen estar mínimamente pensadas para evitarlo; o en todo caso en pruebas pre-producción ya se detecta y se corrige. El caso es que incluso aunque se planee evitarlos se pueden producir. En la mayoría de casos se resuelven solitos al acabar de realizar los cambios la sesión bloqueante, incluso ni nos daremos cuenta. En otros casos más infrecuentes se producen bloqueos circulares irresolubles, “deadlocks”, donde se acaba haciendo rollback de una transacción y se genera una entrada en el fichero de alerta:

ORA-00060: Deadlock detected. More info in file /opt/oracle/admin/XXX/udump/XXX_ora_28205.trc

Recientemente he pasado un entorno mysql de la versión 5.0.32 a una más reciente que ya incluye la base de datos information_schema con tablas de metadatos equivalentes a algunos comandos SHOW ya disponibles anteriormente.
"INFORMATION_SCHEMA es la base de datos de información, que almacena información acerca de todas las otras bases de datos que mantiene el servidor MySQL. Dentro del INFORMATION_SCHEMA hay varias tablas de sólo lectura. En realidad son vistas, no tablas, así que no puede ver ningún fichero asociado con ellas. Cada usuario MySQL tiene derecho a acceder a estas tablas, pero sólo a los registros que se corresponden a los objetos a los que tiene permiso de acceso. "..

A MySql le acompaña mysqlslap (creo que a partir de 5.x), un ejecutable que permite hacer ejecuciones de scripts masivas para simular carga la carga de trabajo en el servidor generada por clientes mysql. Le podemos pasar un script de preparación y un script de consultas DML sobre el que medir tiempos. Con esto lo interesante también es que podemos obtener el tiempo mínimo, máximo y medio con distintas concurrencias.

Podemos empezar con un ejemplo básico con script de creación y de carga...