¿Es seguro agregar índices a una base de datos de Drupal?


12

He estado buscando y leyendo sobre esto, pero no he visto nada definitivo sobre el tema de agregar índices a las tablas de Drupal (tanto core como contrib).

Mi principal preocupación es lo que sucede con los índices personalizados cuando actualiza el núcleo o el código contrib y hay cambios de esquema. ¿Qué pasa en este caso?

EDITAR:

Creo que algún contexto puede ayudar. Me preocupa principalmente agregar índices a las tablas para ajustar el rendimiento del sitio (consultas que aparecen en el registro lento de consultas, páginas con vistas lentas, etc.). Esto puede implicar agregar un índice a una tabla en el módulo de otra persona. Por ejemplo

  1. Instalo el modulo foo
  2. Módulo foo crea tabla foo
  3. Agrego un índice a la tabla foo
  4. El módulo footiene una actualización que cambia el esquema

¿Lo que pasa?

Respuestas:


7

Sí, podría provocar problemas.

Si un módulo quiere hacer algo con la columna en la que ha agregado un índice, eliminará sus propios índices y luego realizará cualquier operación que tenga la intención de hacer.

Lo que sucederá exactamente dependerá de su tipo de base de datos y de la operación realmente ejecutada. Por ejemplo, un cambio de nombre de la columna funcionará bien con MySQL, pero fallará en PostgreSQL. Pero si intenta eliminar esa columna (tal vez después de migrar datos a una tabla / columna diferente), fallará.

Las posibilidades de que esto suceda son relativamente bajas, al menos para actualizaciones menores (sin embargo, depende del módulo real. Por lo general, no agrego ningún cambio que pueda romper algo en las versiones menores), pero es posible.

Mi sugerencia sería que intentes trabajar junto con los encargados del mantenimiento del módulo. Si la (s) consulta (s) problemática (s) provienen del módulo en sí, entonces los mantenedores probablemente agregarán los índices con gusto, si proporciona un parche. Proporcione la salida DESCRIBE de las consultas problemáticas antes y después de agregar el índice. También proporcione un parche que actualice el esquema (incluya una función de actualización para configurarlo para las instalaciones existentes).

Alguien que está trabajando activamente en cosas relacionadas con el rendimiento y hace realmente lo anterior es atrapar, aquí hay un ejemplo: http://drupal.org/node/983950


2

Como se informó en DatabaseSchema_pgsql :: changeField y en db_change_field () :

NOTA IMPORTANTE: Para mantener la portabilidad de la base de datos, debe recrear explícitamente todos los índices y claves principales que utilizan el campo modificado.

Eso significa que debe eliminar todas las claves e índices afectados con db_drop_ {primary_key, unique_key, index} () antes de llamar a db_change_field (). Para recrear las claves y los índices, pase las definiciones clave como el argumento opcional $ new_keys directamente a db_change_field ().

Por ejemplo, suponga que tiene:

$schema['foo'] = array(
  'fields' => array(
    'bar' => array('type' => 'int', 'not null' => TRUE)
  ),
  'primary key' => array('bar')
);

y desea cambiar foo.bar para que sea de tipo serial, dejándolo como la clave principal. La secuencia correcta es:

db_drop_primary_key($ret, 'foo');
db_change_field($ret, 'foo', 'bar', 'bar',
  array('type' => 'serial', 'not null' => TRUE),
  array('primary key' => array('bar'))
);

Se informa un código similar para Drupal 7.

Tenga en cuenta que, según mi experiencia, no puede eliminar una clave primaria que utiliza un campo en serie. En Drupal 6, recibí un error cada vez que intentaba hacerlo; No probé eso en Drupal 7.

Aparte de eso, no conozco ningún otro problema que pueda tener con los índices de la base de datos.

Acerca de agregar un índice a una tabla de base de datos que se crea desde otro módulo, no sugeriría hacerlo porque:

  • Un módulo no suelta un índice para un campo que se está cambiando, si el módulo en sí no creó ese índice. No sería posible que el módulo haga eso porque no conoce el nombre del índice.
  • Modificar una tabla de base de datos creada por otro módulo nunca es una buena idea, incluso en el caso de que el módulo sea un módulo central. Si hay otro módulo que cambia la misma tabla, ¿cómo podrían los módulos manejar cualquier conflicto que tengan entre sí, o con los cambios que el módulo central aplicaría a su propia base de datos?

Si la tabla de la base de datos se está creando desde otro módulo (un módulo central o un módulo de terceros), sugeriría abrir una solicitud de función para el módulo, proporcionando un caso de uso para usar un nuevo índice; Si hay algún problema de rendimiento, agregar un índice podría ser lo que se desea hacer.

Si va a agregar un índice a una tabla creada a partir de otro módulo en su propio sitio, entonces esté preparado para cualquier cambio que necesite hacer a su módulo personalizado cada vez que el módulo se actualice y antes de instalarlo en su propio sitio .
Es usted quien puede decidir si el trabajo extra vale el rendimiento que obtiene. Sin embargo, personalmente no creo que valga la pena.


Gracias. ¿Cómo funcionaría esto si agrego un índice a una tabla para combatir una consulta lenta, no solo un cambio en mi propio módulo? Intentaré editar mi pregunta para que quede un poco más claro cuando tenga la oportunidad.
mpdonadio

3
También puede considerar usar DB Tuner, que es útil para saber qué índices crear.
tostinni

@tostinni Sí, la pregunta estaba casi directamente relacionada con la implementación de las recomendaciones de DB Tuner.
mpdonadio
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.