|
|
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Добрый день. Уже сломал всю голову. Есть таблица, которая занимает примерно 3 млн. записей. К этой таблице, и ряду других применяется такой запрос. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Сервер - 4 ядра i5, 32 Gb оперативки, все кеши на виртуальных дисках в памяти размером 2 Гб, аппаратный RAID. Explain показывает вроде бы неплохую ситуацию Код: plaintext 1. 2. 3. Среднее время выполнения - 4-5 секунд. Меньше ни как. Помогите, плз, в чем может быть проблема? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2013, 21:32:58 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
3 млн. записей - это таблица transaction_by_date. Остальные таблицы - в пределах нескольких десятков тысяч строк ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2013, 21:35:19 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
В результат идут данные данные только из одной таблицы, это так и надо? Таблицу `transactions_by_date` вы соединяете через LEFT JOIN, но тут же в секции WHERE фильтруете по ней, что автоматически превращает LEFT JOIN в просто JOIN. Нужно ли убрать слово LEFT, либо убрать условия фильтрации, либо (наиболее вероятно) перенести их в условия соединения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2013, 22:13:42 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Проблема похоже в вот этом. Код: plsql 1. Этот запрос сам по себе выполняется за 4.10 секунды. При этом EXPLAIN пишет | 1 | SIMPLE | transactions_by_date | index_merge | is_excluded,not_qualified,is_system,user_id | user_id,is_excluded,not_qualified,is_system | 4,5,5,5 | NULL | 8542 | Using intersect(user_id,is_excluded,not_qualified,is_system); Using where | Это как раз та таблица, которая занимает примерно 3 млн. строк. Что в ней может быть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2013, 22:38:34 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
А иногда (редко) данный запрос выдает нормальное время в 0,17 сек. А не может быть это связано с тем, что в эту базу пишутся новые записи с частотой, скажем, 2 записи в секунду? Может быть при вставке новой записи индексы пересчитываются, и в это время не работают? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2013, 22:46:35 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Нехватает индекса по полям, что во where... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2013, 22:48:28 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2013, 22:49:30 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Уже делал - правда по всем, кроме user_id. Не помогает. Но вот что сейчас помогло Код: plsql 1. 2. 3. 0,23 сек Теперь пытаюсь в большой запрос это вставить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2013, 22:59:57 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
AkinaНехватает индекса по полям, что во where...Не факт. Возможно, нужен индекс на поля для соединения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2013, 23:00:44 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Еще интереснее. Вот такой запрос: Код: plsql 1. 2. 3. 4. 5. 6. 7. Он то выполняется 12 секунд, то 0,17. Закономерность такая. Когда 12 секунд, то EXPLAIN такой. 1 PRIMARY <derived2> ALL 254 2 DERIVED td ref transactionId,is_excluded,not_qualified,is_system is_excluded 5 3170975 Using where 2 DERIVED us ref user_id,transaction_id transaction_id 4 savedplus.td.transactionId 1 Using where А если 0,17, то EXPLAIN такой. 1 PRIMARY <derived2> ALL 254 2 DERIVED us ref user_id,transaction_id user_id 4 1230 Using where 2 DERIVED td ref transactionId,is_excluded,not_qualified,is_system transactionId 4 savedplus.us.transaction_id 44 Using where Уже понятнее. Почему-то иногда планировщик выбирает вариант, при котором он просматривает 3 млн. записей. И это занимает 12 секунд. А как можно зафискирвоать вторую схему планирования навсегда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2013, 00:31:28 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Варианты: 1) удалить индекс is_excluded и другие индексы с низкой селективностью (если они не нужны для чего-то другого). 2) выполнить ANALYZE TABLE для обоих таблиц. План попытаться закрепить можно через принудительною использование нужных индексов, см. Index Hint Syntax . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2013, 00:42:19 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Хм. на первый взгляд сработал вариант 1. Сейчас буду тестировать. Исключить ненужные ключи уже в скрипте можно будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2013, 00:49:25 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
miksoftВарианты: 1) удалить индекс is_excluded и другие индексы с низкой селективностью (если они не нужны для чего-то другого). В общем... спасибо огромное! Вот это сработало. Хотя в целом непонимание так и осталось. Похоже, что очень медленно работает index_merge. Все проводки с ними выполняются очень долго. Как только я "ломал разными методами" планировщик запросов, и не видел в EXPLAIN index_merge - все становилось нормально. Например, по части запросов удавалось поднять производительность в десятки и сотни раз (в обще сложности вчера скорректировал 5 запросов) путем замены "is_excluded=0" на "is_excluded != 1". И это при том, что is_excluded, естественно, сам по себе является индексом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2013, 10:26:18 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Stan_1, мусклевский сборщик статистики - вещь такая, как бы сказать... в общем, он может ошибаться. А из кривой статистики вырастают кривые планы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2013, 11:00:19 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
tanglirStan_1, мусклевский сборщик статистики - вещь такая, как бы сказать... в общем, он может ошибаться. А из кривой статистики вырастают кривые планы... А я ей и не пользуюсь. :) У меня скрипт, который пишет время вызова программных методов. Вот например, было im->getUserSA executed at 0.006242036819458 sec (load 2 accounts) im->getUserCC executed at 0.020219087600708 sec (load 10 accounts) Load user at 4.27365647382921 sec Load all transactions at 1.1266248512268 sec Load dates of use application at 0.00624680519104 sec Стало im->getUserSA executed at 0.0063648223876953 sec (load 2 accounts) im->getUserCC executed at 0.019848108291626 sec (load 10 accounts) Load user at 0.016113042831421 sec Load all transactions at 0.16445207595825 sec Load dates of use application at 0.0062861442565918 sec ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2013, 11:03:59 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Stan_1А я ей и не пользуюсь. :)Речь о статистике по имеющимся данным, которую мускль собирает самостоятельно и которая учитывается при оценке количества получаемых записей и, соответственно, при определении используемых при выполнении запросов индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2013, 11:19:16 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
Stan_1, Попробуй для начала убрать подзапрос во from, потом - лишние колонки и таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2013, 11:32:27 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
MasterZiv, И distinct ещё, безусловно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2013, 11:40:20 |
|
||
|
Почему медленно работает запрос?
|
|||
|---|---|---|---|
|
#18+
tanglirStan_1А я ей и не пользуюсь. :)Речь о статистике по имеющимся данным, которую мускль собирает самостоятельно и которая учитывается при оценке количества получаемых записей и, соответственно, при определении используемых при выполнении запросов индексов. Сорри, ступил. :( Теперь понял ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2013, 11:42:57 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38441949&tid=1835828]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
30ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 319ms |

| 0 / 0 |
