Performance - script - Revision history

Admin: /* Optimización de consultas */

Admin — Fri, 12 Jun 2009 20:01:13 GMT

Optimización de consultas

←Older revision		Revision as of 20:01, 12 June 2009
Line 93:		Line 93:

	* Evitar el uso de SELECT *		* Evitar el uso de SELECT *
		+	* Utilizar lo menos posible ANY, SOME, EXISTS, IN
	* Evitar el SELECT DISTINCT y el ORDER BY		* Evitar el SELECT DISTINCT y el ORDER BY
	* Realizar filtrados en el FROM		* Realizar filtrados en el FROM

Admin: /* Tips de indices */

Admin — Fri, 12 Jun 2009 19:58:14 GMT

Tips de indices

←Older revision		Revision as of 19:58, 12 June 2009
Line 43:		Line 43:
	== Tips de indices ==		== Tips de indices ==

-	Si necesitamos un select del tipo SELECT ... WHERE columna_1 = X AND columna_2 = Y y ya tenemos un INDEX con la columna_1, podemos crear un segundo indice con la columna 2, o mejor todavía, crear un único indice combinado con las columnas 1 y 2. Estos son los índices multicolumna, o compuestos.	+	*Si necesitamos un select del tipo SELECT ... WHERE columna_1 = X AND columna_2 = Y y ya tenemos un INDEX con la columna_1, podemos crear un segundo indice con la columna 2, o mejor todavía, crear un único indice combinado con las columnas 1 y 2. Estos son los índices multicolumna, o compuestos.
-		+
	No obstante si tienes índices multicolumna y los utilizas en las clausulas WHERE, incluir siempre de izquierda a derecha las columnas indexadas; o el indice NO se usará:		No obstante si tienes índices multicolumna y los utilizas en las clausulas WHERE, incluir siempre de izquierda a derecha las columnas indexadas; o el indice NO se usará:

-		+	*Los índices pueden resultar contraproducentes si los introducimos sobre campos triviales a partir de los cuales no se realiza ningún tipo de petición ya que, además del problema de memoria ya mencionado, estamos ralentizando otras tareas de la base de datos como son la edición, inserción y borrado.

	= Pautas Basicas de optimización =		= Pautas Basicas de optimización =

Admin: /* Optimización de consultas = */

Admin — Fri, 12 Jun 2009 19:30:16 GMT

Optimización de consultas =

←Older revision		Revision as of 19:30, 12 June 2009
Line 84:		Line 84:
	Él ultimo paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.		Él ultimo paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.

-	= Optimización de consultas ==	+	== Optimización de consultas ==
	* Reglas generales		* Reglas generales
-	**Cascada de selecciones: Evitar el uso de seleccionar todo en última instancia	+	** Cascada de selecciones: Evitar el uso de seleccionar todo en última instancia
-	**Cascada de proyecciones: Evitar el uso de proyectar todo en una última instancia.	+	** Cascada de proyecciones: Evitar el uso de proyectar todo en una última instancia.
-	**Si la lista de la proyección es L= {A1,...,An, B1, ..., Bm} donde A1,...,An son atributos de R y B1,..., Bm son atributos de S. Si la condición del join involucra solo atributos de L. Repartir la proyección en las tablas que corresponda. Esto sería .. llevar lo mas abajo posibles las selecciones.	+	** Si la lista de la proyección es L= {A1,...,An, B1, ..., Bm} donde A1,...,An son atributos de R y B1,..., Bm son atributos de S. Si la condición del join involucra solo atributos de L. Repartir la proyección en las tablas que corresponda. Esto sería .. llevar lo mas abajo posibles las selecciones.
-	**Mismo caso con la UNION.	+	** Mismo caso con la UNION.
-	**Las relaciones con selecciones mas restrictivas sean ejecutadas primero , por mas restrictivas se entiende aquellas que produzcan la relación mas chica en cantidad de tuplas o en tamaño absoluto.	+	** Las relaciones con selecciones mas restrictivas sean ejecutadas primero , por mas restrictivas se entiende aquellas que produzcan la relación mas chica en cantidad de tuplas o en tamaño absoluto.

-	~~: La operación de selección es conmutativa~~
-
-	~~Evitar el uso de SELECT ~~
-	*Evitar el SELECT DISTINCT y el ORDER BY
-	*Realizar filtrados en el FROM
-	*Usar siempre JOINs (Right,Left,Natural) y no tablas dentro del from

		+	* Evitar el uso de SELECT *
		+	* Evitar el SELECT DISTINCT y el ORDER BY
		+	* Realizar filtrados en el FROM
		+	* Usar siempre JOINs (Right,Left,Natural) y no tablas dentro del from

	= Bibliografía ==		= Bibliografía ==

Admin: /* Bibliografía = */

Admin — Fri, 12 Jun 2009 19:20:05 GMT

Bibliografía =

←Older revision		Revision as of 19:20, 12 June 2009
Line 83:		Line 83:

	Él ultimo paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.		Él ultimo paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.
		+
		+	= Optimización de consultas ==
		+	* Reglas generales
		+	**Cascada de selecciones: Evitar el uso de seleccionar todo en última instancia
		+	**Cascada de proyecciones: Evitar el uso de proyectar todo en una última instancia.
		+	**Si la lista de la proyección es L= {A1,...,An, B1, ..., Bm} donde A1,...,An son atributos de R y B1,..., Bm son atributos de S. Si la condición del join involucra solo atributos de L. Repartir la proyección en las tablas que corresponda. Esto sería .. llevar lo mas abajo posibles las selecciones.
		+	**Mismo caso con la UNION.
		+	**Las relaciones con selecciones mas restrictivas sean ejecutadas primero , por mas restrictivas se entiende aquellas que produzcan la relación mas chica en cantidad de tuplas o en tamaño absoluto.
		+
		+	: La operación de selección es conmutativa
		+
		+	Evitar el uso de SELECT
		+	*Evitar el SELECT DISTINCT y el ORDER BY
		+	*Realizar filtrados en el FROM
		+	*Usar siempre JOINs (Right,Left,Natural) y no tablas dentro del from
		+

	= Bibliografía ==		= Bibliografía ==

Admin: /* Pautas Basicas de optimización */

Admin — Mon, 08 Jun 2009 14:18:34 GMT

Pautas Basicas de optimización

←Older revision		Revision as of 14:18, 8 June 2009
Line 52:		Line 52:

	Pautas básicas a tener en cuenta para una estrategia de optimizacion de rendimiento.		Pautas básicas a tener en cuenta para una estrategia de optimizacion de rendimiento.
-

	* Esquema de diseño.		* Esquema de diseño.
Line 71:		Line 70:
	===Optimización de Query===		===Optimización de Query===

-	El segundo paso en la optimización de la estrategia de performance es optimizar los queries. Esto involucra el rediseño de queries. Luego de que optimices el esquema de base de datos se debe revisar y rediseñar los queries.	+	El segundo paso en la optimización de la estrategia de performance es optimizar los queries. Esto involucra el rediseño de queries. Luego de que optimices el esquema de base de datos se debe revisar y rediseñar los queries.

	===Indexación===		===Indexación===

-	El paso siguiente es la optimización de índices. La existencia o ausencia de los indices pueden afectar la performance de la base de datos ya sea mejorando o empeorando la misma. Es por ello que hay que revisar los índices solo después de haber optimizado los queries y re evaluado tu esquema de base de datos.	+	El paso siguiente es la optimización de índices. La existencia o ausencia de los indices pueden afectar la performance de la base de datos ya sea mejorando o empeorando la misma. Es por ello que hay que revisar los índices solo después de haber optimizado los queries y re evaluado tu esquema de base de datos.

	===Locking===		===Locking===

-	La penúltima fase es la estrategia de optimización de locks. Esta fase impacta en la concurrencia de la base de datos, afectando la performance de la misma.	+	La penúltima fase es la estrategia de optimización de locks. Esta fase impacta en la concurrencia de la base de datos, afectando la performance de la misma.

	===Server Tunning===		===Server Tunning===

-	Él ~~ultima~~ paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.	+	Él ultimo paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.

	= Bibliografía ==		= Bibliografía ==

Admin: /* Pautas Basicas de optimización */

Admin — Mon, 08 Jun 2009 14:17:57 GMT

Pautas Basicas de optimización

←Older revision		Revision as of 14:17, 8 June 2009
Line 65:		Line 65:


-	Esquema de Diseño	+	===Esquema de Diseño===

-	La primera y más importante tarea de performance es optimizar el esquema de diseño. Y optimizar el esquema - diseño de base de datos tiene un impacto directo sobre el resto de los niveles de optimización. En esta etapa engloba los conceptos típicos de normalización, desnormalizacion y generalización o método de análisis de relaciones, columnas, etc etc.	+	La primera y más importante tarea de performance es optimizar el esquema de diseño. Y optimizar el esquema - diseño de base de datos tiene un impacto directo sobre el resto de los niveles de optimización. En esta etapa engloba los conceptos típicos de normalización, desnormalizacion y generalización o método de análisis de relaciones, columnas, etc etc.

-	Optimización de Query	+	===Optimización de Query===

	El segundo paso en la optimización de la estrategia de performance es optimizar los queries. Esto involucra el rediseño de queries. Luego de que optimices el esquema de base de datos se debe revisar y rediseñar los queries.		El segundo paso en la optimización de la estrategia de performance es optimizar los queries. Esto involucra el rediseño de queries. Luego de que optimices el esquema de base de datos se debe revisar y rediseñar los queries.

-	Indexación	+	===Indexación===

	El paso siguiente es la optimización de índices. La existencia o ausencia de los indices pueden afectar la performance de la base de datos ya sea mejorando o empeorando la misma. Es por ello que hay que revisar los índices solo después de haber optimizado los queries y re evaluado tu esquema de base de datos.		El paso siguiente es la optimización de índices. La existencia o ausencia de los indices pueden afectar la performance de la base de datos ya sea mejorando o empeorando la misma. Es por ello que hay que revisar los índices solo después de haber optimizado los queries y re evaluado tu esquema de base de datos.

-	Locking	+	===Locking===

	La penúltima fase es la estrategia de optimización de locks. Esta fase impacta en la concurrencia de la base de datos, afectando la performance de la misma.		La penúltima fase es la estrategia de optimización de locks. Esta fase impacta en la concurrencia de la base de datos, afectando la performance de la misma.

-	Server Tunning	+	===Server Tunning===

	Él ultima paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.		Él ultima paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.

Admin: /* Pautas Basicas de optimización */

Admin — Mon, 08 Jun 2009 13:42:51 GMT

Pautas Basicas de optimización

←Older revision		Revision as of 13:42, 8 June 2009
Line 60:		Line 60:
	* Server Tuning.		* Server Tuning.

-	Importancia: Los niveles más bajos de la lista son muy importantes pues impactan en forma directa a la performance, no es lo mismo tratar de solucionar o mejorar rendimiento sobre algo no muy correctamante diseñado, es decir, si se invierte tiempo y recursos en el esquema de diseño, la base de datos será más fácil de optimizar para los demás niveles.	+	'''Importancia''': Los niveles más bajos de la lista son muy importantes pues impactan en forma directa a la performance, no es lo mismo tratar de solucionar o mejorar rendimiento sobre algo no muy correctamante diseñado, es decir, si se invierte tiempo y recursos en el esquema de diseño, la base de datos será más fácil de optimizar para los demás niveles.

-	Orden: Comienzar desde el esquema de diseño y hacia el tunning del server. Este es el orden en que los elementos de la base de datos son más fáciles de optimizar.	+	'''Orden''': Comienzar desde el esquema de diseño y hacia el tunning del server. Este es el orden en que los elementos de la base de datos son más fáciles de optimizar.


	Esquema de Diseño		Esquema de Diseño

-	La primera y más importante tarea de performance es optimizar el esquema de diseño. Y optimizar el esquema - diseño de base de datos tiene un impacto directo sobre el resto de los niveles de optimización. En esta etapa engloba los conceptos típicos de normalización, desnormalizacion y generalización o método de análisis de relaciones, columnas, etc etc.	+	La primera y más importante tarea de performance es optimizar el esquema de diseño. Y optimizar el esquema - diseño de base de datos tiene un impacto directo sobre el resto de los niveles de optimización. En esta etapa engloba los conceptos típicos de normalización, desnormalizacion y generalización o método de análisis de relaciones, columnas, etc etc.

	Optimización de Query		Optimización de Query

-	El segundo paso en la optimización de la estrategia de performance es optimizar los queries. Esto involucra el rediseño de queries. Luego de que optimices el esquema de base de datos se debe revisar y rediseñar los queries.	+	El segundo paso en la optimización de la estrategia de performance es optimizar los queries. Esto involucra el rediseño de queries. Luego de que optimices el esquema de base de datos se debe revisar y rediseñar los queries.

	Indexación		Indexación

-	El paso siguiente es la optimización de índices. La existencia o ausencia de los indices pueden afectar la performance de la base de datos ya sea mejorando o empeorando la misma. Es por ello que hay que revisar los índices solo después de haber optimizado los queries y re evaluado tu esquema de base de datos.	+	El paso siguiente es la optimización de índices. La existencia o ausencia de los indices pueden afectar la performance de la base de datos ya sea mejorando o empeorando la misma. Es por ello que hay que revisar los índices solo después de haber optimizado los queries y re evaluado tu esquema de base de datos.

	Locking		Locking

-	La penúltima fase es la estrategia de optimización de locks. Esta fase impacta en la concurrencia de la base de datos, afectando la performance de la misma.	+	La penúltima fase es la estrategia de optimización de locks. Esta fase impacta en la concurrencia de la base de datos, afectando la performance de la misma.

	Server Tunning		Server Tunning

-	Él ultima paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.	+	Él ultima paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.
		+
	= Bibliografía ==		= Bibliografía ==

Admin at 13:41, 8 June 2009

Admin — Mon, 08 Jun 2009 13:41:20 GMT

←Older revision		Revision as of 13:41, 8 June 2009
Line 48:		Line 48:


		+
		+	= Pautas Basicas de optimización =
		+
		+	Pautas básicas a tener en cuenta para una estrategia de optimizacion de rendimiento.
		+
		+
		+	* Esquema de diseño.
		+	* Optimización del query.
		+	* Indexación.
		+	* Locking.
		+	* Server Tuning.
		+
		+	Importancia: Los niveles más bajos de la lista son muy importantes pues impactan en forma directa a la performance, no es lo mismo tratar de solucionar o mejorar rendimiento sobre algo no muy correctamante diseñado, es decir, si se invierte tiempo y recursos en el esquema de diseño, la base de datos será más fácil de optimizar para los demás niveles.
		+
		+	Orden: Comienzar desde el esquema de diseño y hacia el tunning del server. Este es el orden en que los elementos de la base de datos son más fáciles de optimizar.
		+
		+
		+	Esquema de Diseño
		+
		+	La primera y más importante tarea de performance es optimizar el esquema de diseño. Y optimizar el esquema - diseño de base de datos tiene un impacto directo sobre el resto de los niveles de optimización. En esta etapa engloba los conceptos típicos de normalización, desnormalizacion y generalización o método de análisis de relaciones, columnas, etc etc.
		+
		+	Optimización de Query
		+
		+	El segundo paso en la optimización de la estrategia de performance es optimizar los queries. Esto involucra el rediseño de queries. Luego de que optimices el esquema de base de datos se debe revisar y rediseñar los queries.
		+
		+	Indexación
		+
		+	El paso siguiente es la optimización de índices. La existencia o ausencia de los indices pueden afectar la performance de la base de datos ya sea mejorando o empeorando la misma. Es por ello que hay que revisar los índices solo después de haber optimizado los queries y re evaluado tu esquema de base de datos.
		+
		+	Locking
		+
		+	La penúltima fase es la estrategia de optimización de locks. Esta fase impacta en la concurrencia de la base de datos, afectando la performance de la misma.
		+
		+	Server Tunning
		+
		+	Él ultima paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.
	= Bibliografía ==		= Bibliografía ==

Admin at 13:34, 8 June 2009

Admin — Mon, 08 Jun 2009 13:34:29 GMT

Admin at 13:22, 8 June 2009

Admin — Mon, 08 Jun 2009 13:22:50 GMT

←Older revision		Revision as of 13:34, 8 June 2009
Line 1:		Line 1:
	= Indices =		= Indices =

-	Un ~~ÃÂndice~~ (o KEY, o INDEX) es un grupo de datos que MySQL asocia con una o varias columnas de la tabla. En este grupo de datos aparece la ~~relaciÃ³n~~ entre el contenido y el ~~nÃºmero~~ de fila donde ~~estÃ¡~~ ubicado.	+	Un índice (o KEY, o INDEX) es un grupo de datos que MySQL asocia con una o varias columnas de la tabla. En este grupo de datos aparece la relación entre el contenido y el número de fila donde está ubicado.

-	Los ~~Ãndices~~ -como los ~~Ãndices~~ de los libros- sirven para agilizar las consultas a las tablas, evitando que mysql tenga que revisar todos los datos disponibles para devolver el resultado.	+	Los índices -como los índices de los libros- sirven para agilizar las consultas a las tablas, evitando que mysql tenga que revisar todos los datos disponibles para devolver el resultado.

-	Podemos crear el ~~Ãndice~~ a la vez que creamos la tabla, usando la palabra INDEX seguida del nombre del ~~Ãndice~~ a crear y columnas a indexar (que pueden ser varias):	+	Podemos crear el índice a la vez que creamos la tabla, usando la palabra INDEX seguida del nombre del índice a crear y columnas a indexar (que pueden ser varias):
	INDEX nombre_indice (columna_indexada, columna_indexada2...)		INDEX nombre_indice (columna_indexada, columna_indexada2...)

-	La sintaxis es ligeramente distinta segun la clase de ~~Ãndice~~:	+	La sintaxis es ligeramente distinta segun la clase de índice:

	PRIMARY KEY (nombre_columna_1 [,nombre_columna2...])		PRIMARY KEY (nombre_columna_1 [,nombre_columna2...])
Line 14:		Line 14:
	INDEX nombre_index (columna_indexada1 [,columna_indexada2...])		INDEX nombre_index (columna_indexada1 [,columna_indexada2...])

-	Podemos ~~tambiÃ©n aÃ±adirlos~~ a una tabla ~~despuÃ©s~~ de creada:	+	Podemos también añadirlos a una tabla después de creada:

	ALTER TABLE nombre_tabla ADD INDEX nombre_indice (columna_indexada);		ALTER TABLE nombre_tabla ADD INDEX nombre_indice (columna_indexada);

-	Los ~~Ãndices~~ permiten mayor ~~rÃ¡pidez~~ en la ~~ejecuciÃ³n~~ de las consultas a la base de datos tipo SELECT ... WHERE	+	Los índices permiten mayor rápidez en la ejecución de las consultas a la base de datos tipo SELECT ... WHERE

-	La regla ~~bÃ¡sica~~ es crear ~~Ãndices~~ sobre aquellas columnas que se usen en una ~~clÃ¡usula~~ WHERE. Pero existen varias reglas donde el uso de un ~~Ãndice podrÃa~~ afectar directamente a la performance de una consulta (Group BY, Order BY)	+	La regla básica es crear índices sobre aquellas columnas que se usen en una cláusula WHERE. Pero existen varias reglas donde el uso de un índice podría afectar directamente a la performance de una consulta (Group BY, Order BY)

-	Otra regla ~~bÃ¡sica~~ es que son mejores candidatas a indexar aquellas columnas que presentan muchos valores distintos, mientras que no son buenas candidatas las que tienen muchos valores ~~idÃ©nticos~~, como por ejemplo sexo (masculino y femenino) porque cada consulta ~~implicarÃ¡~~ siempre recorrer practicamente la mitad del indice.	+	Otra regla básica es que son mejores candidatas a indexar aquellas columnas que presentan muchos valores distintos, mientras que no son buenas candidatas las que tienen muchos valores idénticos, como por ejemplo sexo (masculino y femenino) porque cada consulta implicará siempre recorrer practicamente la mitad del indice.

	== Diferentes tipos de indices ==		== Diferentes tipos de indices ==

-	En algunas bases de datos existen diferencias entre KEY e INDEX ( no ~~asÃ~~ en MySQL donde son ~~sinÃ³nimos~~)	+	En algunas bases de datos existen diferencias entre KEY e INDEX ( no así en MySQL donde son sinónimos)

-	* Un ~~Ãndice~~ que ~~sÃ~~ es especial es el llamado PRIMARY KEY. Se trata de un ~~Ãndice diseÃ±ado~~ para consultas especialmente ~~rÃ¡pidas~~. Todos sus campos deben ser UNICOS y no admite NULL	+	* Un índice que sí es especial es el llamado PRIMARY KEY. Se trata de un índice diseñado para consultas especialmente rápidas. Todos sus campos deben ser UNICOS y no admite NULL

-	* Un ~~Ãndice~~ UNIQUE es aquel que no permite almacenar dos valores iguales.	+	* Un indice UNIQUE es aquel que no permite almacenar dos valores iguales.

-	* Los indices FULL TEXT permiten realizar ~~bÃºsquedas~~ de palabras sobre tablas MYSAM. Puedes crear indices FULLTEXT sobre columnas tipo CHAR, VARCHAR o TEXT. Una vez creado puedes hacer ~~bÃºsquedas~~ del tipo:	+	* Los indices FULL TEXT permiten realizar búsquedas de palabras sobre tablas MYSAM. Puedes crear indices FULLTEXT sobre columnas tipo CHAR, VARCHAR o TEXT. Una vez creado puedes hacer búsquedas del tipo:

	SELECT * FROM nombre_tabla WHERE MATCH(nombre_indice_fulltext) AGAINST('palabra_a_buscar');		SELECT * FROM nombre_tabla WHERE MATCH(nombre_indice_fulltext) AGAINST('palabra_a_buscar');

-	Los ~~Ãndices~~ ordinarios no tienen restricciones en cuanto a la existencia de valores ~~idÃ©nticos~~ o nulos. Una posibilidad interesante, si pensamos crear un ~~Ãndice~~ sobre columnas CHAR y VARCHAR es la de limitar el campo a indexar. Por ejemplo, cada entrada en la columna puede ser de hasta 40 caracteres y nosotros indexar unicamente los primeros 10 de cada una. Para crear estos ~~Ãndices~~ basta con indicar entre ~~parÃ©ntesis~~ el ~~nÃºmero~~ de caracteres a indexar despues del nombre de la columna:	+	Los índices ordinarios no tienen restricciones en cuanto a la existencia de valores idénticos o nulos. Una posibilidad interesante, si pensamos crear un índice sobre columnas CHAR y VARCHAR es la de limitar el campo a indexar. Por ejemplo, cada entrada en la columna puede ser de hasta 40 caracteres y nosotros indexar unicamente los primeros 10 de cada una. Para crear estos índices basta con indicar entre paréntesis el numero de caracteres a indexar despues del nombre de la columna:

	ALTER TABLE libros ADD INDEX idx_autor(nombre(10), apellidos(10));		ALTER TABLE libros ADD INDEX idx_autor(nombre(10), apellidos(10));
Line 43:		Line 43:
	== Tips de indices ==		== Tips de indices ==

-	Si necesitamos un select del tipo SELECT ... WHERE columna_1 = X AND columna_2 = Y y ya tenemos un INDEX con la columna_1, podemos crear un segundo indice con la columna 2, o mejor ~~todavÃaÂ~~, crear un ~~Ãºnico~~ indice combinado con las columnas 1 y 2. Estos son los ~~Ãndices~~ multicolumna, o compuestos.	+	Si necesitamos un select del tipo SELECT ... WHERE columna_1 = X AND columna_2 = Y y ya tenemos un INDEX con la columna_1, podemos crear un segundo indice con la columna 2, o mejor todavía, crear un único indice combinado con las columnas 1 y 2. Estos son los índices multicolumna, o compuestos.

-	No obstante si ~~se tiene un ÃÂndice~~ multicolumna y ~~se utiliza~~ en la clausulas WHERE, incluir siempre de izquierda a derecha las columnas indexadas; o el indice NO se ~~usarÃ¡.~~	+	No obstante si tienes índices multicolumna y los utilizas en las clausulas WHERE, incluir siempre de izquierda a derecha las columnas indexadas; o el indice NO se usará:


-	= ~~BibliografÃa~~ ==	+	= Bibliografía ==

	*http://dev.mysql.com/doc/refman/6.0/en/mysql-indexes.html		*http://dev.mysql.com/doc/refman/6.0/en/mysql-indexes.html
	*http://dev.mysql.com/doc/refman/6.0/en/group-by-optimization.html		*http://dev.mysql.com/doc/refman/6.0/en/group-by-optimization.html
	*http://dev.mysql.com/doc/refman/6.0/en/order-by-optimization.html		*http://dev.mysql.com/doc/refman/6.0/en/order-by-optimization.html

←Older revision		Revision as of 13:22, 8 June 2009
Line 1:		Line 1:
	= Indices =		= Indices =

-	Un ~~índice~~ (o KEY, o INDEX) es un grupo de datos que MySQL asocia con una o varias columnas de la tabla. En este grupo de datos aparece la ~~relación~~ entre el contenido y el ~~número~~ de fila donde ~~está~~ ubicado.	+	Un ÃÂndice (o KEY, o INDEX) es un grupo de datos que MySQL asocia con una o varias columnas de la tabla. En este grupo de datos aparece la relaciÃ³n entre el contenido y el nÃºmero de fila donde estÃ¡ ubicado.

-	Los ~~índices~~ -como los ~~índices~~ de los libros- sirven para agilizar las consultas a las tablas, evitando que mysql tenga que revisar todos los datos disponibles para devolver el resultado.	+	Los Ãndices -como los Ãndices de los libros- sirven para agilizar las consultas a las tablas, evitando que mysql tenga que revisar todos los datos disponibles para devolver el resultado.

-	Podemos crear el ~~índice~~ a la vez que creamos la tabla, usando la palabra INDEX seguida del nombre del ~~índice~~ a crear y columnas a indexar (que pueden ser varias):	+	Podemos crear el Ãndice a la vez que creamos la tabla, usando la palabra INDEX seguida del nombre del Ãndice a crear y columnas a indexar (que pueden ser varias):
	INDEX nombre_indice (columna_indexada, columna_indexada2...)		INDEX nombre_indice (columna_indexada, columna_indexada2...)

-	La sintaxis es ligeramente distinta segun la clase de ~~índice~~:	+	La sintaxis es ligeramente distinta segun la clase de Ãndice:

	PRIMARY KEY (nombre_columna_1 [,nombre_columna2...])		PRIMARY KEY (nombre_columna_1 [,nombre_columna2...])
Line 14:		Line 14:
	INDEX nombre_index (columna_indexada1 [,columna_indexada2...])		INDEX nombre_index (columna_indexada1 [,columna_indexada2...])

-	Podemos ~~también añadirlos~~ a una tabla ~~despuÃ�Â©s~~ de creada:	+	Podemos tambiÃ©n aÃ±adirlos a una tabla despuÃ©s de creada:

	ALTER TABLE nombre_tabla ADD INDEX nombre_indice (columna_indexada);		ALTER TABLE nombre_tabla ADD INDEX nombre_indice (columna_indexada);

-	Los ~~Ã�Ândices~~ permiten mayor ~~rÃ�Â¡pidez~~ en la ~~ejecuciÃ�Â³n~~ de las consultas a la base de datos tipo SELECT ... WHERE	+	Los Ãndices permiten mayor rÃ¡pidez en la ejecuciÃ³n de las consultas a la base de datos tipo SELECT ... WHERE

-	La regla ~~bÃ�Â¡sica~~ es crear ~~Ã�Ândices~~ sobre aquellas columnas que se usen en una ~~clÃ�Â¡usula~~ WHERE. Pero existen varias reglas donde el uso de un ~~Ã�Ândice podrÃ�Âa~~ afectar directamente a la performance de una consulta (Group BY, Order BY)	+	La regla bÃ¡sica es crear Ãndices sobre aquellas columnas que se usen en una clÃ¡usula WHERE. Pero existen varias reglas donde el uso de un Ãndice podrÃa afectar directamente a la performance de una consulta (Group BY, Order BY)

-	Otra regla ~~bÃ�Â¡sica~~ es que son mejores candidatas a indexar aquellas columnas que presentan muchos valores distintos, mientras que no son buenas candidatas las que tienen muchos valores ~~idÃ�Â©nticos~~, como por ejemplo sexo (masculino y femenino) porque cada consulta ~~implicarÃ�Â¡~~ siempre recorrer practicamente la mitad del indice.	+	Otra regla bÃ¡sica es que son mejores candidatas a indexar aquellas columnas que presentan muchos valores distintos, mientras que no son buenas candidatas las que tienen muchos valores idÃ©nticos, como por ejemplo sexo (masculino y femenino) porque cada consulta implicarÃ¡ siempre recorrer practicamente la mitad del indice.

	== Diferentes tipos de indices ==		== Diferentes tipos de indices ==

-	En algunas bases de datos existen diferencias entre KEY e INDEX ( no ~~asÃ�Â~~ en MySQL donde son ~~sinÃ�Â³nimos~~)	+	En algunas bases de datos existen diferencias entre KEY e INDEX ( no asÃ en MySQL donde son sinÃ³nimos)

-	* Un ~~Ã�Ândice~~ que ~~sÃ�Â~~ es especial es el llamado PRIMARY KEY. Se trata de un ~~Ã�Ândice diseÃ�Â±ado~~ para consultas especialmente ~~rÃ�Â¡pidas~~. Todos sus campos deben ser UNICOS y no admite NULL	+	* Un Ãndice que sÃ es especial es el llamado PRIMARY KEY. Se trata de un Ãndice diseÃ±ado para consultas especialmente rÃ¡pidas. Todos sus campos deben ser UNICOS y no admite NULL

-	* Un ~~indice~~ UNIQUE es aquel que no permite almacenar dos valores iguales.	+	* Un Ãndice UNIQUE es aquel que no permite almacenar dos valores iguales.

-	* Los indices FULL TEXT permiten realizar ~~bÃ�Âºsquedas~~ de palabras sobre tablas MYSAM. Puedes crear indices FULLTEXT sobre columnas tipo CHAR, VARCHAR o TEXT. Una vez creado puedes hacer ~~bÃ�Âºsquedas~~ del tipo:	+	* Los indices FULL TEXT permiten realizar bÃºsquedas de palabras sobre tablas MYSAM. Puedes crear indices FULLTEXT sobre columnas tipo CHAR, VARCHAR o TEXT. Una vez creado puedes hacer bÃºsquedas del tipo:

	SELECT * FROM nombre_tabla WHERE MATCH(nombre_indice_fulltext) AGAINST('palabra_a_buscar');		SELECT * FROM nombre_tabla WHERE MATCH(nombre_indice_fulltext) AGAINST('palabra_a_buscar');

-	Los ~~Ã�Ândices~~ ordinarios no tienen restricciones en cuanto a la existencia de valores ~~idÃ�Â©nticos~~ o nulos. Una posibilidad interesante, si pensamos crear un ~~Ã�Ândice~~ sobre columnas CHAR y VARCHAR es la de limitar el campo a indexar. Por ejemplo, cada entrada en la columna puede ser de hasta 40 caracteres y nosotros indexar unicamente los primeros 10 de cada una. Para crear estos ~~Ã�Ândices~~ basta con indicar entre ~~parÃ�Â©ntesis~~ el ~~numero~~ de caracteres a indexar despues del nombre de la columna:	+	Los Ãndices ordinarios no tienen restricciones en cuanto a la existencia de valores idÃ©nticos o nulos. Una posibilidad interesante, si pensamos crear un Ãndice sobre columnas CHAR y VARCHAR es la de limitar el campo a indexar. Por ejemplo, cada entrada en la columna puede ser de hasta 40 caracteres y nosotros indexar unicamente los primeros 10 de cada una. Para crear estos Ãndices basta con indicar entre parÃ©ntesis el nÃºmero de caracteres a indexar despues del nombre de la columna:

	ALTER TABLE libros ADD INDEX idx_autor(nombre(10), apellidos(10));		ALTER TABLE libros ADD INDEX idx_autor(nombre(10), apellidos(10));
Line 43:		Line 43:
	== Tips de indices ==		== Tips de indices ==

-	Si necesitamos un select del tipo SELECT ... WHERE columna_1 = X AND columna_2 = Y y ya tenemos un INDEX con la columna_1, podemos crear un segundo indice con la columna 2, o mejor ~~todavÃ�Âa~~, crear un ~~Ã�Âºnico~~ indice combinado con las columnas 1 y 2. Estos son los ~~Ã�Ândices~~ multicolumna, o compuestos.	+	Si necesitamos un select del tipo SELECT ... WHERE columna_1 = X AND columna_2 = Y y ya tenemos un INDEX con la columna_1, podemos crear un segundo indice con la columna 2, o mejor todavÃaÂ, crear un Ãºnico indice combinado con las columnas 1 y 2. Estos son los Ãndices multicolumna, o compuestos.

-	No obstante si ~~tienes Ã�Ândices~~ multicolumna y ~~los utilizas~~ en ~~las~~ clausulas WHERE, incluir siempre de izquierda a derecha las columnas indexadas; o el indice NO se ~~usarÃ�Â¡:~~	+	No obstante si se tiene un ÃÂndice multicolumna y se utiliza en la clausulas WHERE, incluir siempre de izquierda a derecha las columnas indexadas; o el indice NO se usarÃ¡.


-	= ~~BibliografÃ�Âa~~ ==	+	= BibliografÃa ==

-	http://dev.mysql.com/doc/refman/6.0/en/mysql-indexes.html	+	*http://dev.mysql.com/doc/refman/6.0/en/mysql-indexes.html
-	http://dev.mysql.com/doc/refman/6.0/en/group-by-optimization.html	+	*http://dev.mysql.com/doc/refman/6.0/en/group-by-optimization.html
-	http://dev.mysql.com/doc/refman/6.0/en/order-by-optimization.html	+	*http://dev.mysql.com/doc/refman/6.0/en/order-by-optimization.html