Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

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

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

Купить рекламу на форуме - 42 тыс руб за месяц

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

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

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

К сожалению 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, 22:51   #4
polin11
Форумчанин
 
Регистрация: 07.06.2015
Сообщений: 164
По умолчанию

Как можно скрыть оп планировщика поле 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, 19:55   #5
polin11
Форумчанин
 
Регистрация: 07.06.2015
Сообщений: 164
По умолчанию

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

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

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


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
запросы 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 12:01
SQL запросы akimov_aleks БД в Delphi 3 21.04.2010 05:42