![\"\"](\"https:\/\/enviame.somosforma.dev\/wp-content\/webp-express\/webp-images\/doc-root\/wp-content\/uploads\/2021\/12\/image.jpeg.webp\")
<\/figure><\/div>\n\n\nPara ello, vamos a revisar un ejemplo sencillo. Imag\u00ednense que tenemos una base de datos MySQL con la siguiente tabla users<\/em>, donde la misma tiene un mill\u00f3n de registros y necesitamos filtrar todos los usuarios activos creados en los \u00faltimos 3 meses, que se hayan registrado mediante su celular y que est\u00e9 ordenado por apellido y nombre.<\/p>\n\n\n\n Cuando el motor de base de datos ejecuta la consulta, verifica qu\u00e9 \u00edndice se ajusta mejor a la petici\u00f3n que estamos realizando. Si no existen \u00edndices en la tabla o ninguno se ajusta a nuestra consulta, se realizar\u00e1 un full table scan<\/em>, que leer\u00e1 cada uno de los registros aplicando los par\u00e1metros de b\u00fasqueda que hemos especificado. Esta operaci\u00f3n tendr\u00e1 muy mala performance, por lo que, es necesario analizar qu\u00e9 \u00edndice conviene crear para aumentar la velocidad de la consulta. Algunos pensar\u00e1n en la idea de crear \u00edndices por cada uno de los campos de la tabla, lo cual es un grave error. La creaci\u00f3n masiva de \u00edndices en una tabla, conlleva efectos adversos:<\/p>\n\n\n\n Por lo tanto, la primera decisi\u00f3n que debemos tomar es si conviene crear un \u00edndice simple o uno compuesto. Los compuestos son \u00fatiles cuando tenemos campos que se consultan com\u00fanmente juntos y ambos tienen un alto grado de cardinalidad (a mayor cantidad de valores \u00fanicos, mayor cardinalidad).<\/p>\n\n\n\n Si analizamos nuestra tabla y un posible modelo de negocio, podemos suponer que los campos created_at<\/em> y active<\/em> podr\u00edan aparecer juntos en varias peticiones. Pero si verificamos su cardinalidad, el campo active<\/em> tiene una muy baja (solo 2 valores posibles toma este campo), lo que hace que la performance de crear un \u00edndice \u00fanico por created_at<\/em> y crear un \u00edndice compuesto por created_at<\/em> y active<\/em> sea similar.<\/p>\n\n\n\n Por ende, la mejor decisi\u00f3n para nuestro caso hipot\u00e9tico, es crear un \u00edndice simple por el campo created_at<\/em>.<\/p>\n\n\n\n A continuaci\u00f3n, dejo algunas screens de las pruebas realizadas:<\/p>\n\n\n\n Cantidad total de registros en la tabla<\/em><\/p>\n\n\n\n Plan de acci\u00f3n del motor de base de datos, donde se especifica que NO se va a utilizar ning\u00fan \u00edndice en la ejecuci\u00f3n de la consulta.<\/em><\/p>\n\n\n\n La ejecuci\u00f3n de la consulta tard\u00f3 1118 ms<\/span><\/strong> devolviendo 816<\/strong> registros.<\/p>\n\n\n\n Creaci\u00f3n de \u00edndice BTree<\/em> por campo created_at<\/em> Plan de acci\u00f3n del motor de base de datos, donde se especifica que va a utilizar el \u00edndice users_created_at_IDX en la ejecuci\u00f3n de la consulta.<\/em><\/p>\n\n\n\n La ejecuci\u00f3n de la consulta tard\u00f3 74 ms<\/span><\/strong> devolviendo 816<\/strong> registros.<\/em><\/p>\n\n\n\n Como podr\u00e1n observar, aplicando el correcto \u00edndice, la consulta se ejecut\u00f3 15 veces m\u00e1s r\u00e1pido. Esto nos da la pauta de la importancia de aplicar \u00edndices en nuestras tablas.<\/p>\n\n\n\n Para finalizar, les dejo algunas recomendaciones:<\/p>\n\n\n\n Hace algunos meses, abordamos con el equipo una historia de usuario en donde nos informaban un lento rendimiento en una vista del sistema. Analizando la situaci\u00f3n, verificamos que el problema proven\u00eda de una consulta que no tomaba el \u00edndice correcto para la petici\u00f3n que se estaba solicitando. Esta circunstancia me motiv\u00f3 a escribir este art\u00edculo, en donde se analizar\u00e1 un caso simple de ejemplo, en el que se requiere crear un \u00edndice en una tabla para optimizar una consulta. El objetivo no es definir qu\u00e9 son los \u00edndices o ahondar en sus caracter\u00edsticas, sino analizar c\u00f3mo enfrentar este tipo de problemas y qu\u00e9 estrategias podemos implementar para solucionarlos. Para ello, vamos a revisar un ejemplo sencillo. Imag\u00ednense que tenemos una base de datos MySQL con la siguiente tabla users, donde la misma tiene un mill\u00f3n de registros y necesitamos filtrar todos los usuarios activos creados en los \u00faltimos 3 meses, que se hayan registrado mediante su celular y que est\u00e9 ordenado por apellido y nombre. Cuando el motor de base de datos ejecuta la consulta, verifica qu\u00e9 \u00edndice se ajusta mejor a la petici\u00f3n que estamos realizando. Si no existen \u00edndices en la tabla o ninguno se ajusta a nuestra consulta, se realizar\u00e1 un full table scan, que leer\u00e1 cada uno de los registros aplicando los par\u00e1metros de b\u00fasqueda que hemos especificado. Esta operaci\u00f3n tendr\u00e1 muy mala performance, por lo que, es necesario analizar qu\u00e9 \u00edndice conviene crear para aumentar la velocidad de la consulta. Algunos pensar\u00e1n en la idea de crear \u00edndices por cada uno de los campos de la tabla, lo cual es un grave error. La creaci\u00f3n masiva de \u00edndices en una tabla, conlleva efectos adversos: Cada \u00edndice ocupa espacio de almacenamiento en nuestra base de datos. La velocidad en las operaciones de insert, update y delete puede verse afectada, ya que los \u00edndices de la tabla deben ser actualizados, ante cada una de estas acciones. Por lo tanto, la primera decisi\u00f3n que debemos tomar es si conviene crear un \u00edndice simple o uno compuesto. Los compuestos son \u00fatiles cuando tenemos campos que se consultan com\u00fanmente juntos y ambos tienen un alto grado de cardinalidad (a mayor cantidad de valores \u00fanicos, mayor cardinalidad). Si analizamos nuestra tabla y un posible modelo de negocio, podemos suponer que los campos created_at y active podr\u00edan aparecer juntos en varias peticiones. Pero si verificamos su cardinalidad, el campo active tiene una muy baja (solo 2 valores posibles toma este campo), lo que hace que la performance de crear un \u00edndice \u00fanico por created_at y crear un \u00edndice compuesto por created_at y active sea similar. Por ende, la mejor decisi\u00f3n para nuestro caso hipot\u00e9tico, es crear un \u00edndice simple por el campo created_at. A continuaci\u00f3n, dejo algunas screens de las pruebas realizadas: Cantidad total de registros en la tabla Plan de acci\u00f3n del motor de base de datos, donde se especifica que NO se va a utilizar ning\u00fan \u00edndice en la ejecuci\u00f3n de la consulta. La ejecuci\u00f3n de la consulta tard\u00f3 1118 ms devolviendo 816 registros. Creaci\u00f3n de \u00edndice BTree por campo created_at Plan de acci\u00f3n del motor de base de datos, donde se especifica que va a utilizar el \u00edndice users_created_at_IDX en la ejecuci\u00f3n de la consulta. La ejecuci\u00f3n de la consulta tard\u00f3 74 ms devolviendo 816 registros. Como podr\u00e1n observar, aplicando el correcto \u00edndice, la consulta se ejecut\u00f3 15 veces m\u00e1s r\u00e1pido. Esto nos da la pauta de la importancia de aplicar \u00edndices en nuestras tablas. Para finalizar, les dejo algunas recomendaciones: No usar \u00edndices en tablas con poca cantidad de datos. Tener cuidado con la cantidad de \u00edndices que se utilizan en una tabla, ya que esto puede provocar una baja en el rendimiento de las operaciones de creaci\u00f3n, modificaci\u00f3n y eliminaci\u00f3n. Elegir campos que tengan alta cardinalidad. En los \u00edndices compuestos, el orden en que se crean las columnas INFLUYE. Estos pueden hacer uso de todas sus columnas o pueden usar solo algunas, pero solo tomando la parte m\u00e1s a la izquierda. Por ejemplo, si tenemos un \u00edndice compuesto por las columnas A, B y C, este servir\u00e1 como \u00edndice por: A, A-B y A-B-C. Si se utiliza un \u00edndice compuesto, tratar de elegir en primer lugar un valor con mayor cardinalidad.<\/p>","protected":false},"author":1,"featured_media":9295,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_uag_custom_page_level_css":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-69202","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sin-categorizar"],"acf":[],"uagb_featured_image_src":{"full":["https:\/\/enviame.somosforma.dev\/wp-content\/uploads\/2021\/12\/95003B04-3A36-41AB-AA55-9AF3C0089D5C.jpeg",640,427,false],"thumbnail":["https:\/\/enviame.somosforma.dev\/wp-content\/uploads\/2021\/12\/95003B04-3A36-41AB-AA55-9AF3C0089D5C-150x150.jpeg",150,150,true],"medium":["https:\/\/enviame.somosforma.dev\/wp-content\/uploads\/2021\/12\/95003B04-3A36-41AB-AA55-9AF3C0089D5C-300x200.jpeg",300,200,true],"medium_large":["https:\/\/enviame.somosforma.dev\/wp-content\/uploads\/2021\/12\/95003B04-3A36-41AB-AA55-9AF3C0089D5C.jpeg",640,427,false],"large":["https:\/\/enviame.somosforma.dev\/wp-content\/uploads\/2021\/12\/95003B04-3A36-41AB-AA55-9AF3C0089D5C.jpeg",640,427,false],"1536x1536":["https:\/\/enviame.somosforma.dev\/wp-content\/uploads\/2021\/12\/95003B04-3A36-41AB-AA55-9AF3C0089D5C.jpeg",640,427,false],"2048x2048":["https:\/\/enviame.somosforma.dev\/wp-content\/uploads\/2021\/12\/95003B04-3A36-41AB-AA55-9AF3C0089D5C.jpeg",640,427,false]},"uagb_author_info":{"display_name":"enviameioadm","author_link":"https:\/\/enviame.somosforma.dev\/pe\/author\/enviameioadm\/"},"uagb_comment_info":0,"uagb_excerpt":"Hace algunos meses, abordamos con el equipo una historia de usuario en donde nos informaban un lento rendimiento en una vista del sistema. Analizando la situaci\u00f3n, verificamos que el problema proven\u00eda de una consulta que no tomaba el \u00edndice correcto para la petici\u00f3n que se estaba solicitando. Esta circunstancia me motiv\u00f3 a escribir este art\u00edculo,…","yoast_head":"\n
<\/p>\n\n\n\n![\"\"](\"https:\/\/enviame.somosforma.dev\/wp-content\/webp-express\/webp-images\/doc-root\/wp-content\/uploads\/2021\/12\/image-1.jpeg.webp\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/enviame.somosforma.dev\/wp-content\/webp-express\/webp-images\/doc-root\/wp-content\/uploads\/2021\/12\/image-2.jpeg.webp\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/enviame.somosforma.dev\/wp-content\/webp-express\/webp-images\/doc-root\/wp-content\/uploads\/2021\/12\/image-3.jpeg.webp\")
<\/figure>\n\n\n\n
<\/p>\n\n\n\n![\"\"](\"https:\/\/enviame.somosforma.dev\/wp-content\/webp-express\/webp-images\/doc-root\/wp-content\/uploads\/2021\/12\/image-4.jpeg.webp\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/enviame.somosforma.dev\/wp-content\/webp-express\/webp-images\/doc-root\/wp-content\/uploads\/2021\/12\/image-5.jpeg.webp\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/enviame.somosforma.dev\/wp-content\/webp-express\/webp-images\/doc-root\/wp-content\/uploads\/2021\/12\/image-6.jpeg.webp\")
<\/figure>\n\n\n\n