Форум программистов
 
Контакты: о проблемах с регистрацией, почтой и по другим вопросам пишите сюда - alarforum@yandex.ru, проверяйте папку спам! Обязательно пройдите активизацию e-mail.

Вернуться   Форум программистов > Web > SQL, базы данных
Регистрация

Восстановить пароль
Повторная активизация e-mail

Ответ
 
Опции темы
Старый 07.08.2018, 12:29   #1
polin11
Форумчанин
 
Регистрация: 07.06.2015
Сообщений: 96
Репутация: -53
По умолчанию SQL запросы стали тормозить

Использую СУБД Postgresql, относительно не так давно, SQL запросы стали выполняться намного дольше по времени. Некоторые запросы выполняются в несколько десятков раз дольше.
Провел анализ работы БД (сравнил с данными месячной давности), проблем с памятью или процами нет. Но заметил что время доступа к разделу с БД различается на порядок, что можно с эти сделать,
кроме банального VACUUM FULL ANALYZE?
polin11 вне форума   Ответить с цитированием
Старый 07.08.2018, 19:27   #2
polin11
Форумчанин
 
Регистрация: 07.06.2015
Сообщений: 96
Репутация: -53
По умолчанию

В запросе стал использоваться другой индекс, правильно ли я понимаю, после
VACUUM FULL ANALYZE должна обновиться статистика, которую использует планировщик для выбора оптимального
способа выполнения запроса, также должен помочь REINDEX?
Есть ли еще способ кроме VACUUM FULL ANALYZE поставить "на путь истинный" планировщик?
polin11 вне форума   Ответить с цитированием
Старый 08.08.2018, 21:08   #3
polin11
Форумчанин
 
Регистрация: 07.06.2015
Сообщений: 96
Репутация: -53
По умолчанию

К сожалению VACUUM и REINDEX не помогли.
Как работает планировщик POSTGRES, для меня загадка.
Есть такая же БД(тестовая, с аналогичным набором данных) на другом сервере, в аналогичных запросах,
там используется нужный индекс, который раньше использовался на проблемной базе.
Приведу элементарный запрос и планы выполнения

Код:

SELECT Filed1
FROM Table1
WHERE Field2 like '01%' AND Field3 = 123

План запроса на проблемной БД:

Код:

"Unique  (cost=0.43..6.21 rows=1 width=8) (actual time=1.323..11.502 rows=184 loops=1)"
"  Buffers: shared hit=4806 read=416"
"  ->  Index Scan using "Index1" on "Table1"  (cost=0.43..6.20 rows=1 width=8) (actual time=1.320..11.473 rows=184 loops=1)"
"        Index Cond: ("Filed3" = 123)"
"        Filter: ("Field2" ~~ '01%'::text)"
"        Rows Removed by Filter: 37833"
"        Buffers: shared hit=4806 read=416"
"Planning time: 26.205 ms"
"Execution time: 11.571 ms"

Используется Index1 по полю Field2 с классом оператора varchar_pattern_ops, запрос выполнялся 25 секунд


С аналогичной БД на другом сервере

Код:

"Index Scan using "Index2" on "Table1"  (cost=0.69..8.71 rows=1 width=8) (actual time=0.052..0.426 rows=184 loops=1)"
"  Index Cond: (("Filed3" = 123) AND ("Field2" ~>=~ '01'::text) AND ("Field2" ~<~ '02'::text))"
"  Filter: ("Filed2" ~~ '01%'::text)"
"  Buffers: shared hit=189"
"Planning time: 0.558 ms"
"Execution time: 0.546 ms"

Используется Index2 по полям (Field2 с классом оператора varchar_pattern_ops, Field3), запрос выполнялся 50 миллисекунд

Как-то оптимизировать запрос нельзя, куда уж проще. У меня осталась последняя мысль, удалить Index1,
но будет ли во всех местах, где действительно нужен Index1, использоваться Index2 и не будет ли он тормозить эти запросы?
Буду рад любым конструктивным идеям
polin11 вне форума   Ответить с цитированием
Старый 11.08.2018, 23:51   #4
polin11
Форумчанин
 
Регистрация: 07.06.2015
Сообщений: 96
Репутация: -53
По умолчанию

Как можно скрыть оп планировщика поле Field2, чтобы использовался индекс по Fileld3. В запросе
Код:

SELECT Filed1
FROM Table1
WHERE Field2 like '01%' AND Fileld3 = 123


В поле Field2 в нижнем регистре тип данных text
Вариант 1:
Код:

SELECT Filed1
FROM Table1
WHERE LOWER(Field2) like '01%' AND Fileld3 = 123


Вариант 2:
Код:

SELECT Filed1
FROM Table1
WHERE  (Field2 like '01%')::integer=1 AND Fileld3 = 123

Может есть варианты более оптимальные?
polin11 вне форума   Ответить с цитированием
Старый 13.08.2018, 20:55   #5
polin11
Форумчанин
 
Регистрация: 07.06.2015
Сообщений: 96
Репутация: -53
По умолчанию

помогли следующие волшебные команды

ALTER TABLE "Table1" ALTER COLUMN "Field2" SET STATISTICS 10000;
VACUUM ANALYZE "Table1";
polin11 вне форума   Ответить с цитированием
Старый 16.08.2018, 17:28   #6
IliaIT
Участник клуба
 
Аватар для IliaIT
 
Регистрация: 17.03.2009
Сообщений: 952
Репутация: 508
По умолчанию

та же фигня в mysql есть. короче большие базы пишутся на ндд кусочками (на момент добавления строк), надо тупо их оптимизировать или просто копировать с одного места на другое (тогда сектора диска будут подряд, что критично на базах от 1млн записей и дисках hdd). в данном запросе вся база переписалась на новое место. что ускорило доступ.
__________________
Интуитивно понятный интерфейс - это такой интерфейс, для работы с которым нужна недюжинная интуиция.
IliaIT вне форума   Ответить с цитированием
Ответ

Опции темы

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
запросы sql synthex Помощь студентам 2 15.07.2013 12:55
SQL запросы marusua SQL, базы данных 2 16.01.2013 01:22
sql запросы neomax38 БД в Delphi 0 13.12.2011 15:00
БД и SQL запросы kuzmich БД в Delphi 1 15.11.2010 13:01
SQL запросы akimov_aleks БД в Delphi 3 21.04.2010 05:42


09:29.


Powered by vBulletin® Version 3.8.8 Beta 2
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.

RusProfile.ru


Справочник российских юридических лиц и организаций.
Проекты отопления, пеллетные котлы, бойлеры, радиаторы
интернет магазин respective.ru