Tal vez esto sea noob, pero estoy jugando con un par de mesas.

Tengo TABLA A unos 45.000 discos.

Tengo la TABLA B de aproximadamente 1.5 millones de discos.

Tengo una consulta:

update
    schema1.tablea a
    inner join (
        SELECT DISTINCT
            ID, Lookup,
            IDpart1, IDpart2
        FROM
            schema1.tableb
        WHERE
            IDpart1 is not NULL
        AND
            Lookup is not NULL
        ORDER BY
            ID,Lookup
    ) b Using(ID,Lookup)
set 
    a.Elg_IDpart1 = b.IDpart1, 
    a.Elg_IDpart2 = b.IDpart2
where
    a.ID is NOT NULL
AND
    a.Elg_IDpart1 is NULL

Así que estoy forzando el índice de identificación, Búsqueda. Cada tabla también tiene un índice en esas columnas, pero debido a la subconsulta la forcé.

Se está tomando PARA SIEMPRE correr, y realmente debería tomar, me imagino que en menos de 5 minutos ...

Mis preguntas se refieren a los índices, no a la consulta.

Sé que no se puede usar el índice hash en el índice ordenado.

Actualmente tengo índices tanto en ID como en Búsqueda, y como un índice, y es un índice B-Tree. Basado en miWHERE ¿Cláusula, se ajusta un índice hash como una técnica de optimización?

¿Puedo tener un solo índice de hash y el resto de los índices b índice de árbol B?

Este no es un campo de clave principal.

Publicaré mi explicación pero cambié el nombre en estas tablas. Básicamente, está usando el índice solo para ID ... en lugar de usar la ID, Buscar, me gustaría forzarlo a usar ambos, o al menos convertirlo en un tipo diferente de índice y ver si eso ayuda.

Ahora sé que MySQL es lo suficientemente inteligente como para determinar qué índice es el más apropiado, ¿entonces eso es lo que está haciendo? El campo de búsqueda asigna la primera y la segunda parte de la ID ...

Cualquier ayuda o percepción sobre esto es apreciada.

ACTUALIZAR

UnEXPLAIN sobre elUPDATE después saqué la sub-consulta.

+----+-------------+-------+------+-----------------------------+--------------+---------+-------------------+-------+-------------+
| id | select_type | table | type |        possible_keys        |     key      | key_len |        ref        | rows  |    Extra    |
+----+-------------+-------+------+-----------------------------+--------------+---------+-------------------+-------+-------------+
|  1 | SIMPLE      | m     | ALL  | Lookup_Idx,ID_Idx,ID_Lookup |              |         |                   | 44023 | Using where |
|  1 | SIMPLE      | c     | ref  | ID_LookupIdx                | ID_LookupIdx |       5 | schema1.tableb.ID |     4 | Using where |
+----+-------------+-------+------+-----------------------------+--------------+---------+-------------------+-------+-------------+

tablea índices relevantes:

ID_LookupIdx (ID, Lookup)

tableb índices relevantes:

ID (ID)Lookup_Idx (Lookup)ID_Lookup_Idx (ID, Lookup)

Todos los índices son árboles B normales.