|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
07.08.2018, 11:29 | #1 |
Форумчанин
Регистрация: 07.06.2015
Сообщений: 164
|
SQL запросы стали тормозить
Использую СУБД Postgresql, относительно не так давно, SQL запросы стали выполняться намного дольше по времени. Некоторые запросы выполняются в несколько десятков раз дольше.
Провел анализ работы БД (сравнил с данными месячной давности), проблем с памятью или процами нет. Но заметил что время доступа к разделу с БД различается на порядок, что можно с эти сделать, кроме банального VACUUM FULL ANALYZE? |
07.08.2018, 18:27 | #2 |
Форумчанин
Регистрация: 07.06.2015
Сообщений: 164
|
В запросе стал использоваться другой индекс, правильно ли я понимаю, после
VACUUM FULL ANALYZE должна обновиться статистика, которую использует планировщик для выбора оптимального способа выполнения запроса, также должен помочь REINDEX? Есть ли еще способ кроме VACUUM FULL ANALYZE поставить "на путь истинный" планировщик? |
08.08.2018, 20:08 | #3 |
Форумчанин
Регистрация: 07.06.2015
Сообщений: 164
|
К сожалению VACUUM и REINDEX не помогли.
Как работает планировщик POSTGRES, для меня загадка. Есть такая же БД(тестовая, с аналогичным набором данных) на другом сервере, в аналогичных запросах, там используется нужный индекс, который раньше использовался на проблемной базе. Приведу элементарный запрос и планы выполнения Код:
Код:
С аналогичной БД на другом сервере Код:
Как-то оптимизировать запрос нельзя, куда уж проще. У меня осталась последняя мысль, удалить Index1, но будет ли во всех местах, где действительно нужен Index1, использоваться Index2 и не будет ли он тормозить эти запросы? Буду рад любым конструктивным идеям |
11.08.2018, 22:51 | #4 |
Форумчанин
Регистрация: 07.06.2015
Сообщений: 164
|
Как можно скрыть оп планировщика поле Field2, чтобы использовался индекс по Fileld3. В запросе
Код:
В поле Field2 в нижнем регистре тип данных text Вариант 1: Код:
Вариант 2: Код:
|
13.08.2018, 19:55 | #5 |
Форумчанин
Регистрация: 07.06.2015
Сообщений: 164
|
помогли следующие волшебные команды
ALTER TABLE "Table1" ALTER COLUMN "Field2" SET STATISTICS 10000; VACUUM ANALYZE "Table1"; |
16.08.2018, 16:28 | #6 |
Форумчанин
Регистрация: 17.03.2009
Сообщений: 977
|
та же фигня в mysql есть. короче большие базы пишутся на ндд кусочками (на момент добавления строк), надо тупо их оптимизировать или просто копировать с одного места на другое (тогда сектора диска будут подряд, что критично на базах от 1млн записей и дисках hdd). в данном запросе вся база переписалась на новое место. что ускорило доступ.
Интуитивно понятный интерфейс - это такой интерфейс, для работы с которым нужна недюжинная интуиция.
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
запросы 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 |