Засада вот в чем.
Есть несколько таблиц с довольно большим количеством записей 5000000-20000000, длина записи до 80 байт (2-3 небольших поля). В таблицах основное поле, по которому идут соединения имеет тип BINARY(16) (суть идентификатор objectа).
Замечены большие чтения и тормоза в выполнении запросов. После замены типа BINARY(16) на INT (в целях отладки) с удивлением обнаружено совершенно иное построение плана выполнения запроса и ускорение его в несколько раз (при одинаковом наполнении таблиц и одинаковой структуре индексов).
Дальше больше
Замена INT на BIGINT дает совершенно обратный эффект, опять все тупит и план выполнения очень похож на вариант с BINARY(16). Причем замечено, что с INT оптимизатор применяет правильные по смыслу планы,а в ситуациях с BINARY(16) и BIGINT тупо строит HASH, что на большом количестве записей приводит к тормозам неимоверным. Такое ощущение, что оптимизатор знает, с BINARY(16) и BIGINT он может применить только HASH, когда с вариантом INT активно испотльуется MERGE и в небольших объемах LOOP. Статистику всех таблиц обновлял.

Каков может быть выход и какие мнения ?