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

1 секунда = 1000 милисекунд.

5000мс = 5 секунд.

Explain запроса делали ?

На запрос и структуру таблицы взглянуть бы

id select_type table type possible_keys key key_len ref rows Extra

1 SIMPLE the_table const PRIMARY PRIMARY 96 const 1

Запрос:

SELECT id, value FROM the_table WHERE id='dfghekagr'

Структура длинная, лень красиво постить. 22 поля в общей сложности, типов INT, FLOAT и CHAR(n). Подробности разве могут иметь значение если row type FIXED?

МонгоДБ к гадалке не ходи достает данные из кэша так или иначе.

А у Вас майисам база на 2млн записей по 2.5кб - это 5гб. В память так полагаем вся не влезает? Тогда идет считывание с хдд.

Время позиционирования у хдд на 7200 об/мин до 0.0083 секунды, а еще надо не забыть эти 2 килобайта считать + у хдд еще другие дела есть.

Пусть у Вас серверные диски с 15000об/мин, ну допустим это будет 0.0042 секунды время позиционирования, если диск ничем не занят.

Чем Вам 0.005 секунды в этом варианте не нравится? :) Откуда там 0.0002 возьмуться, если чисто по физике диск спозиционироваться даже не успеет?

В иннодб проще засунуть всю базу в кэш, если скорость действительно критична и других минусов нет - переходите на иннодб и ставьте размер кэша что бы вся база влезала.

сортировка есть по какому-то полю? Если есть, то есть ли по нему индекс?

Раньше помогало составной ключ на id, value. Ну и иннодб. Если оп есть, чтоб оно поместилось. Давно на монге, мускул стал забывать.

Там тоже через гадалку, если запаса оп нет. На 1 млн по "_id" на хдд, после systemctl restart mongod в зависимости от (ну, начнем с load average) вполне может от 1 до 5сек. На прогретом и 200 микросек м/б. Все зависит от наличия оп, ну и

wiredTiger:

  engineConfig:

    cacheSizeGB:

знама что:

делать базу распределенной. (реляционной)

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

что в итоге? (10 или больше таблиц по 150 000 записей в каждой вместо одной на 1500000- как понимаете разница при выборке будет и существенная)

других действенных решений как таковое нет - всякие там опции настройки они если и выиграют вам 0,05 секунд вам оно погоду не сделает..

ну а в реале если записей больше миллиона это уже свой сервер а не хостинг и работают уже с Оракл - он для больших БД и разрабатывался....

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

там оно не что то не не так

это результат разных технологий...

как всегда есть как свои плюсы так и минусы.... (дело в том что 200мс это тоже много, конечно смотря где и смотря для чего.. вот к примеру сайт - там нормальный отклик для первого контента от сервера = до 1 сек -и вот 0,2 сек тратится только на обращение к БД .....- да это непозволительно много - он должен быть 0,05сек максимум чтобы уложиться в рамки. ()почему - а обращений может быть еще и много параллельных, нагрузка возрастет скорость будет теряться..... (ну как то так - писать много ленно (там по правильному так - если запрос 0,2 то вероятность паралельных запросов сильно возрастает... И а если сайт на хостинге не один ,, в общем я кратко для чуть понимания ,,, ) )) но ..тем не менее.

как уже сказал с применением у MySQL реляционной структуры вот этот плюс у Mongodb будет полностью утерян..

Автор, это нормально.

Мы используем Mongodb во всех проектах уже 8 лет. Структура хранения Mongodb выносит индексы отдельно в wt файлы, сама структура данные сортирована и разбита по файлам - коллекции.

В новых версиях можно вовсе запустить демона Mongodb и базу развернуть в памяти без возможности писать. Чтение ввиду особенности скорости памяти повышается еще больше.

Если вам нужна какая-то связанная структура, то я бы рекомендовал перенести в PostgreSQL. Если вам нужно читать ключ - значение, то в ту же Mongodb.

Сортировки нет

То что вы описываете ниже по тексту называется шардинг.

Оракл это куча бабла и достаточно специфические полезные функции.

2кк записей и таблица 3.5Гб это совсем не "большие БД".

Вот честно не понимаю, почему хвалят Postgre? Во многих случаях, когда у меня были проблемы с быстродействием, я тестировал Maria, Postgre и Mongo, и всегда быстрее всего оказывались или Maria или Mongo но никогда Postgre.

Нужно ключ-значение, но я пока что сделаю отдельную таблицу id, value в MariaDB и буду держать ее в памяти. Не хочу разбираться как (и умеет ли) Mongo держать таблицы в памяти.

Solmyr,

Если char 32 почему 96? реально нужны ключи в mb-кодировке?..

key_buffer_size что показывает?