¿Puedo configurar Mysql para la partición automática?

(Esta respuesta está dirigida al esquema y SELECCIONAR).

Dado que prevé millones de filas, primero quiero señalar algunas mejoras en el esquema.

• FLOAT(m,n) suele ser lo 'incorrecto' porque conduce a dos redondeos. O usa simple FLOAT (que parece 'correcto' para métricas como voltaje) o use DECIMAL(m,n) . FLOAT es de 4 bytes; en los casos dados, DECIMAL serían 3 o 4 bytes.

• Cuando tienes ambos INDEX(a) y INDEX(a,b) , el primero es innecesario ya que el segundo puede cubrirlo. Tienes 3 LLAVES innecesarias. Esto ralentiza INSERTs .

• INT(3) -- ¿Estás diciendo un "número de 3 dígitos"? Si es así, considera TINYINT UNSIGNED (valores 0..255) para 1 byte en lugar de INT para 4 bytes. Esto ahorrará muchos MB de espacio en disco, por lo tanto, velocidad. (Véase también SMALLINT , etc, y SIGNED o UNSIGNED .)

• Si filename se repite mucho, es posible que desee "normalizarlo". Esto ahorraría muchos MB.

• Usar NOT NULL a menos que necesite NULL por algo.

• AUTO_INCREMENT=690892041 implica que estás a 1/3 del camino al desastre con id , que alcanzará un máximo de unos 2.000 millones. ¿Usas id? ¿por nada? Deshacerse de la columna evitaría el problema; y cambie la UNIQUE KEY a PRIMARY KEY . (Si necesita id , hablemos más.)

• ENGINE=MyISAM -- El cambio tiene algunas ramificaciones, tanto favorables como desfavorables. La mesa se volvería 2-3 veces más grande. La elección 'correcta' de PRIMARY KEY aceleraría aún más esto SELECT significativamente. (Y puede o no ralentizar otros SELECTs .)

Una nota sobre el SELECT :Desde string y unit_num son constantes en la consulta, los dos últimos campos de ORDER BY timestamp asc, string asc, unit_num asc son innecesarios. Si son relevantes por razones no aparentes en el SELECT , entonces mi consejo puede estar incompleto.

esto

WHERE filename = 'foobar'
  AND unit_num='40'
  AND string='2' 
  AND timestamp >= ...

es manejado de manera óptima por INDEX(filename, unit_name, string, timestamp) . El orden de las columnas no es importante excepto esa timestamp tiene que ser último . Reorganizando el UNIQUE actual clave, te da el índice óptimo. (Mientras tanto, ninguno de los índices es muy bueno para este SELECT .) Haciéndola la PRIMARY KEY y la tabla InnoDB lo haría aún más rápido.

¿Fraccionamiento? Sin ventaja No para el rendimiento; no por nada más que hayas mencionado. Un uso común para la partición es para purgar 'antiguo'. Si tiene la intención de hacer eso, hablemos más.

En tablas grandes, es mejor mirar todos los SELECTs importantes simultáneamente para que no aceleremos uno mientras derribamos la velocidad de otros. puede incluso resulta que la partición ayuda en este tipo de compensación.