|
|
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток форумчане, прошу помощи с оптимизацией вот такого запроса: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Суть запроса: выбираются первые 50 провайдеров из базы user_cards имеющие неограниченное количество типов и специализаций ID которых для каждого провайдера, хранятся в таблицах user_cards_multy_type и user_cards_multy_spec. Сами названия типов и специализаций хранятся в таблицах user_type и user_multi_specialty. Проблема: данный запрос выполняется более 10 секунд (( explain запроса: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Вывод show create table user_cards: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. Вывод: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Вывод:show create table user_cards_multy_type; Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Вывод: show create table user_type; Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Ну и вывод:show create table user_multi_specialty; Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 10:42:20 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Что-то оптимизатор не догоняет... статистику обновить не пробовали? Если пробовали и не помогло, то предлагаю переписать запрос, заменив "provider" на непосредственно выбранные 50 записей из таблицы user_cards (т.е. на подзапрос). ЗЫ. MyISAM? А зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 10:53:44 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
necoro, Плохой стиль смешивать обычные JOIN-ы и перечисление таблиц через запятую в секции FROM, т.к. эти операции имеют разный приоритет и даже результат иногда может оказаться неожиданным. Попробуйте запятые заменить на JOIN-ы или LEFT JOIN (в зависимости от логики таблиц), а вместо provider сделать подзапрос, как советует tanglir. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 11:03:32 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Запутался я .. Сделал такой запрос Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Все бы хорошо, но теперь возвращается только 1 запись .. Вот его explain Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 11:59:54 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Для начала можно попробовать запрос без SQL_CALC_FOUND_ROWS, тем более что с выборкой 50 провайдеров в подзапросе его использование вообще теряет смысл. Уверены ли в корректности выборки столбцов без агрегатных функций в вашем случае? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 12:01:30 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
necoro, Если я ничего не напутал, то примерно так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 12:11:49 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
to miksoft. Без GROUP MySQL дублирует каждую строку по количеству вхождений в user_cards_multy_type,user_multi_specialty. Более/менее рабочий вариант получается таким: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Его explain: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 12:33:13 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
necoro, Нет, это явно не рабочий вариант. Я упустил тот момент, что user_cards.code не является первичным ключом, как я думал. И группировка, и агрегатные функции должны быть в подзапросе. Но тут нужно определиться - из какой именно записи нужно брать значения для остальных полей таблицы user_cards в пределах группы по user_cards.code ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 12:37:51 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
necoro, в подзапросе потеряли ORDER BY user_cards.code DESC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 12:41:10 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
miksoftnecoro, Нет, это явно не рабочий вариант. Я упустил тот момент, что user_cards.code не является первичным ключом, как я думал. И группировка, и агрегатные функции должны быть в подзапросе. Но тут нужно определиться - из какой именно записи нужно брать значения для остальных полей таблицы user_cards в пределах группы по user_cards.code ? `code` int(6) NOT NULL, UNIQUE KEY `code` (`code`), так что в подзапросе группировка не нужна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 12:43:41 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
retvizan `code` int(6) NOT NULL, UNIQUE KEY `code` (`code`), так что в подзапросе группировка не нужна.Хм, действительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 12:47:57 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
retvizannecoro, в подзапросе потеряли ORDER BY user_cards.code DESCА итоговый ORDER BY лишний. С этими поправками вроде должно получиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 12:51:11 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Работает только в таком варианте: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. explain: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 12:59:40 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
necoroРаботает только в таком варианте:Теперь LIMIT потерялся :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 13:02:48 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
А SQL_CALC_FOUND_ROWS нашелся :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 13:07:16 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
miksoft, ОоО, я даже не заметил на глаз разницы в скорости обработки запроса что для 50-записей что для всей таблицы )) Итоговый вариант Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Просто летает, спасибо всем ) P.S. возник вопрос а как теперь добавлять строку с фильтрами хоть по странам/городам, хоть по специализациям .. )) Первоначально на PHP все выглядело вот так: Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. До этого соответственно заполнялась строка $whereClause. Если в новый запрос вставить в конце and 1 $whereClause то логично предположить выборка пойдет только из первых 50 строк... Тогда получается надо добавлять эту строку в подзапрос, он не поймет ничего про страны/города да и прочее не находящееся в user_cards .. ОМГ )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 13:31:08 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
necoroвозник вопрос а как теперь добавлять строку с фильтрами хоть по странам/городам, хоть по специализациям .. ))ЕМНИП кто-то с этого форума...А вообще, я очень хочу, чтобы наша профессия со временем стала такой же инженерной дисциплиной, как, например, строительство - вам нужно здание? Извольте заплатить за проект, а потом за возведение, или покупайте (арендуйте) готовое, но тут уж не выдвигайте требований пристроить к нему еще 30 этажей. Изволили построить времянку, а теперь хотите ее превратить в доменный цех? нет проблем - СНОСИМ временку и строим цех. Через пять лет вам потребуется переделать цех в аэропорт? Это ваши трудности - х*й в голове медицина бессильна. Вы никогда не задумывались почему в IT такой процент проваленных проектов (представьте себе такой процент например в автомобилестроениии)? А потому, что делают их не в рамках инженерного подхода, а вопреки ему.... И заметьте, никто не кричит "Судостроители пи...сы не хотят переделать речной трамвайчик в ледокол". Ээээх мечты... Фильтры-то к чему применяются? Если к базовой таблице, так и перенесите их в подзапрос. А если нет, см.выше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 13:42:10 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38921129&tid=1833363]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 335ms |

| 0 / 0 |
