[guillotmarc]

Hola.

Felicidades por resolver el problema, pero la explicación que has dado es errónea, puede llevar a confusión a otra persona que llegue hasta aquí por un problema similar.

Algo más de lo que te sugirió Román has hecho, puesto que lo que dices no tiene sentido, es harto difícil de creer.

Es imposible que un delete from remision where fecha <= :xFecha te tarde ocho horas, añadas un índice sobre el campo Fecha (que es el índice que te sugirieron crear ya que es el único campo que interviene, no la clave primaria) y milagrosamente ese borrado pase a tardar dos segundos.

Simplemente no puede ser, si el motor SQL no encuentra un índice para Fecha, se ve obligado a recorrer toda la tabla buscando las fechas menores a cierto valor. Pero eso puede tardar un par de minutos (como máximo), nunca ocho horas.

NOTA: Resulta evidente que has solucionado el problema mediante índices sobre las tablas secundarias que son borradas en triggers. Así que no te equivoques, tu problema estaba en esos triggers, en lo que tardaban en ejecutarse al no estar debidamente optimizados (lo cual, como te dijimos, multiplicado por 100.000 registros a borrar, es lo único que puede explicar un tiempo de ejecución de ocho horas).

PD: Las Primary Keys siempre están ordenadas, puesto que siempre existe un índice para la clave primaria que definas en la tabla (ese índice lo crea automáticamente el sistema). Tú te estas refiriendo a que has creado índices para las Foreign Keys, es decir, las referencias en tus tablas secundarias que apuntan a la tabla a borrar.

Saludos.