Mejora en las consultas anidadas en MySQL6

ByLuis

Buena noticia de rendimiento en la futura versión de MySQL. En este caso se trata de las consultas anidadas dentro de MySQL, pongamos un ejemplo.

Si tenemos esta consulta:

select title, from_date, to_date
from titles
where emp_no in
(select emp_no
from employees
where first_name = 'Mary'
and last_name = 'Sluis'
)

En MySQL5 (usando estos datos) obtendríamos el resultado (1 fila) en 7.88 segundos, mientras que en MySQL6 tardaría 0.13 segundos.

El motivo parece ser que MySQL transforma la subconsulta en un join.

Drizzling MySQL

Similar Posts

Nueva versión de Sphinx

ByLuis

Sphinx es un buscador de texto bastante rápido y potente (pensado para bases de datos grandes), que permite ser integrado con otras bases de datos como MySQL.

Acaban de sacar la versión 0.9.8 después de 15 meses de trabajo (y justo después de que yo ayer me bajara la versión anterior y la instalara). Existen más de 70 nuevas características, de las cuales destacaría:

  • Soporte para libstemmer, permitiendo stemmers para nuevos lenguajes.
  • Posibilidad de eliminar elementos HTML.
  • Decodificar entidades HTML.
  • Añadidas nuevos modos de crear excerpts.
  • Mejorado el motor para obtener queries.
  • Nuevos modos de ordenación de resultados.
  • Nuevas APIs para Java, C y Ruby.

Sphinx

ExtSQL: Extended Usage Statistics for SQL

ByLuis

ExtSQL es una serie de modificaciones y parches realizados sobre MySQL y PostgresSQL que permiten realizar monitorizaciones e informes sobre el estado de la base de datos, del servidor, la actividad de los usuarios. Las consultas se realizan mediante queries SQL, las cuales quieren que se añadan al estándar SQL. Actualmente, la mayor parte del trabajo se ha realizado en MySQL, ya que están a la espera de la respuesta de la comunidad de PostgreSQL.

Por ejemplo, para saber el número de selects e inserts realizados por todos los usuarios desde que el servidor arrancó, sería así:

SHOW STATISTICS Com_select, Com_insert, Questions FROM user;

Dando el siguiente resultado:

+----------+-------------+------------+------------+
| user     | Com_select  | Com_insert | Questions  |
+----------+-------------+------------+------------+
| bandala  | 8302675     | 95973      | 23153940   |
| sandymao | 1702812     | 6205       | 3829023    |
| ponnetli | 24909       | 4784       | 95646      |

ExtSQL

Vía / VivaLinux

Gracias David por el aviso

Optimizar MYSQL seleccionando correctamente los tipos de los campos

ByLuis

Algo muy importante para desarrollar una aplicación web es diseñar correctamente la base de datos MySQL, en este caso los tipos de los campos.
Algunos errores que se suelen cometer es por ejemplo usar texto para almacenar cantidades de dinero porque aparece el carácter de la moneda, cuando lo más lógico es formatear el valor obtenido en la base de datos en tus páginas.
Por ello lo primero es saber qué tipo de campo vamos a usar, numérico o texto, y luego saber qué subtipo seleccionar. Debemos tener en cuenta dos factores, cuánto espacio en disco ocupa y cuánto tiempo de proceso requiere.
Por ello, no es lo mismo seleccionar un CHAR que un VARCHAR, CHAR tiene ancho fijo, pero VARCHAR es más rápido de procesar, debemos tener en cuenta si nuestra base de datos va a ocupar poco o si necesita rapidez y actuar en consecuencia seleccionando el tipo correcto para los campos de las tablas.
Leed más, sobre todo la comparativa de tipos de campos, en el siguiente artículo.
Making your MySQL Tables More Effeciant by Using Correct Fieldtypes
Vía / dzone

Hacer un split en MySQL

ByLuis

Normalmente no se suelen necesitar hacer splits en MySQL, porque un buen diseño de la BD debería almacenar los campos en distintas columnas, y si no se puede realizar así, se suele guardar la información serializada en PHP o en formato JSON o XML. Pero no siempre son las cosas como queremos y alguna vez nos podemos encontrar con la necesidad de hacer un split de un campo en MySQL (como me ha pasado a mi ahora).

Hacerlo es fácil, solo es necesario hacer dos substrings, por cada campo:

SELECT `ip` ,
SUBSTRING_INDEX( `ip` , '.', 1 ) AS a,
SUBSTRING_INDEX(SUBSTRING_INDEX( `ip` , '.', 2 ),'.',-1) AS b,
SUBSTRING_INDEX(SUBSTRING_INDEX( `ip` , '.', -2 ),'.',1) AS c,
SUBSTRING_INDEX( `ip` , '.', -1 ) AS d
FROM log_table

MySQL String Functions

Curiosidades sobre TIMESTAMP en MySQL

ByLuis

Interesante lo que descubre uno sobre el TIMESTAMP en MySQL:

  • Por defecto TIMESTAMP es NOT NULL, insertar un NULL hace que se almacene el DATETIME actual
  • TIMESTAMP puede tener un valor entre ‘1970-01-01 00:00:01′ y ‘2038-01-19 03:14:07′
  • Solo la primera columna con NOT NULL puede tener por defecto la propiedad CURRENT_TIMESTAMP
  • Cuando CURRENT_TIMESTAMP se indica como ON UPDATE esa columna no se actualiza si no hay cambios significativos (por ejemplo al hacer dos updates iguales)

Interesting things about TIMESTAMP data type in MySQL

5 consejos para optimizar sentencias en MySQL

ByLuis

Interesantes consejos a tener en cuenta cuando realizamos nuestras aplicaciones usando MySQL:

  • Optimización de tipos: intenta evitar el uso de NULLs ya que requieren más operaciones internas en MySQL. Usa el tamaño correcto para las variables, por ejemplo, si vas a usar un número pequeño no uses INT.
  • Cuidado con la codificación de caracteres: inserta los datos siempre en la misma codificación, si tienes orígenes con diferentes codificaciones modificalo antes de insertar.
  • Optimización de COUNT: COUNT(*) sin un WHERE no necesita acceder a la tabla para obtener los resultados, al igual sin en vez de asterisco usamos un campo de la tabla que no tenga valores NULL. En el caso de que haya WHERE, poco se puede hacer para optimizar la consulta salvo usar índices correctamente.
  • Optimización de subqueries: MySQL no optimiza muy bien las subqueries por lo que es preferibles pasarlas a una JOIN. Incluso realizar dividir en dos queries independientes puede ser una buena alternativa.
  • Optimización de UNION: UNION devuelve la unión de los datos de dos tablas que no se hayan en la otra, por lo que realizan un UNIQUE y una ordenación. Usa UNION ALL si estás seguro de que las distintas consultas no tienen datos repetidos (o no te importa que esté repetidos).

Five Query Optimizations in MySQL