Так что, возможно, это нуб, но я возился с парой столов.

У меня ТАБЛИЦА А примерно 45000 записей

У меня в ТАБЛИЦЕ B примерно 1,5 миллиона записей

У меня есть запрос:

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

Так что я форсирую индекс по ID, Lookup. У каждой таблицы также есть индекс по этим столбцам, но из-за подзапроса я его принудил.

Это займет ВЕЧНО, чтобы бежать, и это действительно должно занять, я думаю, меньше 5 минут ...

Мои вопросы касаются индексов, а не запроса.

Я знаю, что вы не можете использовать хеш-индекс в упорядоченном индексе.

В настоящее время у меня есть индексы как ID, Lookup отдельно, так и как один индекс, и это индекс B-Tree. На основании моегоWHERE Предложение, подходит ли хеш-индекс как метод оптимизации?

Могу ли я иметь один хэш-индекс, а остальные индексы b B-дерева индекса?

Это не поле первичного ключа.

Я бы опубликовал свое объяснение, но я изменил имя в этих таблицах. По сути, он использует индекс только для идентификатора ... вместо использования идентификатора, я хотел бы заставить его использовать оба, или, по крайней мере, превратить его в индекс другого типа и посмотреть, поможет ли это?

Теперь я знаю, что MySQL достаточно умен, чтобы определить, какой индекс является наиболее подходящим, так это то, что он делает? Поле Lookup отображает первую и вторую часть идентификатора ...

Любая помощь или понимание этого приветствуется.

ОБНОВИТЬ

EXPLAIN наUPDATE после того, как я вынул подзапрос.

+----+-------------+-------+------+-----------------------------+--------------+---------+-------------------+-------+-------------+
| 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 соответствующие индексы:

ID_LookupIdx (ID, Lookup)

tableb соответствующие индексы:

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

Все индексы являются нормальными B-деревьями.