Bajo rendimiento de mysql y php

[robervcp]

es dificil dar un consejo cuando uno nunca hizo la prueba.

Pero creo que lo mejor que te puedo decir es que repases los consejos simple de siempre para el tema de consultas...
Seguro que ya los sabes, pero quizas alguien no.

Personalmente, se que algo te puede ayudar muchisimo, a la hora de las consultas, es pedir solo los datos necesarios...

Siempre somos del SELECT * (verdad?)

Lo otro importantisimo, es que estudies nuevamente el tipo de campo que has establecido para las tablas, CHAR, VARCHAR. aunque no parezca, eso afecta.saludos

aca te paso algo que siempre leo, pero no siempre respeto ;)


Uno de los pasos cruciales en la construcción de una aplicación que maneje una base de datos, es sin duda, el diseño de la base de datos. Si las tablas no son definidas apropiadamente, podemos tener muchos dolores de cabeza al momento de ejecutar consultas a la base de datos para tratar de obtener algún tipo de información.

No importa si nuestra base de datos tiene sólo 20 registros, o algunos cuantos miles, es importante asegurarnos que nuestra base de datos está correctamente diseñada para que tenga eficiencia y usabilidad a lo largo del tiempo.

En este artículo, se mencionarán algunos principios básicos del diseño de base de datos y se tratarán algunas reglas que se deben seguir cuando se crean bases de datos. Dependiendo de los requerimientos de la base de datos, el diseño puede ser algo complejo, pero con algunas reglas simples que tengamos en la cabeza será mucho más fácil crear una base de datos perfecta para nuestro siguiente proyecto.

Construir grandes aplicaciones en MySQL resulta fácil con herramientas como Apache, Perl, PHP, y Python. Asegurarse de que son rápidas, sin embargo, requiere algo más que perspicacia. MySQL tiene una bien merecida reputación de ser un servidor de bases de datos muy rápido que también es muy fácil de configurar y usar, además de que en los últimos años su popularidad ha crecido notablemente debido a que se utiliza en infinidad de sitios web que requieren hacer uso de una base de datos. Sin embargo, pocos usuarios sabemos algo más que crear una base de datos y escribir algunas búsquedas contra ella.

Después de leer este artículo debemos ser capaces de entender algunas técnicas que nos ayudarán a diseñar bases de datos MySQL para construir mejores aplicaciones. Vamos a suponer que se tiene un conocimiento básico del lenguaje SQL, y de MySQL, pero no vamos a asumir que se tiene mucha experiencia en alguno de los dos.



Almacenar sólo la información necesaria

Parece de sentido común, pero muchas personas suelen tomar el enfoque de "sumidero de cocina" para el diseño de bases de datos. A menudo pensamos en todo lo que quisiéramos que estuviera almacenado en una base de datos y diseñamos la base de datos para guardar dichos datos. Hemos de ser realistas acerca de nuestras necesidades y decidir qué información es realmente necesaria. Frecuentemente podemos generar algunos datos sobre la marcha sin tener que almacenarlos en una tabla de una base de datos. En estos casos también tiene sentido hacer esto desde el punto de vista del desarrollo de la aplicación.

Por ejemplo, una tabla de productos para un catálogo en línea puede contener nombres, descripciones, tamaños, pesos y precios de varios productos. Además del precio, puede que se quieran guardar los impuestos y los gastos de envío asociados con cada producto. Pero realmente no hay ninguna necesidad de hacer esto. Primero, tanto los impuestos como los gastos de envío pueden ser calculados sobre la marcha (ya sea por nuestra aplicación, o por MySQL). Segundo, si cambiamos los impuestos o los gastos de envío, tendríamos que escribir las búsquedas necesarias para actualizar los impuestos y los gastos de envío en cada registro del producto.

Algunas veces pensamos que agregar campos a las tablas de una base de datos una vez que han sido creadas es demasiado difícil, así que nos vemos impulsados a definir tantas columnas como se pueda. Bueno, esto simplemente es un concepto erróneo, ya que en MySQL podemos usar el comando ALTER TABLE para modificar la definición de una tabla en cualquier momento para que se adecue a nuestras necesidades cambiantes.

Por ejemplo, si en algún momento nos damos cuenta que necesitamos agregar una columna de popularidad a nuestra tabla productos (tal vez queramos que nuestros clientes califiquen los productos en nuestro catálogo), podríamos hacer lo siguiente:

ALTER TABLE productos ADD popularidad INTEGER;


Este comando agrega una columna popularidad del tipo entero a nuestra tabla productos.


Pedir sólo lo necesario y ser explícito

Igual que decir "almacenar sólo lo necesario", esto puede parecer un poco más de sentido común, sin embargo, esto no suele ser considerado muy a menudo. ¿Por qué?. Porque cuando una aplicación está en desarrollo los requerimientos suelen cambiar, de tal forma que muchas de las búsquedas terminan pareciéndose a esto:

SELECT * FROM algunaTabla;


Obtener todas las columnas de una tabla es simplemente lo más conveniente que podemos hacer cuando no estamos seguros de qué campos necesitamos. Sin embargo, a medida que las tablas crecen y cambian, esto puede convertirse en un problema de rendimiento. A la larga es mucho mejor tardarnos un tiempo extra después de nuestro desarrollo inicial y decidir exactamente qué es lo que necesitamos en nuestras búsquedas. En concreto, es mucho mejor especificar las columnas de forma explícita:

SELECT nombre, precio, descripcion FROM productos;


Esto se relaciona con un punto que tiene que ver más con el mantenimiento del código que con el rendimiento. La mayoría de los lenguajes de programación (Perl, Python, PHP, Java, etc) nos permiten acceder a los resultados de una consulta por los nombres de los campos y por su posición numérica. Para el ejemplo anterior, podemos acceder al campo 0, o al campo /nombre/ y obtener los mismos resultados.

A la larga es mejor usar los nombres de columnas que sus posiciones numéricas. ¿Por qué? Porque las posiciones relativas de columnas en una tabla o en un resultado de una consulta pueden variar. Por ejemplo, pueden variar en una tabla como resultado de un ALTER TABLE, o bien, cambiarán en una consulta como resultado de que alguien rescriba la búsqueda y se olvide de actualizar la lógica de la aplicación apropiadamente.

Claro está, ¡aún debemos ser cuidadosos cuando cambiemos los nombres de las columnas! Pero si usamos nombres en vez de posiciones numéricas, podemos usar la capacidad de búsqueda y reemplazo de nuestro editor para encontrar el código que hemos de cambiar en caso de que cambie el nombre de una columna.