Tablas de gran tamaño no son necesariamente una buena solución. Es mejor la normalización de las tablas y un diseño más eficiente, relevando el tipo real de información que se consulta, antes que crear tablas de formas que no resultan a la larga muy eficientes.
Por lo general, si una consulta tarda demasiado es posible que el filtrado de datos devuelva demasiada información, o bien las subconsultas no acoten bien la info buscada, la masa de información transferida sea por ende demasiado grande.
Ten en cuenta que, en una máquina pequeña, barrer toda una tabla para buscar datos, con 1.500.00 registros, puede tardar 20 segundos, pero mandarla por la web puede llevar más de 5 minutos, si el bloque de datos recuperados es demasiado grande, por lo que la falla no estaría en la base de datos, sino en la consulta misma.
Para aclarar el panorama, en gran porcentaje de los problemas de la lentitud de una consulta se fundamentan en las siguienes fallas:
1.
Aplicaciones mal diseñadas. Muchos programadores "piensan" que las bases de datos deben ser siempre las responsables o que deben hacer tareas para las que no están diseñadas.
2.
Una errónea concepción del sistema. Habitualmente producto de errores de relevamiento, o mala comprensión de las reglas del negocio.
3.
Errores en la concepción del modelo de datos, usualmente originado en el punto anterior. Aprender a estructurar la información, las tablas y los índices, así como su normalización o desnormalización es fundamental a la hora de diseñar.
4.
Falta de normalización y optimización del modelo. Esto tiene que ver con la experiencia y conocimientos adquiridos por el DBA.
5.
Errores en la optimización de las consultas. Hay que practicar mucho y conocer muy bien cómo funciona el motor de la base de datos y cómo realiza las operaciones para saber optimizar una consulta. A pesar de eso, hay algunas cuanta reglas que te pueden ayudar.
6.
Distribución de la base de datos. El hecho que una base de datos sea centralizada o distribuida (vía MySQL Cluster), afecta mucho la eficiencia de una consulta a bases de datos grandes.
7.
Hardware no optimizado. A pesar de que MySQL puede funcionar óptimamente con un hardware bastante elemental, no todos los modelos de hardware responderán igual a las consultas, según el tamaño y complejidad de la base de datos.
8.
Topología de la LAN y enlaces. Casi nadie lo menciona, pero si la información es muy voluminosa, dependiendo de la cantidad, afectarán el rendimiento de la red y se verán afectadas por él.
Habiéndote aburrido lo suficiente con ésto, te recomiendo echarle una mirada a estas páginas sobre optimización:
Optimización de MySQL Optimizing MySQL Queryes & Indexes MySQL Optimization 10 Tips for MySQL Opmization