Está en la página 1de 53

Manual Mysql 5

INTEGRANTES:

Optimizar sentencias SELECT y otras consultas

Sintaxis de EXPLAIN (Obtener informacin acerca de un SELECT)


EXPLAIN nombre_de_table o EXPLAIN SELECT opciones_de_select La sentencia EXPLAIN puede obtener informacin acerca de cmo MySQL ejecuta una sentencia SELECT:

EXPLAIN es sinnimo de DESCRIBE. Cuando se precede una sentencia SELECT con la palabra EXPLAIN, MySQL muestra informacin del optimizador sobre el plan de ejecucin de la sentencia. Es decir, MySQL explica cmo procesara el SELECT, proporcionando tambin informacin acerca de cmo y en qu orden estn unidas (join) las tablas.

Segundo uso de EXPLAIN

EXPLAIN es una ayuda para decidir qu ndices agregar a las tablas, con el fin de que las sentencias SELECT encuentren registros ms rpidamente. EXPLAIN puede utilizarse tambin para verificar si el optimizador une (join) las tablas en el orden ptimo. Si no fuera as, se puede forzar al optimizador a unir las tablas en el orden en el que se especifican en la sentencia SELECT empezando la sentencia con SELECT STRAIGHT_JOIN en vez de simplemente SELECT. Si un ndice no est siendo utilizado por las sentencias SELECT cuando debiera, debe ejecutarse el comando ANALYZE TABLE, a fin de actualizar las estadsticas de la tabla como la cardinalidad de sus claves, que pueden afectar a la decisiones que el optimizador toma.

Lo que muestra EXPLAIN

El resultado que obtendremos ser el plan de ejecucin de la consulta a la base de datos. Una explicacin de como acceder MySQL a las diferentes columnas involucradas en la consulta. EXPLAIN devolver:

id: Es el identificador que EXPLAIN asignar a la consulta. select_type: Tipo de consulta a analizar. Por ejemplo, si se trata de una consulta sencilla su valor ser SIMPLE. table: Nombre de la tabla a la que hacen referencia el resto de datos en la fila. Hay que tener en cuenta que el orden de las filas ser el que utilizar MySQL para acceder a los datos. type: Indica como MySQL combinar los datos de esa tabla. possible_keys: Lista de los indices que se podran utilizar, aunque podra no usarse ninguno. key: ndice que finalmente se usar, si no se usa ninguno el valor del campo ser NULL. key_len: Tamao del indice utilizado, si no se us ninguno contendr NULL. ref: Muestra con que campo est relacionado el ndice seleccionado. rows: Nmero de registros que se tendrn que recuperar para ejecutar la consulta. extra: Informacin adicional sobre la forma en que se obtendrn los datos.

Con esta informacin es posible encontrar donde se producen los cuellos de botella en las consultas que realizamos a la base de datos, y nos permitir optimizarlas para evitar que una consulta lenta provoque un retraso injustificado en la devolucin de resultados a los usuarios

Estimar el rendimiento de una consulta

Estimar el rendimiento de una consulta

Para tablas pequeas, se puede encontrar una fila en una sola bsqueda (porque el ndice probablemente est en memoria). Para tablas grandes, puedes realizar la estimacin, usando los ndices de rboles-B, mediante la formula para calcular la cantidad de bsquedas necesarias para encontrar una fila:
log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1

En MySQL, un bloque de ndice es usualmente de 1024 bytes y el puntero de dato es de 4 bytes.


Para una tabla con 500,000 filas con un ndice de 3 bytes, se requerira de 4 bsquedas.

Estimar el rendimiento de una consulta

El ndice para el caso anterior tendra un tamao de 5.2MB, as que probablemente se tendra casi todo el ndice en memoria, por lo que solo se necesitara de una o 2 llamadas para encontrar una fila. Para grabar, se necesitarn 4 bsquedas para encontrar dnde ubicar el nuevo ndice y normalmente 2 bsquedas para actualizar el ndice y grabar la fila.

Velocidad de las consultas SELECT

Velocidad de las consultas SELECT

En generar para volver una consulta SELECT ms rpida, lo primero que se tiene ver es lo que se puede aadir al ndice. Todas las referencias entre tablas diferentes deben realizarse mediante ndices. Para determinar qu ndices son usados en un SELECT se puede usar EXPLAIN.

Velocidad de las consultas SELECT

Tips para incrementar la velocidad de las consultas en tablas MyISAM:

Para optimizar mejor las consultas, usar ANALYZE TABLE en una tabla, luego de que se carg con datos. Esto actualiza los valores para cada ndice indicando el nmero promedio de filas con el mismo valor. Para ordenar un ndice y los datos de acuerdo a un ndice, usar myisamchk sortindex sort-records=1. Es una buena forma de hacer consultas ms rpidas.

Optimizacin de las clusulas WHERE por parte de MySQL

Optimizacin de las clusuras WHERE por parte de MySQL

Optimizaciones realizadas por MySQL:


Remover parntesis innecesarios. Usar constantes. Eliminacin de constantes redundantes. Las constantes usadas por ndices son evaluadas una sola vez Deteccin temprana de constantes invlidas. Todas las tablas constantes son leas primero antes que otras tablas en la consulta. Se utiliza el mejor ndice a menos que el optimizador decida que es ms eficiente usar un recorrido de toda la tabla.

Optimizacin de rango

Mtodo de acceso a rango para ndices simples

Para ndices simples, los valores de los intervalos de los ndices pueden ser representados por condiciones en el WHERE, y se llaman condiciones de rango ms que intervalos. La definicin de estos, por los ndices es la siguiente:

For both BTREE and HASH indexes, comparison of a key part with a constant value is a range condition when using the =, <=>, IN, IS NULL, or IS NOT NULL operators.

For BTREE indexes, comparison of a key part with a constant value is a range condition when using the >, <, >=, <=, BETWEEN, !=, or <> operators, or LIKE 'pattern' (where 'pattern' doesn't start with a wildcard).
For all types of indexes, multiple range conditions combined with OR or AND form a range condition.

Mtodo de acceso a rango para ndices simples

Constant value en las descripciones precedentes significa uno de los siguientes:


Una constante de la cadena de consulta Una columna de una tabla const o sistema de la misma unirse El resultado de una subconsulta no correlacionada Cualquier expresin compuesta enteramente de subexpresiones de los tipos anteriores

Range Access Method for Multiple-Part Indexes

Las caractersticas varan de un ndice de mltiples partes son una extensin de las condiciones del rea de distribucin de un ndice de una sola parte. Una condicin del pastizal en un ndice de mltiples partes restringe los registros de ndice que se encuentran dentro de uno o varios intervalos tupla clave. Intervalos clave tupla se definen a travs de un conjunto de tuplas clave, mediante orden del ndice.

Index Merge Optimization

Index Merge Optimization

El ndice de mezcla (index_merge) se utiliza para recuperar filas con ref varias, ref_or_null, o escaneos de rango y combinar los resultados en una sola. Este mtodo se emplea cuando la condicin de tabla es una disyuncin de condiciones para las cuales ref, ref_or_null, o rango podra ser utilizado con claves diferentes. En EXPLAIN salida, este mtodo aparece como index_merge en la columna de tipo. En este caso, la columna de clave contiene una lista de ndices que se utilizan, y key_len contiene una lista de las ms largas de las partes fundamentales de dichos ndices.

Index Merge Intersection Access Algorithm

Este algoritmo de acceso puede ser empleada cuando una clusula WHERE se convirti a varias condiciones de alcance en diferentes claves combinadas con Y, y cada condicin es uno de los siguientes:

En esta forma, donde el ndice tiene partes exactamente n (es decir, todas las partes de ndice estn cubiertos):key_part1=const1 AND key_part2=const2 ... AND key_partN=constN Cualquier condicin por encima de rango una clave principal de una tabla InnoDB o BDB.

Algoritmo de acceso a Index Merge Union Access Algorithm

Los criterios de aplicabilidad para este algoritmo son similares a aquellos para el algoritmo de mezcla ndice de interseccin mtodo. El algoritmo se puede emplear cuando la tabla de la clusula WHERE se convirti a varias condiciones de alcance en diferentes claves combinadas con OR, y cada condicin es uno de los siguientes:

En esta forma, donde el ndice tiene partes exactamente n (es decir, todas las partes de ndice estn cubiertos): key_part1 = const1 Y key_part2 = const2 ... Y key_partN = constn Cualquier condicin por encima de rango una clave principal de una tabla InnoDB o BDB. Una condicin para que el mtodo Merge Index algoritmo de interseccin es aplicable.

Index Merge Sort-Union Access Algorithm

Este algoritmo de acceso se emplea cuando la clusula WHERE se convirti en agostadero varias combinadas con OR, pero para los cuales el ndice de Merge mtodo uni.

Aqu estn algunos ejemplos: SELECT * FROM tbl_name DONDE key_col1 <10 O key_col2 <20; SELECT * FROM nombre_tabla WHERE (key_col1> 10 O key_col2 = 20) y nonkey_col = 30; en el algoritmo no es aplicable.

La diferencia entre el algoritmo de ordenacin sindical y el algoritmo de unin es que el algoritmo de ordenacin sindical debe buscar los ID de fila para todos los registros y ordenarlos antes de regresar algn registro.

Cmo optimiza MySQL IS NULL

Cmo optimiza MySQL IS NULL

MySQL puede realizar la optimizacin del mismo en col_name IS NULL que se puede utilizar con col_name = constant_value. Por ejemplo, MySQL puede usar ndices y rangos para buscar NULL con IS NULL. Si una clusula WHERE incluye un col_name condicin IS NULL para una columna que es declarado como NOT NULL, esa expresin se ha optimizado de distancia. Esta optimizacin no se produce en los casos en que la columna podra producir NULL de todos modos, por ejemplo, si se trata de una tabla en el lado derecho de un LEFT JOIN. MySQL 5.0 tambin puede optimizar la combinacin col_name = expr Y col_name IS NULL, una forma que es comn en las subconsultas resueltas. EXPLAIN muestra ref_or_null cuando este se utiliza la optimizacin.

Esta optimizacin puede manejar un IS NULL para cualquier pieza clave.

Cmo MySQL optimiza DISTINCT

Cmo MySQL optimiza DISTINCT


DISTINCT combinado con ORDER BY necesita una tabla temporal en muchos casos. Tenga en cuenta que debido DISTINCT puede usar GROUP BY, debe ser consciente de cmo MySQL trabaja con columnas en ORDER BY o HAVING clusulas que no forman parte de las columnas seleccionadas. Consulte Seccin 12.10.3, "GROUP BY con campos Escondidos". Debido a esta equivalencia, las optimizaciones aplicables a GROUP BY consultas se pueden tambin aplicar a las consultas con una clusula DISTINCT. Por lo tanto, para obtener ms detalles sobre las posibilidades de optimizacin de consultas DISTINCT, consulte Seccin 7.2.11, "Como optimizacin de MySQL grupo Los BY". Cuando se combinan row_count LIMIT con DISTINCT, MySQL se detiene tan pronto como encuentre ROW_COUNT filas nicas.

Cmo optimiza MySQL los LEFT JOIN y RIGHT JOIN

Cmo optimiza MySQL los LEFT JOIN y RIGHT JOIN

Una A LEFT JOIN condicin_junta B se implementa en MySQL de la siguiente manera:


Tabla B se encuentra a depender de la tabla A y todas las tablas en las que A depende. Tabla A se ajusta a depender de todas las tablas (excepto B) que se utilizan en la izquierda condicin de unin. La condicin LEFT JOIN se utiliza para decidir cmo recuperar filas de la tabla B. (En otras palabras, cualquier condicin en la clusula WHERE no se utiliza.) Todas las optimizaciones de combinacin estndar se hace, con la excepcin de que una tabla siempre se lee despus de todas las mesas de los que depende. Si hay una dependencia circular, MySQL emite un error. Todo el estndar DONDE optimizaciones se realizan. Si hay un registro en A que coincide con la clusula WHERE, pero no hay ninguna fila en B que coincide con la condicin ON, una fila B adicional se genera con todas las columnas a NULL. Si utiliza LEFT JOIN para buscar las filas que no existen en alguna tabla y tiene la siguiente prueba: col_name IS NULL en la parte WHERE, donde col_name es una columna que se declara como NOT NULL, MySQL para buscar ms filas (por una combinacin de teclas especial) despus de haber encontrado una fila que coincide con la condicin JOIN LEFT.

Cmo optimiza MySQL los LEFT JOIN y RIGHT JOIN

RIGHT JOIN se lleva a cabo de forma anloga a JOIN LEFT, con las funciones de las mesas invertidas. El optimizador de join calcula el orden en el que las tablas deben ser unidas. La mesa de lectura obligada por orden LEFT JOIN y STRAIGHT_JOIN ayuda al unirse optimizador hacer su trabajo mucho ms rpido, porque hay menos permutaciones mesa para el registro. Tenga en cuenta que esto significa que si usted hace una consulta del tipo siguiente, MySQL realiza un escaneo completo en B, porque el LEFT JOIN obliga a leer antes d: SELECT * FROM a, b c LEFT JOIN ON (= c.key a.key) d LEFT JOIN ON (= d.key a.key) DONDE b.key = d.key;

Cmo optimiza MySQL los LEFT JOIN y RIGHT JOIN


La solucin en este caso es invertir el orden en A y B se enumeran en la clusula FROM: SELECT * FROM b, c un LEFT JOIN ON (= c.key a.key) d LEFT JOIN ON (= d.key a.key) DONDE b.key = d.key; MySQL 5.0 realiza las siguientes LEFT JOIN Optimizacin: Si la condicin WHERE siempre es falsa para la fila NULL generado, el LEFT JOIN se cambia a una normal unirse. Por ejemplo, la clusula WHERE sera falso en la siguiente consulta si t2.column1 eran NULL: SELECT * FROM t1 t2 LEFT JOIN ON (column1) DONDE t2.column2 = 5; Por lo tanto, es seguro para convertir la consulta a una normal de unirse: SELECT * FROM t1, t2 DONDE t2.column2 = 5 y = t1.column1 t2.column1; Esto se puede hacer ms rpido porque MySQL puede utilizar la tabla t2 t1 mesa antes si esto se traducira en un mejor plan de consulta. Para forzar una orden de la tabla especfica, utilice STRAIGHT_JOIN.

Cmo optimiza MySQL ORDER BY

Cmo optimiza MySQL ORDER BY

En algunos casos, MySQL puede utilizar un ndice para satisfacer una clusula ORDER BY sin hacer ninguna seleccin adicional. El ndice tambin se puede utilizar incluso si el ORDER BY no coincide con el ndice exactamente, siempre y cuando todas las partes no utilizadas del ndice y de todo el orden adicional por columnas son constantes en la clusula WHERE.
SELECT * FROM t1 ORDER BY key_part1,key_part2,... ;
SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2; SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC; SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC;

Cmo optimiza MySQL ORDER BY

En algunos casos, MySQL no puede usar ndices para resolver el ORDER BY, aunque todava utiliza los ndices para buscar las filas que coincidan con la clusula WHERE. Estos casos incluyen los siguientes:
Se utiliza ORDER BY en claves diferentes: SELECT * FROM t1 POR ORDEN clave1, clave2; Se utiliza ORDER BY en la no-consecutivos partes de una tecla: SELECT * FROM t1 WHERE clave2 = constante POR ORDEN key_part2; Usted mezcla ASC y DESC: SELECT * FROM t1 POR ORDEN key_part1 DESC, key_part2 ASC; La clave utilizada para recuperar las filas no es el mismo que el utilizado en el ORDER BY: SELECT * FROM t1 WHERE clave2 = constante POR ORDEN key1; Ustedes se estn uniendo muchas tablas, y las columnas en el ORDER BY no son todos de la primera no constante tabla que se utiliza para recuperar filas. (Esta es la primera tabla de la salida de explicar que no tiene un tipo de combinacin const.) Usted tiene ORDER BY diferente y expresiones GROUP BY. El tipo de ndice de la tabla usada no permite guardar los registros en orden. Por ejemplo, esto sucede con un ndice hash en una tabla HEAP.

Cmo optimiza MySQL los GROUP BY

Cmo optimiza MySQL los GROUP BY

La forma ms general para satisfacer una clusula GROUP BY es escanear toda la tabla y crear una nueva tabla temporal donde todas las filas de cada grupo son consecutivos, y luego utilice esta tabla temporal para descubrir grupos y aplicar funciones de agregado (si lo hay). En algunos casos, MySQL es capaz de hacer mucho ms que eso, y para evitar la creacin de tablas temporales mediante el acceso de ndice. Las condiciones ms importantes para el uso de ndices para GROUP BY son que todos los atributos de las columnas GROUP BY de referencia del mismo ndice, y el ndice almacena sus claves en orden (por ejemplo, se trata de un ndice B-Tree, y no es un ndice hash). Si el uso de tablas temporales puede ser sustituido por el acceso de ndice tambin depende de qu partes de un ndice se utiliza en una consulta, las condiciones especificadas para estas partes, y las funciones agregadas seleccionadas.

Loose index scan

La manera ms eficaz es cuando el ndice se utiliza para recuperar directamente los campos de grupo. Con este mtodo de acceso, MySQL usa la propiedad de algunos tipos de ndice (por ejemplo, B-Trees) que las claves estn ordenados. Esta propiedad permite el uso de grupos de bsqueda en un ndice sin tener que considerar todas las claves en el ndice que satisfacer todas DONDE condiciones. Puesto que este mtodo de acceso considera slo una fraccin de las claves en un ndice, lo que se llama un ndice de exploracin suelto. Cuando no hay clusula WHERE, una exploracin de ndice suelto lee tantas claves como el nmero de grupos, que pueden ser un nmero mucho menor que el de todas las claves.

Tight index scan


Una exploracin de ndice ajustada puede ser o bien una exploracin de ndice completo o un rango de exploracin de ndice, dependiendo de las condiciones de la consulta.

Cuando las condiciones para una exploracin de ndice suelto no se cumplen, todava es posible para evitar la creacin de tablas temporales para GROUP BY consultas. Si se dan las condiciones de rango en la clusula WHERE, este mtodo lee slo las claves que satisfacen estas condiciones. De lo contrario, se realiza una exploracin de ndice. Dado que este mtodo lee todas las teclas en cada rango definido por la clusula WHERE, o que busque el ndice general si no hay condiciones de rango, lo que llamamos una exploracin de ndice ajustado. Tenga en cuenta que con un recorrido de ndice ajustado, la operacin de agrupamiento se realiza slo despus de que todas las claves que satisfacen las condiciones de distribucin han sido encontrados.
Para que este mtodo funcione, es suficiente que, para todas las columnas de una consulta que se refieren a partes de la clave que viene antes o entre las partes de la clave GROUP BY, hay una condicin de igualdad constante. Las constantes de las condiciones de igualdad de llenar los "huecos" en las claves de bsqueda para que sea posible la formacin de prefijos completos del ndice. Estos prefijos ndice se pueden entonces utilizar para las bsquedas de ndice. Si se requiere clasificacin del grupo por resultado, y es posible la formacin de las claves de bsqueda que son los prefijos del ndice, MySQL tambin evita las operaciones de ordenacin adicionales porque la bsqueda de prefijos en un ndice ordenado ya recupera todas las claves en orden.

Cmo optimiza MySQL las clusulas LIMIT

Cmo optimiza MySQL las clusulas LIMIT


En algunos casos, MySQL trata de una consulta de forma diferente cuando se usa LIMIT y row_count no usar HAVING: Si est seleccionando slo unas pocas filas con LIMIT, MySQL utiliza los ndices en algunos casos, cuando normalmente preferira hacer un escaneo completo de tabla. Si utiliza row_count LIMIT con ORDER BY, MySQL termina la clasificacin tan pronto como se ha encontrado en las primeras filas de la ROW_COUNT resultados ordenado, en lugar de clasificar el resultado completo. Si realiza el pedido se hace mediante el uso de un ndice, esto es muy rpido. Si un filesort se debe hacer, todas las filas que coincidan con la consulta sin la clusula LIMIT debe ser seleccionado, y la mayor parte o la totalidad de ellos debe ser resuelto, antes de que se pueda determinar que las filas ROW_COUNT primero se han encontrado. En cualquier caso, una vez que las filas se han encontrado, no hay necesidad de separar cualquier resto del conjunto de resultados, y MySQL no lo hace. Cuando se combinan row_count LIMIT con DISTINCT, MySQL se detiene tan pronto como encuentre ROW_COUNT filas nicas. En algunos casos, un GROUP BY se puede resolver mediante la lectura de la llave en orden (o haciendo una especie en la tecla) y calculando a continuacin resmenes hasta que los cambios de valor de clave. En este caso, row_count lmite no se calcula ninguna GRUPO innecesario por los valores. Tan pronto como MySQL se ha enviado el nmero necesario de lneas al cliente, se aborta la consulta a menos que utilice SQL_CALC_FOUND_ROWS. LIMIT 0 rpidamente devuelve un conjunto vaco. Esto puede ser til para comprobar la validez de una consulta. Cuando se utiliza una de las API MySQL, tambin se pueden emplear para la obtencin de los tipos de las columnas de resultados. (Este truco no funciona en el monitor de MySQL, que se limita a mostrar configuraciones vaco en estos casos, usted debera usar SHOW COLUMNS o DESCRIBE para este propsito.) Si el servidor utiliza tablas temporales para resolver la consulta, la clusula LIMIT row_count se utiliza para calcular la cantidad de espacio requerido.

Cmo evitar lecturas completas de tablas

Cmo evitar lecturas completas de tablas

La salida de EXPLAIN muestra ALL en la columna de tipo cuando MySQL utiliza una exploracin de tabla para resolver una consulta. Esto sucede generalmente en las siguientes condiciones:

La tabla es tan pequeo que es ms rpido para realizar una exploracin de la tabla de una clave de bsqueda. Esto es comn para las tablas con menos de 10 filas y una longitud de fila corta. No hay restricciones que puedan utilizarse en la clusula ON o WHERE para las columnas indizadas. Usted est comparando las columnas indizadas con valores constantes y MySQL se ha calculado (basado en el ndice de rbol) que las constantes de cubrir una parte demasiado grande de la mesa y que una exploracin de tabla sera ms rpido Est utilizando una llave con cardinalidad baja (muchas filas que coincida con el valor de la clave) a travs de otra columna. En este caso, MySQL asume que mediante el uso de la clave que probablemente hace un montn de bsquedas de claves y que una exploracin de tabla sera ms rpido.

Cmo evitar lecturas completas de tablas

Para las tablas pequeas, una mesa de exploracin con frecuencia es apropiado. Para tablas grandes, pruebe las siguientes tcnicas para evitar que el optimizador incorrectamente elegir un recorrido de tabla:

Use ANALYZE TABLE tbl_name para actualizar las distribuciones clave para la tabla analizada. Use FORCE para la tabla escaneada a decir a MySQL que los recorridos de tablas son muy caros en comparacin con el uso del ndice dado.
SELECT * FROM t1, t2 FORCE INDEX (index_for_column) WHERE t1.col_name=t2.col_name;

Inicie mysqld with the --max-seeks-for-key=1000 option or use SET max_seeks_for_key=1000 para decir al optimizador que asumir que no scan causas clave de ms de 1.000 clave tiene.

Velocidad de la sentencia INSERT

Velocidad de la sentencia INSERT

El tiempo necesario para insertar un registro est determinada por los siguientes factores, donde los nmeros indican proporciones aproximadas: Connecting: (3)

Sending query to server: (2) Parsing query: (2) Inserting record: (1 x size of record) Inserting indexes: (1 x number of indexes) Closing: (1)

Esto no toma en cuenta la sobrecarga inicial para abrir las tablas, que se realiza una sola vez por cada consulta se ejecutan simultneamente. El tamao de la tabla se ralentiza la insercin de ndices por log N, suponiendo ndices B-tree.

Velocidad de la sentencia INSERT

Bloqueo tambin reduce el tiempo total de conexin de mltiples pruebas-, aunque el tiempo de espera mximo para las conexiones individuales podran subir porque esperan a que las cerraduras. Por ejemplo: Conexin 1 hace 1000 inserciones Conexiones 2, 3 y 4 hacen un inserto Conexin 5 hace 1.000 inserciones Si usted no utiliza bloqueo, conexiones 2, 3 y 4 antes de final 1 y 5. Si se utiliza el bloqueo, conexiones 2, 3, y 4 probablemente no termine antes de 1 o 5, pero el tiempo total debe ser de aproximadamente 40% ms rpido. INSERT, UPDATE y DELETE son muy rpidos en MySQL, pero se puede obtener mejor rendimiento general mediante la adicin de cerraduras en torno a todo lo que hace mucho ms que unos cinco inserciones o actualizaciones en una fila. Si usted inserta muchos en una fila, se podra hacer un LOCK TABLES seguido de un UNLOCK TABLES de vez en cuando (aproximadamente cada 1.000 lneas) para permitir el acceso a otros hilos de la mesa. Esto todava se traducira en un aumento del rendimiento bueno. INSERT sigue siendo mucho ms lento para cargar datos que LOAD DATA INFILE, incluso cuando se utilizan las estrategias que acabamos de esbozar.

Velocidad de las sentencias UPDATE

Velocidad de las sentencias UPDATE

Instrucciones Update estn optimizados como una consulta SELECT con la sobrecarga adicional de una escritura. La velocidad de la escritura depende de la cantidad de datos que se actualizan y el nmero de ndices que se actualizan. Los ndices que no son modificados no se actualiza. Otra forma de obtener actualizaciones rpidas es retrasar las actualizaciones y luego hacer muchas actualizaciones en un lote ms tarde. Esto es mucho ms rpido que hacerlo de uno en uno si se bloquea la tabla. Tenga en cuenta que para una tabla MyISAM que utiliza el formato de registro dinmico, la actualizacin de un registro a una mayor longitud total puede dividir el disco. Si lo hace a menudo, es muy importante usar OPTIMIZE TABLE vez en cuando.

Velocidad de sentencias DELETE

Velocidad de sentencias DELETE

El tiempo para eliminar los registros individuales es exactamente proporcional al nmero de ndices. Para eliminar registros ms rpidamente, puede aumentar el tamao de la cach de claves. Si desea eliminar todas las filas de una tabla, utilice TRUNCATE TABLE tbl_name en lugar de DELETE FROM tbl_name.

Otros consejos sobre optimizacin

Otros consejos sobre optimizacin

En esta seccin se enumera una serie de consejos para mejorar diversos velocidad de procesamiento de consulta:

Utilizar conexiones permanentes a la base de datos para evitar la sobrecarga de la conexin. Si no puede usar conexiones persistentes y estn iniciando muchas nuevas conexiones a la base de datos, es posible que desee cambiar el valor de la variable thread_cache_size.
Compruebe siempre si todas sus preguntas realmente utilizar los ndices que se han creado en las tablas. En MySQL, puede hacer esto con la declaracin EXPLAIN. Trate de evitar las complejas consultas SELECT en tablas que se actualizan con frecuencia, para evitar problemas de bloqueo de tablas que se producen debido a la discordia entre los lectores y los escritores. Con tablas MyISAM que no tienen registros borrados, puede insertar filas en la final al mismo tiempo que otra consulta est leyendo de la tabla. Si esto es importante para usted, usted debe considerar el uso de la tabla de manera que eviten la eliminacin de filas. Otra posibilidad es ejecutar OPTIMIZE TABLE despus de haber eliminado una gran cantidad de filas.

Otros consejos sobre optimizacin

Use ALTER TABLE ... ORDER BY expr1, expr2, ... si sobre todo recuperar las filas de expr1, expr2, ... orden. Al utilizar esta opcin despus de grandes cambios en la tabla, puede ser capaz de obtener un mayor rendimiento. En algunos casos, puede tener sentido para introducir una columna que se "hash" basndose en la informacin de otras columnas. Si esta columna es corta y nica razonablemente, puede ser mucho ms rpido que un ndice grande en muchas columnas. En MySQL, es muy fcil de usar esta columna extra:

SELECT * FROM tbl_name WHERE hash_col=MD5(CONCAT(col1,col2)) AND col1='constant' AND col2='constant';


Para tablas MyISAM que cambian mucho, usted debe tratar de evitar todas las columnas de longitud variable (VARCHAR, BLOB y TEXT). La tabla utiliza el formato de registro dinmico si incluye ni una sola columna de longitud variable.

Otros consejos sobre optimizacin

Normalmente, no es til para dividir una tabla en tablas diferentes filas slo porque es grande. Para acceder a una fila, el golpe ms grande es el rendimiento de bsqueda de disco para encontrar el primer byte de la fila. Despus de encontrar los datos, los discos ms modernos pueden leer toda la fila con la suficiente rapidez para la mayora de aplicaciones. El nico caso en que es ventajoso para dividir una tabla es si la tabla es una tabla MyISAM con formato de registro dinmico (vase ms arriba) que se puede cambiar a un tamao de registro fija, o si muy a menudo tienen que recorrer la tabla, pero no necesitan ms de las columnas.

Si a menudo se necesita para calcular los resultados como los recuentos basados en informacin de una gran cantidad de filas, puede ser preferible introducir una nueva tabla y actualizar el contador en tiempo real. Una actualizacin de la siguiente forma es muy rpido:

UPDATE tbl_name SET count_col=count_col+1 WHERE key_col=constant;