- \n
- Problemas de espacio con la\u00a0base de datos:<\/strong>\u00a0se supone que si tu\u00a0p\u00e1gina web est\u00e1 en continuo crecimiento, debes tener un buen plan en tu\u00a0hosting para no tener que preocuparte por problemas de espacio en disco. En mi caso, el sitio en el que trabaj\u00e9 contaba con un buen plan de VPS (Servidor Virtual Privado), as\u00ed que el espacio no era\u00a0el problema (la base de datos podr\u00eda pesar tantos\u00a0GB como quisiera).<\/li>\n
- Normalizaci\u00f3n de DB:\u00a0<\/strong>si has aplicado algo de ingenier\u00eda en tu base de datos\u00a0desde el principio, no tendr\u00edas que estar viendo este detalle ahora, salvo por supuesto\u00a0que se haya realizado grandes cambios en el sitio y se tenga que “reestructurar” la base de datos. En cualquier caso, no se hablar\u00e1 de esto aqu\u00ed porque hay mucha informaci\u00f3n en internet al respecto.<\/li>\n
- Problemas de servidor:<\/strong>\u00a0si eres el administrador del sitio, debes asegurarte que el problema no tiene nada que ver con tu servidor o servicio de hosting. Por ejemplo, hostings como\u00a0Godaddy son conocidos por ser de los peores del mercado (aun con la enorme publicidad con la que cuenta), as\u00ed que antes de realizar cualquier acci\u00f3n brusca en tu sitio web, cerci\u00f3rate primero que el problema no sea \u00e9se.<\/li>\n
- Crear un backup de tu base de datos:\u00a0<\/strong>Esto deber\u00eda estar de forma impl\u00edcita desde el comienzo de cualquier art\u00edculo o tutorial. Sin importar qu\u00e9 “optimizaci\u00f3n” vayas a realizar, o qu\u00e9 tan confiable sea\u00a0el art\u00edculo que te indique cambios a realizar\u00a0en una base de datos, por al amor de Dios SIEMPRE haz una copia de respaldo (backup) <\/strong>de toda tu base de datos.<\/li>\n<\/ul>\n
\nEntonces, \u00bfcu\u00e1l fue exactamente el problema que tuve?<\/h2>\n
El sitio web en el que trabaj\u00e9 era enorme<\/strong> y\u00a0las tablas<\/strong> donde se guardaban los detalles de las \u00f3rdenes de compra<\/strong>, simplemente no dejaban de crecer<\/strong>. La cantidad de\u00a0tuplas que almacenaba cada tabla iba desde 70k<\/strong> hasta 300k<\/strong>,\u00a0las cuales\u00a0continuaban aumentando cada d\u00eda.<\/p>\n
Esto ocasionaba que el sitio web se colgara<\/strong>\u00a0o se pusiera muy\u00a0lento<\/strong> cuando comenzaban a ejecutarse consultas relacionadas a las compras<\/strong>, como por ejemplo: historial de compras del cliente, estad\u00edsticas de la tienda, reportes diversos, etc.<\/p>\n
En algunos casos lo\u00a0recomendable ser\u00eda simplemente subir a un plan superior de VPS, pero despu\u00e9s de analizar su base de datos me di cuenta que aquello no servir\u00eda de nada y el sitio seguir\u00eda lento.<\/p>\n
Quiz\u00e1s alguno de ustedes se haya hecho la pregunta:<\/p>\n
Hey, si tu problema solamente radica en las\u00a0\u00f3rdenes de compra, \u00bfentonces\u00a0por qu\u00e9 simplemente no eliminaste las \u00f3rdenes de compras viejas?\u00a0<\/strong><\/em><\/span><\/p>\n
Lastimosamente eso no se puede realizar en la mayor\u00eda de los casos, ya que como dije antes toda esa informaci\u00f3n es de bastante utilidad<\/strong>\u00a0para el sitio al sacar historiales<\/strong> y estad\u00edsticas<\/strong> diversas, ya sea para los clientes<\/strong> como tambi\u00e9n para los administradores<\/strong> del sitio. Adem\u00e1s, las bases de datos est\u00e1n hechas precisamente para eso: ALMACENAR DATOS<\/strong>, de modo que no se deber\u00eda ELIMINAR nada, salvo por supuesto “informaci\u00f3n basura” que realmente no tenga utilidad alguna en el sitio.<\/p>\n
Bueno, ya le di demasiadas vueltas al asunto.<\/span> AHORA VAYAMOS AL GRANO!<\/strong><\/span><\/p>\n
\nSoluci\u00f3n<\/h2>\n
Despu\u00e9s de buscar bastante por la red y preguntar en foros, finalmente logr\u00e9\u00a0optimizar la base de datos<\/strong>\u00a0realizando \u00fanicamente\u00a0dos acciones<\/strong>:<\/p>\n
1) Cambiar el motor de almacenamiento a InnoDB<\/h3>\n
La base de datos del sitio estaba usando el motor de almacenamiento\u00a0MyISAM,<\/strong>\u00a0el cual ten\u00eda entendido\u00a0proporcionaba una alta velocidad de acceso<\/strong>, sobre todo cuando solamente se necesita “leer datos” y no as\u00ed en la “escritura”. As\u00ed que como el sitio se lenteaba al leer datos para los reportes y estad\u00edsticas, pues pens\u00e9 que el problema no ten\u00eda que ver con MyISAM.<\/p>\n
Sin embargo llegu\u00e9 a descubrir que lo m\u00e1s recomendable era siempre manejar InnoDB,\u00a0aunque\u00a0lo m\u00e1s experimentados en el tema saben en qu\u00e9 casos conviene mejor usar MyISAM.\u00a0En todo caso, si no sabes qu\u00e9 motor de almacenamiento usar en mysql, ve siempre por InnoDB<\/strong>.<\/p>\n
Personalmente al principio cre\u00ed que iba a ser mucho m\u00e1s lento el sitio con InnoDB, pero todas mis dudas y temores fueron disueltos\u00a0cuando apliqu\u00e9 la \u00faltima acci\u00f3n que describo abajo.<\/p>\n
2) Agregar una gran cantidad de \u00edndices<\/h3>\n
He aqu\u00ed el factor m\u00e1s importante para\u00a0optimizar una base de datos… la creaci\u00f3n de \u00edndices<\/strong><\/span>.<\/p>\n
Si bien ya sab\u00eda que los \u00edndices agilizan bastante las\u00a0consultas, me di cuenta de mi error al percatarme de que no ten\u00eda una buena cantidad\u00a0de \u00edndices en mi base de datos.<\/p>\n
Sin entrar en muchos detalles, les dir\u00e9 que existen varios\u00a0tipos de \u00edndices, pero de momento solo\u00a0nos interesar\u00e1n los siguientes\u00a0dos:<\/p>\n
- \n
- \u00cdndices de claves primarias:\u00a0<\/strong>es decir el\u00a0primary key<\/strong><\/em>\u00a0con el que estoy seguro que cuentan todas sus bases de datos. No pueden tener valores duplicados.<\/li>\n
- \u00cdndices ordinarios:\u00a0<\/strong>aquellos que son creados de forma “manual” y que\u00a0no tienen nada que ver con la llave primaria de la tabla. Estos \u00edndices pueden tener valores duplicados siempre y cuando su campo no tenga el atributo UNIQUE.<\/li>\n<\/ul>\n
Para optimizar nuestra base de datos, tendremos que crear una buena cantidad de \u00edndices “ordinarios” para agilizar nuestras\u00a0consultas.<\/p>\n
\n\u00bfY c\u00f3mo creo \u00edndices para mi tabla?<\/h2>\n
Lo primero que debes hacer es\u00a0IDENTIFICAR<\/strong>\u00a0qu\u00e9\u00a0campos deber\u00edan\u00a0tener \u00edndices. Esto debe ser analizado para cada tabla. Por lo general deber\u00edas\u00a0crear un \u00edndice a todo campo o columna que trabaje como llave for\u00e1nea<\/strong> o\u00a0foreign key<\/strong>. Es decir, aquellos campos que sirven para conectar tus tablas\u00a0en consultas matriciales.<\/p>\n
Por ejemplo, si tengo la tabla “order_detail”<\/strong> y uno de sus campos es “customer_id”<\/strong>, entonces obviamente\u00a0que a trav\u00e9s del campo “customer_id” puedo obtener informaci\u00f3n de una tabla “customer_information” <\/strong>realizando una consulta matricial.<\/p>\n
![\"indices_tabla_ejemplo\"](\"http:\/\/www.chaosrequiem.com\/main\/wp-content\/uploads\/2016\/06\/indices_tabla_ejemplo.png\")
<\/p>\nPor lo tanto, yo deber\u00eda agregar un \u00edndice<\/strong> para este campo realizando la siguiente consulta:<\/p>\n
\r\n\r\nALTER TABLE `order_detail` ADD INDEX ( `customer_id` ) ;\r\n\r\n<\/pre>\n
Y listo!\u00a0El \u00edndice se crear\u00e1 correctamente en la base de datos. Esta consulta\u00a0s\u00f3lo debe realizarse una sola vez, similar a la creaci\u00f3n de llaves primarias<\/strong>.<\/p>\n
Esto nos servir\u00e1 de mucho cuando se ejecute una consulta\u00a0que involucren las tablas “order_detail” y “customer_information”, ya que gracias al \u00edndice creado ahora se ejecutar\u00e1 mucho m\u00e1s r\u00e1pido<\/strong> sin importar la cantidad de tuplas que tengan dichas tablas (lean acerca de \u00edndices<\/strong> si quieren saber el por qu\u00e9).<\/p>\n
Ahora s\u00f3lo toca crear los \u00edndices<\/strong> que vean convenientes para cada tabla<\/strong>, ya que uno solo no basta.<\/p>\n
Por ejemplo, en la misma\u00a0tabla “order_detail”<\/strong> yo podr\u00eda\u00a0tener campos como “address_id”, “shipping_id”, “coupon_id”<\/strong>, etc. de modo que me corresponder\u00eda crear un \u00edndice para cada campo mencionado. Luego deber\u00eda\u00a0ponerme a examinar cada tabla de la base de datos y crear los \u00edndices respectivos.<\/p>\n
Y eso es todo. Una vez hayan agregado una buena cantidad de \u00edndices (si su DB es grande), ver\u00e1n los\u00a0GRANDES RESULTADOS\u00a0<\/strong>al volver a navegar en\u00a0su sitio web o sistema:\u00a0historiales, reportes, estad\u00edsticas y toda informaci\u00f3n extensa ser\u00e1 ejecutada en un abrir y cerrar de ojos<\/strong>.<\/p>\n
![\"mission-complete-stamp-small\"](\"http:\/\/www.chaosrequiem.com\/main\/wp-content\/uploads\/2016\/06\/mission-complete-stamp-small.jpg\")
<\/p>\n
\nNotas finales<\/h2>\n
- \u00cdndices ordinarios:\u00a0<\/strong>aquellos que son creados de forma “manual” y que\u00a0no tienen nada que ver con la llave primaria de la tabla. Estos \u00edndices pueden tener valores duplicados siempre y cuando su campo no tenga el atributo UNIQUE.<\/li>\n<\/ul>\n
- Normalizaci\u00f3n de DB:\u00a0<\/strong>si has aplicado algo de ingenier\u00eda en tu base de datos\u00a0desde el principio, no tendr\u00edas que estar viendo este detalle ahora, salvo por supuesto\u00a0que se haya realizado grandes cambios en el sitio y se tenga que “reestructurar” la base de datos. En cualquier caso, no se hablar\u00e1 de esto aqu\u00ed porque hay mucha informaci\u00f3n en internet al respecto.<\/li>\n