La selectividad es la relación que hay entre el número de valores posibles en una columna, y el número total de registros. La mejor selectividad es 1, y ocurre cuando hay tantos valores posibles como registros presentes, precisamente en el caso de una clave primaria sobre una columna; la peor selectividad es la que tiende a 0, y ocurre cuando hay muy pocos valores posibles en relación a los registros presentes, por ejemplo una columna sexo.

De esta manera, no es eficiente crear índices para columnas que tienen un número pequeño de posible valores. Incluso he leído, que un optimizador de consultas decente ignorará la presencia de un índice sobre esa columna con poco valores distintos, porque notará que la selectividad es muy baja.

A través del Snipplr de un compañero de trabajo, descubro un interesante script que retorna los 10 índices de MySQL con el peor rendimiento:

/*
SQL script to grab the worst performing indexes
in the whole server
*/
SELECT
  t.TABLE_SCHEMA AS `db`
 , t.TABLE_NAME AS `table`
 , s.INDEX_NAME AS `inde name`
 , s.COLUMN_NAME AS `field name`
 , s.SEQ_IN_INDEX `seq in index`
 , s2.max_columns AS `# cols`
 , s.CARDINALITY AS `card`
 , t.TABLE_ROWS AS `est rows`
 , ROUND(((s.CARDINALITY / IFNULL(t.TABLE_ROWS, 0.01)) * 100), 2) AS `sel %`
FROM INFORMATION_SCHEMA.STATISTICS s
 INNER JOIN INFORMATION_SCHEMA.TABLES t
  ON s.TABLE_SCHEMA = t.TABLE_SCHEMA
  AND s.TABLE_NAME = t.TABLE_NAME
 INNER JOIN (
  SELECT
     TABLE_SCHEMA
   , TABLE_NAME
   , INDEX_NAME
   , MAX(SEQ_IN_INDEX) AS max_columns
  FROM INFORMATION_SCHEMA.STATISTICS
  WHERE TABLE_SCHEMA != 'mysql'
  GROUP BY TABLE_SCHEMA, TABLE_NAME, INDEX_NAME
 ) AS s2
 ON s.TABLE_SCHEMA = s2.TABLE_SCHEMA
 AND s.TABLE_NAME = s2.TABLE_NAME
 AND s.INDEX_NAME = s2.INDEX_NAME
WHERE t.TABLE_SCHEMA != 'mysql'                         /* Filter out the mysql system DB */
AND t.TABLE_ROWS > 10                                   /* Only tables with some rows */
AND s.CARDINALITY IS NOT NULL                           /* Need at least one non-NULL value in the field */
AND (s.CARDINALITY / IFNULL(t.TABLE_ROWS, 0.01)) < 1.00 /* Selectivity < 1.0 b/c unique indexes are perfect anyway */
ORDER BY `sel %`, s.TABLE_SCHEMA, s.TABLE_NAME          /* Switch to `sel %` DESC for best non-unique indexes */
LIMIT 10;

Un ejemplo del resultado de esta consulta en un proyecto en producción, retorna índices de campos booleanos o campos que indican el sexo:

Entradas relacionadas:

1. Diferencias entre ENUM y SET en MySQL
2. Trabajando con el tipo de campo BIT de MySQL en PHP
3. Función GROUP_CONCAT de MySQL

• mysql es la API histórica que ofrece PHP desde hay varias versiones.
• mysqli es la nueva versión de mysql, orientada a objetos.
• PDO es una capa de abstracción de base de datos, con soporte para MySQL y otros sistemas gestores de bases de datos. Proporciona comandos preparados y otra serie de operaciones adaptadas al driver necesario.

Si no hubiera ningún motivo que hiciera variar la elección, se recomienda usar PDO; y si no es posible, entonces mysqli. Como último recurso, usar mysql. Visto en stackowerflow

ACTUALIZACIÓN (2010/08/01): En el foro "Foros del web", se abrío un hilo hace meses, hablando de los pros y contras sobre PDO o MySQLi. Desde ahí, se puede acceder a un artículo muy interesante del blog TuFunción: "PHP y MySql: una estrecha relación". Se muestran los resultados de unos test. para comprobar el rendimiento de los diferentes drivers. El driver MySqli demuestra un rendimiento de casi el doble respecto a PDO.

Las conclusiones del artículo son:

• Rendimiento: MySqli o MySql
• Características: MySqli
• Facilidad de uso: PDO

Entradas relacionadas:

1. Diferencias entre ENUM y SET en MySQL
2. Trabajando con el tipo de campo BIT de MySQL en PHP
3. Diferencias entre URL, URI y URN

Al tipo de datos BIT se le puede especificar el número de bits, que va de 1 a 64. Si no se especifica, por defecto se toma que BIT solo contiene un bit. Para especificar los valores en MySQL, se puede utilizar una notación que muestro con el siguiente ejemplo, en que tengo una tabla de jugadores, con su ID que es un número y el vampo ‘lesionado’ que es un BIT(2):

INSERT INTO jugador (idjugador, lesionado)
	VALUES (1, b'01'), (2, b'11');

Existen otras notaciones para también pasar valores hexadecimales o octales. Para ver unos ejemplos, entrad en el siguiente enlace.

Si viéramos los valores desde el phpmyadmin, veríamos símbolos raros. En realidad intentan representar los valores del campo. Si hicieramos una consulta desde PHP a la base de datos, veriamos el mismo valor al hacer un echo o un var_dump. El valor que nos retorna es el carácter ASCii que concuerda con los bits almacenados.

Para poder trabajar con esos valores para hacer comparaciones o demás operaciones, necesitamos las funciones ord y chr de PHP. La función ord nos devuelve el número decimal de un carácter ASCii pasado por parámetro.

En el ejemplo, es una tontería usar 2 bits, ya que con un bit puedo guardar el estado, si esta lesionado o no el jugador. Pero he usado dos bits para que se entienda mejor que la función ord devuelve el valor decimal (’11′ en decimal es un 3).

$registros = mysql_query("SELECT idjugador, lesionado
				FROM jugador");
while ($reg = mysql_fetch_assoc($registros)) {
	echo $reg['idjugador'];
	if (ord($reg['lesionado']) == 1) {
		echo "No esta lesionado";
	}
	else if (ord($reg['lesionado']) == 3) {
		echo "Esta lesionado";
	}
}

Cuando queramos pasar un valor a la base de datos, ya sea para hacer un INSERT o un UPDATE, hemos de utilizar la función chr, que nos convierte un número decimal en su representación en ASCii.

mysql_query("UPDATE jugador
	SET lesionado = '" . chr(2) . "'
	WHERE idjugador=1");

Todo y las explicaciones, creo que no es muy recomendable usar este tipo de dato, principalmente por dos motivos:

• Ocupa más espacio del número de bits que le asignamos
• Necesita una transformación para ser utilitzado en PHP

Despendiendo de lo que necesitemos, sería más conveniente un TINYINT o un SET.

Entradas relacionadas:

1. Diferencias entre ENUM y SET en MySQL
2. Diferencias entre mysql, mysqli y PDO en PHP
3. Función GROUP_CONCAT de MySQL

Tenemos dos tablas, Contenidos y Categorías (o cualquier relación típica de 1:N o N:N). El objetivo es sacar todos los contenidos, y en cada registro de contenidos, las categorías de cada uno de ellos.

Si hiciéramos una consulta en que relacionamos las tablas, hicieramos el GROUP BY, y pidieramos los campos nombre_contenido y nombre_categoria, solamente retornaría el nombre de una categoría, la primera que encuentre:

SELECT nombre_contenido, nombre_categoria
FROM contenidos
	INNER JOIN categorias_contenidos USING (id_contenido)
	INNER JOIN categorias USING (id_categoria)
GROUP BY id_contenido

Pero con la función GROUP_CONCAT, todas las Categorías que se ven agrupadas por el GROUP BY, serán concatenadas en un campo, con una coma como separador.

SELECT nombre_contenido, GROUP_CONCAT(nombre_categoria)
FROM contenidos
	INNER JOIN categorias_contenidos USING (id_contenido)
	INNER JOIN categorias USING (id_categoria)
GROUP BY id_contenido

La función GROUP_CONCAT solo tiene un parámetro, que es una expresión. Básicamente puede ser el nombre de la columna a concatenar. Pero permite tres personalizaciones, según nuestras necesidades:

• Utilizar DISTINCT, para evitar las repeticiones
• Añadir un ORDER BY, para decidir el orden de concatenación del campo
• Definir con SEPARATOR el separador a utilizar para separar los campos (por defecto, el separador es una coma)

Pongo un ejemplo completo con todas las funcionalidades de GROUP_CONCAT, así no tendremos repeticiones de las categorías, estarán ordenadas alfabéticamente y separadas por un guión:

SELECT nombre_contenido, GROUP_CONCAT(DISTINCT nombre_categoria
					ORDER BY nombre_categoria ASC
					SEPARATOR '-')
FROM contenidos
	INNER JOIN categorias_contenidos USING (id_contenido)
	INNER JOIN categorias USING (id_categoria)
GROUP BY id_contenido

Una vez recibido el registro, podemos convertir este campo concatenado en un array, simplemente utilizando la función explode de PHP.

Actualización: A través del comentario de Daniel, me entero que la función tiene un límite de 1024 caracteres, incluidos los separadores. En un ejemplo que he visto, he leído que en una consulta en que la función GROUP_CONCAT tenía que devolver del 1 al 20.000 separados por comas, solo devolvía hasta el 283; los números cuadran de la siguiente manera:

• Del 1 al 9, van 9 caracteres
• Del 10 al 99, van 90*2= 180 caracteres
• Del 100 al 283, van 184*3= 552 caracteres
• Más las 283 comas, que son 283 carácteres más
• TOTAL = 9 + 180 + 552 + 283 = 1024 caracteres.

Pero esto no es un inconveniente para utilizar la función GROUP_CONCAT. Este límite se puede modificar a nuestro gusto, de las dos maneras siguientes:

1. Editando el archivo de configuración my.cnf y modificando la variable:

   group_concat_max_len=4096

2. Ejecutando esta orden antes de realizar la consulta:

   SET GLOBAL group_concat_max_len=4096

Fuentes – Syntax Error y MySQL Performance Blog (mirar también los comentarios)

Entradas relacionadas:

1. La selectividad de los índices en MySQL
2. Trabajando con el tipo de campo BIT de MySQL en PHP
3. Diferencias entre mysql, mysqli y PDO en PHP

Tanto ENUM como SET, sirven para determinar los valores que puede tener un campo de una tabla, es decir, puedes determinar que en un campo solamente pueda contener valores de una lista definida por ti. La principal diferencia es que un campo del tipo ENUM siempre contiene sólo un valor de la lista; y un campo del tipo SET puede contener ninguno, uno o varios valores de la lista.

Hay más características de estos dos campos de MySQL, que les hace diferenciarse y es necesario conocerlas para decidir cual es más apropiado para nuestro diseño de la base de datos.

El tipo de campo ENUM se caracteriza por:

CREATE TABLE sizes (
	size ENUM('small', 'medium', 'large') NOT NULL DEFAULT 'medium'
);

• Sólo contiene un valor
• Se puede definir la lista de hasta 65535 valores distintos
• Si se permite NULL, este será el valor por defecto; sinó, y si no se define con DEFAULT, será el primer valor de la lista (en el ejemplo de arriba, si no defino el DEFAULT ‘medium’, por defecto sería ‘small’)
• Cada valor de la lista es numerado con un índice (empieza desde el 1), pudiendo usar el índice en vez del valor de la lista (en el ejemplo de arriba: 1=>’small’, 2=>’medium’ y 3=>’large’)
• En caso de introducir un valor no perteciente a la lista, el campo pasará a valer ”, una cadena vacía, que tiene el índice zero
• El índice de NULL es NULL,
• Para retornar el índice de un campo del tipo ENUM, podemos sumar zero al campo (SELECT size+0 FROM …)
• De almacenamiento físico, ocupará 1 byte si hay 255 o menos valores en la lista, o 2 bytes si hay 256 o más valores

El tipo de campo SET se caracteriza por:

CREATE TABLE letters (
	letter SET('a', 'b', 'c', 'd')
);

• Contiene zero, uno o varios valores
• Se puede definir la lista de hasta 64 valores distintos
• Los valores no pueden contener comas, ya que los valores asignados son separados por comas
• Cada valor de la lista representa un bit de la cadena de bits del campo
• El valor decimal del campo determina los bits, marcando los valores que contiene el campo,de manera que si todos los bits estan a 1, es que ese campo contiene todos los valores (ejemplo: si el valor decimal es 7, en binario sería 0111, y eso quiere decir que el campo contiene los valore ‘a’, ‘b’ y ‘c’)
  

  SET	Decimal	Bytes
  ‘a’	1	0001
  ‘b’	2	0010
  ‘c’	4	0100
  ‘d’	8	1000

• De almacenamiento físico, ocupará 1, 2, 3, 4, o 8 bytes, según la longitud de la lista de valores (si N es el número de valores, la formula es (N+7)/8 bytes)

Conociendo más a fondo los tipos de campos, y sabiendo sus posibilidades, ahora es fácil decidirse y justicarse.

Entradas relacionadas:

1. Diferencias entre mysql, mysqli y PDO en PHP
2. Trabajando con el tipo de campo BIT de MySQL en PHP
3. Diferencias entre URL, URI y URN

Pero se puede dar el caso, de que se quieren incremenetar una serie de registros a la vez. Por poner otro ejemplo, tenemos una tabla de tags, donde se almacenan las veces que son asignadas a una entrada. Cuando se crea una entrada, hay que incrementar todas las tags que tiene la entrada asignadas.

A la hora de programarlo, tenemos tres opciones:

• Por código, se hace una llamada a la procedure por cada tag que tiene la entrada asignada, haciendo tantas llamadas a la procedure como tags asignadas.
• Modificamos la procedure anterior, para que reciba una cadena de tags con un separador, así la procedure se encarga de ir cortando y cogiendo las tags y incrementandolas.

CREATE PROCEDURE increment_tags (tags VARCHAR(100000))
BEGIN
	DECLARE tag VARCHAR(10);	--Variable donde se irán guardando las tags
 
	WHILE LENGTH(tags)>0 DO
		SET tag = SUBSTRING_INDEX(tags, ',', 1);	--El separador es una coma
		SET tags = SUBSTR (tags, LENGTH(tag)+2);	--La cadena de tags es recortada por el tag actual
		INSERT INTO tbl_tags (tag, ranking) VALUES (tag, 1)
			ON DUPLICATE KEY UPDATE ranking = ranking +1;
	END WHILE;
END

• Modificar la procedure que va cortando la cadena de tags para que, en vez de incrementar cada vez que coge una tag, haga una cadena de texto que seráuna sentencia preparada, un INSERT con todos las tags a incrementar, y al final la ejecute, consiguiendo una petición a la Base de Datos, y un solo INSERT.

CREATE PROCEDURE increment_tags (tags VARCHAR(100000))
BEGIN
	DECLARE tag VARCHAR(10);	--Variable donde se irán guardando las tags
	DECLARE txt_insert VARCHAR(105000) DEFAULT '';		--Contendrá el INSERT que se va formando
 
	WHILE LENGTH(tags)>0 DO
		SET tag = SUBSTRING_INDEX(tags, ',', 1);
		SET tags = SUBSTR(tags, LENGTH(tag)+2);
		SET txt_insert = CONCAT(txt_insert, ',(', tag, ', 1)');
	END WHILE;
 
	SET @sql = CONCAT('INSERT INTO tags (tag, ranking) VALUES '
					, SUBSTR(txt_insert, 2)
					, ' ON DUPLICATE KEY UPDATE ranking = ranking +1;');
	PREPARE stmt1 FROM @sql;
	EXECUTE stmt1;
	DEALLOCATE PREPARE stmt1;
END

Entradas relacionadas:

1. Procedure de estadísticas que haga un INSERT o un UPDATE (I)
2. WordPress y problemas con el módulo ModSecurity de Apache

• Si no existen estadísticas sobre este registro, se tiene que crear el registro en la tabla de estadísticas con un INSERT
• Si ya existen estadísticas, se tiene que incremenetar el valor del registro de la tabla de estadísticas con un UPDATE

Hay tres opciones a la hora de programar el sistema que incremente las estadísticas en MySQL:

• Se hace una consulta a la Base de Datos con un SELECT, para saber si ya existe el registro o no en la tabla de estadísticas. Si no existe, hacemos otra petición a la Base de Datos haciendo un INSERT, y si existe, la petición será un UPDATE. En resumen, dos peticiones a la Base de Datos, con una operación cada una.
• Se puede programar una STORED PROCEDURE que reciba el registro de las estadísticas. La Procedure se encarga de comprobar que exista el registro o no con un SELECT, y dependiendo del caso, hará la operación pertinente. En resumen, una petición a la Base de Datos, que al final ejecutará dos operaciones.

CREATE PROCEDURE `increment_stadistics`( IN uid int  )
BEGIN
DECLARE is_uid INT;
SELECT id INTO is_uid FROM stadistics WHERE id = uid LIMIT 1;
IF is_uid IS NULL THEN
INSERT INTO stadistics  (id, stats) values (uid, 1);
ELSE
UPDATE stadistics  SET stats = stats+1 WHERE id = uid LIMIT 1;
END IF;
END

• Igual que el anterior, pero directamente hacer el INSERT … ON DUPLICATE KEY UPDATE, y que él mismo detecte a traves de un índice UNIQUE que ya existe el registro, y entonces lo incremente. En resumen, una petición a la Base de Datos, y una operación, pero es necesario un índice UNIQUE que puede ser la PRIMARY KEY de la tabla si nos sirve.

CREATE PROCEDURE increment_stadistics ( IN uid int )
BEGIN
DECLARE is_uid INT;
INSERT INTO stadistics (id, stats) VALUES (uid, 1)
ON DUPLICATE KEY UPDATE stats = stats +1;
END

El inconveniente de los índices, es que cuando se modifica la tabla (INSERT, UPDATE o DELETE), se han de regenerar. El caso de índice UNIQUE, implica además que antes de hacer un INSERT, tendrá que comprobar que no se dupliquen los registros. Como va a tener que comprobarlo, si no lo encuentra, hace el INSERT, y si lo encuentra, hace el UPDATE automáticamente.

En la siguiente entrada, veremos como modificar la procedure para que haga el incremento de una serie de registros con una sola llamada a la procedure.

Entradas relacionadas:

1. Procedure de estadísticas que haga un INSERT o un UPDATE (II)

Al autor del artículo, las consultas de una aplicación le tardaban casi un minuto. Después de buscar una solución, decubrió que poniendo “SELECT STRAIGHT_JOIN …“, obligaba a MySQL a tratar las tablas de los JOINs en el orden en que se establecían, es decir, primero la de la izquierda y después la de la derecha.

Según el manual de MySQL:

STRAIGHT_JOIN is similar to JOIN, except that the left table is always read before the right table. This can be used for those (few) cases for which the join optimizer puts the tables in the wrong order.

Entradas relacionadas:

1. Diferencias entre mysql, mysqli y PDO en PHP
2. Diferencias entre ENUM y SET en MySQL
3. Función GROUP_CONCAT de MySQL