|
|
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
Добрый день! Приходится писать на форум ибо сам не могу понять куда копать. Словесное описание запроса: Показать все организации (gsorg), которые давали объявления в определенном городе (glcitymy), области (globlmy), и с которыми еще не было переписки (rmailorg). Вот запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. На все нужные поля есть индексы. В тестовой таблице gsorg более 2 млн. записей Вот EXPLAIN: id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE globlmy const PRIMARY PRIMARY 4 const 1 Using index; Using temporary1 SIMPLE glcitymy ref PRIMARYoblId oblId 5 const 27 Using where; Using index1 SIMPLE adverts ref PRIMARYcityIdthemeId cityId 5 smser.glcitymy.id 4358 Using where1 SIMPLE radvorg ref orgIdorgId_2advertId advertId 5 smser.adverts.id 1 Using where1 SIMPLE gsorg eq_ref PRIMARY PRIMARY 4 smser.radvorg.orgId 1 Using index1 SIMPLE rmailorg ref orgIdorgId_2 orgId 5 smser.radvorg.orgId 1 Using where; Distinct В плане explain не силен, поэтому пробовал всякие варианты с увеличением tmp_table_size. Сейчас стоит 256M - вообще никак не влияет. Эксперименты показали что как только подключаешь таблицу связи - "Организации-Объявления" (radvorg) - сразу происходит значительно увеличение времени выполнения. Куда копать? Может какие то системные переменные увеличить? Вроде везде все по индексам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 14:44:10 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
Вот нормальный EXPLAIN (в пред. посте не получилось оформить в виде таблицы) idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLEgloblmyconstPRIMARYPRIMARY4const1Using index; Using temporary1SIMPLEglcitymyrefPRIMARY;oblIdoblId5const27Using where; Using index1SIMPLEadvertsrefPRIMARY;cityId;themeIdcityId5smser.glcitymy.id4358Using where1SIMPLEradvorgreforgId;orgId_2;advertIdadvertId5smser.adverts.id1Using where1SIMPLEgsorgeq_refPRIMARYPRIMARY4smser.radvorg.orgId1Using index1SIMPLErmailorgreforgId;orgId_2orgId5smser.radvorg.orgId1Using where; Distinct ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 14:48:23 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
dundin, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. LIMIT без ORDER BY -- бессмысленен. Перепиши сначала запрос правильно, затем будешь его уже оптимизировать. Также нужны будут DDL-и всех таблиц с индексами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 14:52:52 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 14:55:08 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
MasterZiv, добавление ORDER BY id ASC погоды не сделало - все также долго. Кроме того т.к. это делается для веб-интерфейса, то чтобы показать в виде таблицы с пагинатором - нужен второй запрос который будет считать COUNT - а тут уже ORDER BY бессмысленен. DDL: Организации: gsorg Код: sql 1. 2. 3. 4. 5. 6. Связь организаций и их объявлений (radvorg) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Собственно сами объявления (в тестовой таблице более 7 млн. объявлений): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Справочник городов (glcitymy) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Справочник областей (globlmy) Код: sql 1. 2. 3. 4. 5. 6. Таблица связи "Организации - Письма" (rmailorg) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 15:12:06 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
Пока у меня объяснение только в размерах таблиц. Организаций - 2 млн. Объявлений - 7 млн. Между ними связь, которая тоже не менее 7 млн. Как только все это соединяется - получается шляпа. Пока решение вижу в подключении сфинкса - там фильтрация по атрибутам происходит достаточно быстро. Но сфинкс - это геморр с перестроением индексов. В любом случае - это усложнение всей архитектуры,хотелось бы на уровне SQL решить проблему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 15:25:41 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
dundinСвязь организаций и их объявлений (radvorg)Между конкретной организацией и конкретным объявлением может быть более одной связи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 15:29:54 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
miksoftdundinСвязь организаций и их объявлений (radvorg)Между конкретной организацией и конкретным объявлением может быть более одной связи? Да. Связь "Многие-Ко-Многим". Оно конечно на первый взгляд нелогично - но в определенных случаях одно объявление может относиться к двум-трем разным организациям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 15:35:36 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
dundinmiksoftпропущено... Между конкретной организацией и конкретным объявлением может быть более одной связи? Да. Связь "Многие-Ко-Многим". Оно конечно на первый взгляд нелогично - но в определенных случаях одно объявление может относиться к двум-трем разным организациям.Мне кажется, мой вопрос не понят. Связь "многие-ко-многим" сама по себе не говорит о количестве этих связей в паре организация+объявление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 15:37:35 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
miksoft, да - не понял с первого раза:) Нет - связь между конкретным объявлением и конкретной организацией может быть только одна. Об этом говорит уникальный индекс Код: sql 1. в таблице связи radvorg. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 15:45:17 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
dundinmiksoft, да - не понял с первого раза:) Нет - связь между конкретным объявлением и конкретной организацией может быть только одна. Об этом говорит уникальный индекс Код: sql 1. в таблице связи radvorg.Тогда я бы предложил таблицу radvorg сократить до двух полей, из обоих сделать первичный ключ и из них же в обратном порядке сделать простой индекс. Тогда объем хранимых данных сократится раза в два. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 15:49:57 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
И еще - зачем в запросе используется таблица gsorg, если из нее выбирается только поле id, которое и так получается из других таблиц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 15:51:13 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
miksoft , спасибо за совет, начал пробовать :) О результатах отпишусь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 15:52:17 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
dundinначал пробоватьПро формат дат не забудьте (см. выше), а то еще и неправильный ответ получите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 15:54:03 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
dundinMasterZiv, добавление ORDER BY id ASC погоды не сделало - все также долго. Так добавление ORDER BY либо не изменит, либо замедлит запрос. Но в любом случае запрос будет уже другой. И в таком случае нет смысла обсуждать проблемы этого запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 16:51:06 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Имеем тут 3 SARG-а: -- globlmy.id IN (61) -- adverts.themeId IN (2) AND adverts.date > '2013.11.11' -- rmailorg.orgId IS NULL OR rmailorg.send = 0 Сколько по каждому отфильтровывается записей ( select count(*) from <thetable> where <это условие> сколько даёт ) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 16:54:22 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
Вообщем то обрезать таблицу radvorg до 2 полей не получилось, т.к. там еще разные нужные поля, но убрал поле id, и сделал первичные ключ из orgId и advertId. Не сказать что время выполнения значительно сократилось. Может и помогло - но не намного. По формату даты пока н смотрел - но сейчас это не принципиально - можно это условие вообще убрать - проблема останется. Вот мои некоторые эксперементы: Запрос без сортировки и дистинкта выполняется за вполне приемлемое время 0,5 сек. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Добавление дистинкта увеличивает время на 1 сек. Но время все еще приемлемое - 1,5 сек. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Добавление секции ORDER BY, как справедливо заметил MasterZiv, увеличивает время выполнения еще аж на 4 секунды (суммарно уже 5,5 сек.) - поэтому order by убираем - ибо к самой задаче он не нужен. (задача - показать любые (хоть какие то )организации) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Примерно 4 секунды добавляет Код: sql 1. (условие что с этой организацией переписки еще не было) Ну и еще 5 секунд добавляет COUNT Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Т.е. итого 9 -12 секунд с count. (Напомню что COUNT нужен для пагинатора) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 17:13:38 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
dundin, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: sql 1. 2. 3. Код: sql 1. 2. 3. Что эти запросы возвращают ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2014, 17:19:27 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. возвращает 191360 Код: sql 1. 2. 3. Возвращает 1, и это понятно, ведь globlmy - это справочник областей Код: sql 1. 2. 3. Возвращает 627455 Я так понимаю - что можно попробовать построить индексы по 2 полям? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 10:13:54 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
dundinMasterZiv, Я так понимаю - что можно попробовать построить индексы по 2 полям? Нет. Это означает, что твои SARG-и все плохие, и тебе приходится DISTINCT-ом выжимать из почти 200 тысяч записей твой результат. Т.е. твой запрос неработоспособен в любом случае. Можешь его выкидывать. А если учеть, что ты его ещё и раз 10 примерно собираешься выполнять на один пользовательский экран -- и подавно нужно выкидывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 15:45:47 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
MasterZivНет. Это означает, что твои SARG-и все плохие, и тебе приходится DISTINCT-ом выжимать из почти 200 тысяч записей твой результат. Что имеется в виду под словом "SARG-и"? Гугл не помог. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 21:32:49 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
dundinMasterZivНет. Это означает, что твои SARG-и все плохие, и тебе приходится DISTINCT-ом выжимать из почти 200 тысяч записей твой результат. Что имеется в виду под словом "SARG-и"? Гугл не помог.Если добавить слово Sybase (взятое из профиля MasterZiv), то вполне гуглится, что это понятие похоже на "предикаты выборки". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2014, 22:01:36 |
|
||
|
Помогите оптимизировать запрос. В одной из таблиц записей более 2 млн. Выполнение 30 сек.
|
|||
|---|---|---|---|
|
#18+
dundinMasterZivНет. Это означает, что твои SARG-и все плохие, и тебе приходится DISTINCT-ом выжимать из почти 200 тысяч записей твой результат. Что имеется в виду под словом "SARG-и"? Гугл не помог. SARG = Search ARGument Это выражения фильтрации записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2014, 12:47:48 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38601010&tid=1835034]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
74ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 389ms |

| 0 / 0 |
