|
Задавайте вопросы, мы ответим
Вы не зашли.
Как я слышал, существует некая закономерность, что излишняя индексация таблицы может повредить быстродействию работы СУБД, при большом количестве изменяющих (инсерты, апдейты, дилиты) запросов.
Однако при моих подсчетах, соотнешение чтения/изменение данных из таблицы будет примерно 1/16... Существует ли какая-то математическая формула или закономерность, по котороый можно было бы эффективно вычислить, поможет ли ндексация в этом случае для повышения быстродействия ил итолько усугубит его.
Когда то давно работал с ораклом, местный админ сказал, что это можно проверить только методом научного тыка - тобишь проиндексировать - посмотреть время выполнения запросов. убрать индексацию - и посмотреть время запросов...
Неактивен
Излишняя индексация таблицы, безусловно вредит быстродействию.
Но замедляется лишь скорость обработки данных при добавлении/обновлении/удалении
данных в ключевых полях. Скорость выборки данных, разумеется, не уменьшится.
Конкретной формулы нет, есть некие наводящие соображения:
1. Если весь индекс располагается в памяти - его обработка происходит очень
быстро. Если индекса в памяти нет - вы добавляете лишний disk seek для чтения
страницы индекса в память (и последующего обновления индекса в нем). Если при этом
сервер настроен так, что он каждое изменение индекса записывает на диск, то будет
еще и второй seek на запись.
2. Обновление 1-2 строк обычно не заметно для процессорного времени (можете посмотреть
замечательную Java-демонстрацию того, как работают индексы).
При большом объеме данных требуется больше ресурсов для балансировки индекса
(в том числе и возможные disk seeks на чтение соседних страниц индекса).
3. Составной индекс, как правило, может использоваться для запросов по первому столбцу
этого индекса. Разумное создание индексов может сократить их количество.
4. Обычно, Вы можете себе позволить достаточно большое время на добавление/изменение
данных (ведь пользователь как таковой изменяет обычно не более 1 записи за раз), но выборки
данных должны производиться очень быстро (т.к. нужны группировки, объединения и проч.).
Если Вы сталкиваетесь с таким количеством обновлений таблиц, которые отражаются заметно
на производительности сервера, попробуйте воспользоваться MySQL Cluster.
Неактивен
картинка на ссылке не грузится, но в принципе я понял ход мысли.
спасибо большое.
Неактивен
Картинка java-плагин требует. Очень поучительная вещь, показывает, что сохранять B-tree сбалансированным не так уж сложно, как на первый взгляд может показаться.
Неактивен
