Parece que ya sabes la respuesta, pero recuerda, mantén los sistemas que diseñas fáciles de modificar, ya que los modelos de negocios siempre cambian con el tiempo o eventualmente fallan (es una generalización, pero entiendes la idea). Un corolario de eso es que si haces un modelo rígido, rápido o lento, es rígido, los cambios serán más difíciles y el usuario final no verá la diferencia, por lo tanto, no se logra ningún cambio de dinero/felicidad, a menos que sea un cambio muy malo. Su problema no es técnico en la forma en que una consulta funciona en el motor, sino más bien filosófico, cambios fáciles versus velocidad aparente. Pregúntese, ¿cuál es la ventaja de tener una base de datos normalizada? Piense en una arquitectura y un diseño limpios, el rendimiento es el menor problema en el mundo actual, ya que el procesamiento es más económico y el almacenamiento también. Pero el diseño es caro. La normalización se hizo para crear sistemas que no dependieran de decisiones de último momento sino de un proceso de diseño estructurado. Las tablas grandes no son un gran problema para MySql, pero son un gran problema mantenerlas, modificarlas y expandirlas. No se trata solo de agregar una columna más, se trata de la estructura rígida de los datos en sí. Eventualmente, con el tiempo, simplemente agregará columnas que contienen índices, y esos índices apuntarán a tablas pequeñas. De todos modos, MySql buscará el camino alrededor de todos esos datos. Así que iré por el primero, muchas tablas pequeñas, muchas a muchas.
