Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Ускорят ли запросы с WHERE/ORDER BY/JOIN по проиндексированным колонкам?
Неактивен
Насколько я знаю да.
Естественно есть примая связь с размером таблицы.
Ещё в Memory tables может быть полезным быстрый индекс HASH INDEX
Неактивен
Ну да, если исходить из известных материалов, то рекомендуется использовать hash-индексы, но это только на прямое равенство. В случае >= или <= придется создавать btree-индекс (при этом явно это прописав в создании индекса) и помнить про его больший объем, нежели у hash-индекса.
Неактивен
На самом деле надо смотреть в конкретной ситуации. Если много записей, то безусловно индекс ускорит выполнение запроса, но количественная граница сильно смещена, относительно обычных таблиц. Сейчас посмотрел одну MEMORY-таблицу, которую активно использовал и думал, что на ней есть индексы. Оказалось, что индексов нет и я ничего не заметил при 28 миллионах записей.
Неактивен
rgbeast написал:
На самом деле надо смотреть в конкретной ситуации. Если много записей, то безусловно индекс ускорит выполнение запроса, но количественная граница сильно смещена, относительно обычных таблиц. Сейчас посмотрел одну MEMORY-таблицу, которую активно использовал и думал, что на ней есть индексы. Оказалось, что индексов нет и я ничего не заметил при 28 миллионах записей.
fullscan по 28 миллионам записей ? Это работает быстро ? :-)
Вообще интересно провести эксперимент с сравнением на конкретных примерах. Возможно что разница действительно не будет значительной.
Неактивен
evgeny написал:
fullscan по 28 миллионам записей ? Это работает быстро ? :-)
Вообще интересно провести эксперимент с сравнением на конкретных примерах. Возможно что разница действительно не будет значительной.
Примерно 2 секунды, что меня устраивает для конкретной задачи. Это на порядок быстрее, чем MyISAM с индексами (требуемый запрос в любом случае делает скан части таблицы, но индексы ему помогают). Вспомнил, что индекс не использовал для экономии памяти - сама возможность поместить данные в память важнее, чем индекс.
Неактивен
я ничего не заметил при 28 миллионах записей
Хм..
Этот факт практически равносилен ответу "нет" на вопрос о значимости индексов для MEMORY-таблиц.
Если граница смещена так сильно, то почти не будет случаев, когда верно обратное: 28 миллионов записей в памяти - это уже масштабы in-memory noSQL-хранилищ типа Redis или Tarantool (это я к тому, что там узкими местами другие вещи становятся обычно; хотя опять же зависит от конкретной задачи).
Неактивен
LazY написал:
Этот факт практически равносилен ответу "нет" на вопрос о значимости индексов для MEMORY-таблиц.
Если граница смещена так сильно, то почти не будет случаев, когда верно обратное: 28 миллионов записей в памяти - это уже масштабы in-memory noSQL-хранилищ типа Redis или Tarantool (это я к тому, что там узкими местами другие вещи становятся обычно; хотя опять же зависит от конкретной задачи).
Не совсем так. Все же у меня был запрос изначально медленный (он использовал хранимую функцию в части where) и 2 секунды для него казалось мгновенным. Если запрос прямо по индексу, то, очевидно, индекс поможет и граница не так далеко.
Неактивен
У меня во многих случаях разница ощутимая. А иногда бывает с индексами медленнее, чем без.
Для меня очень важны индексы (именно BTREE) там, где постоянно надо связывать несколько таблиц Memory.
Неактивен
Страниц: 1