xavi

Recopilación de los mejores trucos e ideas para mejorar el rendimiento de tu BD de un servidor web.

1. SÉ CUIDADOSOEN SU DISEÑO.

Aunque parezca obvio, lo más importante a la hora de que tu BD sea rápida es que en creación haya sido la correcta.

- Haz uso de las tablas necesarias: por ejemplo, una tabla para los datos básicos del usuario y otra para sus pedidos. Nunca en una misma

- Utiliza nombres de campos y tablas que cumplan los estandars (nada de caracteres raros) y utiliza siempre el PRIMARY KEY.

2. CONOCER QUE SE PUEDE OPTIMIZAR.

Existe una instrucción muy util a la hora de optimizar tus consultas. Si usamos el comando EXPLAIN conseguiremos obtener información muy relevante sobre la consulta y poder optimizarla correctamente.

Te muestro un ejemplo de uso:

EXPLAIN SELECT * FROM wp_posts WHERE post_status = ‘publish’ LIMIT 50,103.

3.LA MEJOR CONSULTA ES ….. LA QUE NO SE HACE.

Cada consulta, aunque sea poco, hace uso de los recursos del sistema, y estos son limitados. En los sitios con gran tráfico, la mejor opción para no estar constantemente haciendo consultas repetitivas es usar tecnicas de “cache”. Más de la mitad de las consultas que se reciben ya las ha realizado el propio servidor pocos minutos antes, entonces,…., porque no guardar el resultado para cuando se vuelva a necesitar el mismo resultado?

Algunos de los más destacados que nos ayudan a “cachear” nuestras consultas són:AdoBD, Memcached, o CSQL Cache.

4. NO CONSULTES LO QUE NO NECESITAS.

Uno de los usos más típicos y más costosos para el sistema es el uso en las consultas del símbolo * para obtener resultados. En la mayoría de los casos no se necesitan siempre todos los datos de la tabla sino algunos en concreto.

El uso de el clásico “SELECT * FROM…” usa mayor recursos en la consulta y ocupa más espacio en la memoria lo que acaba ocupandola más rapidamente.

Si sólo se necesita el campo NOMBRE de la tabla USUARIOS es mucho más eficiente hacer la consulta asi:

SELECT NOMBRE FROM USUARIOS

5. LIMITA EL NUMERO DE REGISTROS.

Si no se usa el parametro LIMIT en las consultas, éstas siempre devuelven el máximo número de registros que corresponden al resultado. En la mayoria de casos NO necesitamos que se nos devuelvan todos los registros que cumplen una condición sino que solo un subconjunto de ellos.

Si queremos listar los 100 primeros registros que cumplen una condición, el uso de LIMIT mejorará notablemente el tiempo y la carga de nuestra BD.

Ejemplo: SELECT NOMBRE FROM USUARIOS LIMIT 100;

6.EVITA CONSULTAS EN BUCLES.

Cuando se usa SQL en programación por ejemplo en PHP, se tiende a introducir consultar SQL dentro de while o for. Esto puede resultar muy perjudicial para el rendimiento del gestor de base de datos.Veamos un ejemplo de un uso incorrecto y su posterior soluciónIncorrecto:

foreach ($empledo as $id => $numero) {
    $sql = "UPDATE trabajadores SET empleado = $numero WHERE id = $id";
    mysql_query($sql);
}

Correcto

UPDATE trabajadores
    SET empleado = CASE id
        WHEN 1 THEN 3
        WHEN 2 THEN 4
        WHEN 3 THEN 5
    END
WHERE id IN (1,2,3)

7. USAR JOIN EN VEZ DE SUBCONSULTAS.

Normalmente se tiene a usar la figura de la subconsulta para obtener un resultado dentro de una consulta. En la mayoria de los casos puede ser reemplaza por un join y el resultado va a ser mucho más rápido.

Ejemplo de uso de subconsultas:

SELECT a.id,
    (SELECT MAX(created)
    FROM posts
    WHERE author_id = a.id)
AS latest_post FROM authors a

Ejemplo de uso de JOIN con una ejecución mucho más rápida:

SELECT a.id, MAX(p.created) AS latest_post
FROM authors a
INNER JOIN posts p
    ON (a.id = p.author_id)
GROUP BY a.id

8. SÉ CUIDADO CON EL USO DEL COMODÍN % EN “LIKE”

El uso del comodín % en el “LIKE” para obtener resultados en una consulta se hace a menudo imprescindible. A pesar de ello debemos tener mucho cuidado ya que las consultas que usan el LIKE con los dos lados con comodín obligan al motor de la BD a trabajar al máximo rendimiento buscando en todas las filas de la BD.

Siempre que sea posible es mejor usar solo el comodín % solo como prefijo o como sufijo y solo usar ambos en casos muy muy concretos. Así mejoraremos mucho nuestra velocidad y evitaremos que nuestro motor pueda volverse loco buscando y buscando.

#LIKE con ambos comodines
SELECT * FROM clientes WHERE nombre LIKE '%Garcia%';
#Sufijo
SELECT * FROM clientes WHERE nombre LIKE  'Garcia%';
#Prefijo
SELECT * FROM clientes WHERE nombre LIKE  '%Garcia';

9. USAR “UNION” MEJOR QUE “OR”

Siempre es mejor usar la sentencia “UNION” que usar la sentencia “OR”. Para el gestor de BD es más rapido juntar dos consultas que buscar una solo con dos condiciones.

Ejemplo de uso incorrecto del “OR”

SELECT * FROM a, b WHERE a.p = b.q or a.x = b.y;

Ejemplo uso de la misma consulta con “UNION”, más rápida incluso con muchas más consultas:

SELECT * FROM a, b WHERE a.p = b.q
UNION
SELECT * FROM a, b WHERE a.x = b.y

10. USAR ÍNDICES

Los índices en Bases de Dados serian como librerias donde puedes encontrar más rapido las cosas que buscas porque están ordenadas y clasificadas por más de 1 elemento.

Un índice se puede crear de una simple columna o una convinación de varias columnas.

El campo que es un índice es el que forma la clave primaria. Eso limita a que las consultas seran rapidas sólo en el caso de buscar por la columna de la clave primaria. En muchos casos se realizan consultas de campos que no son la clave primaria. Si nos interesa que sean rápidas las consultas podemos crear un índice de ese campo.

Pero se debe ser cauteloso con la creación de índices.

Claves para NO usar índices:

- Cuando se trata de una tabla donde la mayoria de veces se realizan tareas de actualización o inserción no es aconsejable ya que cada inserción o actualización deberá modificar el índice.

- Si se trata de una columna con muy pocos valores (sexo por ejemplo) no tiene ningún sentido porque el motor de la BD igualmente deberá buscar muchos valores que cumplen la misma condición.

Ejemplo de creación de un índice:

CREATE INDEX nombreIndice ON tabla(nombrecolumna);