MySQL медленная выборка по PRIMARY KEY, что делать?

У меня вот, наоборот, проект постепенно мигрирует с монги на postgresql. Те запросы, которые в монги тормозят время от времени, в постгре даже без шаманизма работают быстро (оговорка используется fts в постгре, там запросы с OR слегка подтормаживают и нужно шаманить).

Не смотря на то, что автор уже определился с выбором, там на самом деле ещё бы конфиг MySQL глянуть, потому что если там есть query_cache, он может довольно таки хорошо убивать производительность, если запросы летят в разные части индекса, и есть запросы на вставку.

Я сталкивался с багом, когда на двух почти идентичных VPSках (2 гб, и 1 ядро), с одинаковыми данными, с одинаковыми конфигами, на одной VPS планировщик выбирал эффективный план, а на другой - медленный. Помог логический дамп, и пересоздание базы и таблиц.

Если почти не будет операций вставки/удаления, то норм. Если же будут вставки/удаления, то имхо лучше рассмотреть другой вариант сделать виртуальный диск из памяти и кинуть майисамную таблицу туда (вместо создавания мемори). Останутся все преимущества обычной таблицы и одновременно с этим реактивная скорость.

Solmyr, попробуйте залимитировать выборку. Или вам сразу нужны все результаты сразу?

Поле ID строковое? https://ru.stackoverflow.com/a/511197/179289

Может есть возможность изначально разбить этот массив данных. Заведомо как-то переформировать. Например по алфавиту ключа и тд.

Партишенинг или шардинг всегда должен работать медленнее чем первичный ключ, даже для ключа типа BTREE не говоря о ключе HASH. Если партишенинг работает быстрее ключа, с ключом точно что-то не так.

---------- Добавлено 28.03.2020 в 16:48 ----------

FTS я вообще делаю на сфинксе, пока минусов не заметил.

Я со сфинкса переехал на постгре. Сфинкс тогда остановился в развитии был (это было года 3 назад) и новый поиск у постгре была быстрее. Сейчас трудно сказать, но у постгре моментальный фтс, если не OR между словами и массив лемм не сотни на одну запись.

А у меня и то, и другое. :)

С чего вы это взяли?

С того что BTREE всегда эффективно делит подмножества, а партишенинг не всегда, даже при эффективной природе ключа партишенинга количество подмножеств не всегда равно степени двойки.

Партиционирование по хешу тоже делит данные эффективно. Учитывая, что там можно использовать даже PARTITION BY HASH (id div 1000), таким образом ряд из 1000 непрерывных id попадет в одну и ту же партицию. И можно даже range запросы делать по ним. Оптимизатор знает, в какую партицию ему сходить на основании запроса. Ему нужно ходить по дереву небольшой партиции, вместо большого дерева одной жирной таблицы. Вставка, кстати, тоже более эффективна.

А почему количество подмножеств должно быть равно степени двойки? :)