MySQL Optimización de una tabla con filas 137000

Question

Estoy tratando de optimizar una base de datos Redmine antes de que sea demasiado de un dolor; los cambios (básicamente un registro de todos los cambios de SVN) es en filas 137000 (ISH) y la mesa se ajusta a la configuración predeterminada ASIC b. Sin embalaje clave, etc.

La tabla es la siguiente

ID int[11] Auto Inc (PK)
changeset_id int[11]
action varchar[1]
path varchar[255]
from_path varchar[255]
from_revision varchar[255]
revision varchar[255]
branch  varchar[255]

Índices: Primaria (ID), Francia changeset_id establecido en el índice BTREE

Todo el juego de caracteres latin1 basado en un poco de información de http://forge.mysql.com/ wiki / Top10SQLPerformanceTips

El motor de la tabla es InnoDB Paquete Keys está definido como predeterminado (sólo paquetes varchar char)

Todas las otras opciones están desactivadas.

¿Cuál es la mejor manera de optimizar esto? (Bar Truncar; o))

Answer 1

Hay algunas técnicas generales de optimización para MySQL: el primero sería hacer que sus tipos de datos encajan el ABC (ver aquí ). El pasar a continuación, de arriba a abajo, de identificación y changeset_id verse bien, la acción probablemente debería ser un char 1 en lugar de un varchar (anulable si se puede dejar en blanco (y, en general, asegúrese de que su anulable se establece correctamente en otros campos)). En cuanto a los otros 5 campos (que, dependiendo del tamaño, probablemente dominará la tabla), son cadenas del tipo de datos correcto? (Supongo que sí con la ruta, from_path, rama, pero tal vez la revisión debería ser un número (supongo que no es lo que soporta git o algo así))

Además, se ven como objetivos de normalización, especialmente desde un "caminos" y "revisiones" mesa sería normalizar cuatro de ellos ( aquí hay un tutorial básico, si lo necesita)

Answer 2

Depende por completo de sus características de lectura y escritura, es decir, las consultas que está haciendo, y la frecuencia con la que estás escribiendo a la misma.

La forma de optimizar para la escritura es reducir al mínimo el número de índices. Idealmente, se utiliza lo que en MS SQL Server sería el "índice agrupado" con una llave de forma monótona incrementando, lo que garantiza que escriba nuevos registros al final de la mesa, y se escribe ningún otro índice separado. Mejor aún, incluso, es saltarse el DBMS y escribir en un archivo de registro simple y llano de algún tipo, si no necesita ninguna capacidad transaccional.

Para consultas, así, que puede llegar tan complejo como desee. Tenga en cuenta, sin embargo, que si necesita una cantidad significativa de datos de la tabla para una consulta (es decir, es algo más que mirar un registro único basado en una clave), los recorridos de tablas pueden no ser tan malo. En general, si usted está examinando más de 3-5% de los contenidos de una tabla, un recorrido de tabla será muy rápido. Una vez más, por esto, un archivo simple y llano será probablemente más rápido que un DBMS.

Si usted tiene que optimizar tanto, considerar la optimización para escribir, y luego hacer una copia de forma regular que optimice para las consultas, y hacer las consultas contra la copia.