Оптимизация SQL запросов в реляционных СУБД
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
?о меньше предыдущего результата. Это и ожидалось, так как основное время тратилось на пересылку данных с сервера на сервер. Следовательно, для оптимизации данного запроса, необходимо рассмотреть таблицы, из которых этот запрос состоит.
4.3Возможности оптимизации запроса
Рассмотрим структуру таблиц данного запроса. Выборка идёт из 5 таблиц.
Первая таблица - pyr.stations. Она имеет следующую структуру (рисунок 2) :
Рисунок 2 - Структура таблицы pyr.stations
Данная таблица не проиндексирована. Она содержит 119 строк - названия станций. В данной распределённой базе содержится несколько табличных пространств. Стоимость выборки из данной таблицы невелика и составляет величину, равную 2. Но объединение происходит уже с большим количеством строк, что может повлиять на итоговую стоимость выполнения запроса.
Данная таблица относится к табличному пространству Constant_Data. Структура этого табличного пространства представлена на рисунке 3.
Рисунок 3 - Табличное пространство Constant_Data
На этом рисунке место, занимаемое таблицей pyr.stations, обозначено цифрой 1. А полосой выделена его структура. Отсюда видно, что таблица занимает 1 экстент из 8 блоков, т.е. это минимальное количество дискового пространства, отведённого для таблиц в данной базе данных. Поэтому и общий вес в выборке из данной таблицы должен быть невелик. Из плана выполнения представленного запроса (рисунок 1) мы можем это увидеть.
Но тем не менее выборку из этой таблицы можно оптимизировать для данного запроса.
Так как нам из всей таблицы pyr.stations требуется лишь имя станции, то создадим новую таблицу, состоящую из имени станции, идентификатора и поля ST_ETS для связи с другой таблицей, и проиндексируем по идентификатору.
Данную таблицу разместим в табличном пространстве USERS. Теперь выполним запрос с новой таблицей.
select st_name as name_of_station,e_name as name_of_seti,fg_name as name_of_group,f_name as name_of_fider, p_value as znachenie_moshnosti from stationstest,refbus.ets,pyr.fgroups,pyr.fiders,pyr.power where st_id=fg_station and st_ets=e_id and fg_station=f_station and f_id=p_fider and p_value>'40' and p_hhnumber>'119000'
Таблица STATIONSTSEST здесь является новой. Время выполнения уже этого запроса составляет 0.59 секунды, что значительно меньше чем в предыдущий раз. Данный результат можно объяснить только количеством обращений к данной таблице.
Следующая таблица, которую мы будем рассматривать - это таблица refbus.ets. Эта таблица аналогична предыдущей. Она расположена в том же табличном пространстве, содержит 30 записей о сетях, она не проиндексирована. Потому проделаем с ней тоже самое, т.е. создадим новую таблицу, состоящую из двух полей - идентификатора, для связи с другими таблицами, и имени сети, а так же организуем индекс по идентификатору.
Эта таблица так же занимает 1 экстент в табличном пространстве. Перепишем теперь запрос в соответствии с новой таблицей, сохранённой так же в табличном пространстве USERS :
select st_name as name_of_station,e_name as name_of_seti,fg_name as name_of_group,f_name as name_of_fider, p_value as znachenie_moshnosti from stationstest,etstest,pyr.fgroups,pyr.fiders,pyr.power where st_id=fg_station and st_ets=e_id and fg_station=f_station and f_id=p_fider and p_value>'40' and p_hhnumber>'119000'
В результате выполнения данного запроса получаем время выполнения 0.01 секунды. По сравнению с начальным значением - это значительный выигрыш в скорости выполнения.
Таблица pyr.fgroups. Эта таблица занимает уже 5 экстентов, размещённых по табличному пространству Constatnt_Data, т.е. можно сказать что это не оптимально (рисунок 4):
Рисунок 4 -