|
|
|
Прошу совета по оптимизации выборки из трех огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Господа, подскажите, плиз, с такими большими таблицами мне работать еще не приходилось (>300000-400000) Пишу такой запрос для выборки из трех таблиц: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Код: plaintext 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. Classifier - каталог групп товара, 17000 записей Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ClassWares - таблица принадлежности товара к группе классификатора Код: plaintext 1. 2. 3. 4. 5. Цель моего запроса - сделать выборку значений по товарам из раздела классификатора, включая дочерние элементы каталога. Такой запрос жутко тормозит. Explain показывает, что из первой таблицы берется огромная выборка, т.к. (w.WareTypeId = '50') - это почти все записи (320тыс.). Может быть, стоит посмотреть в сторону InnoDB-таблиц?:) или вообще PostgreSQL? Или озадачится прикрутить к MS SQL базе, с которой я собственно и импортирую данные в MySQL? Спасибо за советы:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2005, 19:56:42 |
|
||
|
Прошу совета по оптимизации выборки из трех огромных таблиц
|
|||
|---|---|---|---|
|
#18+
InnoDB может быть быстрее в случае постоянных апдейтов таблиц, при выборке особой скорости появиться неоткуда... Собственно, основная причина тормозов в том, что в результате объединения вы получаете 320 тысяч записей, и начинаете их сортировать без использования индекса, чтобы извлечь первые 5. Рекомендую построить индекс по WareName, должно сделать запрос не столь мучительно долгим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2005, 02:17:38 |
|
||
|
Прошу совета по оптимизации выборки из трех огромных таблиц
|
|||
|---|---|---|---|
|
#18+
DocAlInnoDB может быть быстрее в случае постоянных апдейтов таблиц, при выборке особой скорости появиться неоткуда... Да? А мне казалось, как раз наоборот, нет? DocAlСобственно, основная причина тормозов в том, что в результате объединения вы получаете 320 тысяч записей, и начинаете их сортировать без использования индекса, чтобы извлечь первые 5. Рекомендую построить индекс по WareName, должно сделать запрос не столь мучительно долгим. Это понятно, индекс такой есть, непонятно только, как им пользоваться в моем случае - ведь объединение мне нужно по элементам классификатора, а не по товару. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2005, 18:05:04 |
|
||
|
Прошу совета по оптимизации выборки из трех огромных таблиц
|
|||
|---|---|---|---|
|
#18+
DocAlСобственно, основная причина тормозов в том, что в результате объединения вы получаете 320 тысяч записей, и начинаете их сортировать без использования индекса, чтобы извлечь первые 5.А вот что говорится в документации : MySQL ABЕсли LIMIT # используется с ORDER BY, MySQL закончит сортировку, как только найдет первые # строк, вместо того, чтобы сортировать всю таблицу.Так что мнение DocAl не является 100% причиной тормозов, хотя и содержит рациональное зерно... Моё предложение будет таким: первым должен обрабатываться "классификатор" (думаю в нем не так много записей с ParentID = '2', хотя возможно это не так), а дальше уже соединяем результат с товарами через ClassWares. Выглядеть все это будет примерно так (к сожалению не могу проверить, поэтому результат не гарантирован ;-) ): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. и то что предикат cl.ParentID = '2' выполняется одним из первых, лучше бы самым первым. Да и индекс по этому полю не помешал бы ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 02:44:52 |
|
||
|
Прошу совета по оптимизации выборки из трех огромных таблиц
|
|||
|---|---|---|---|
|
#18+
vick_ivanov DocAlInnoDB может быть быстрее в случае постоянных апдейтов таблиц, при выборке особой скорости появиться неоткуда... Да? А мне казалось, как раз наоборот, нет? Вам казалось. vick_ivanov DocAlСобственно, основная причина тормозов в том, что в результате объединения вы получаете 320 тысяч записей, и начинаете их сортировать без использования индекса, чтобы извлечь первые 5. Рекомендую построить индекс по WareName, должно сделать запрос не столь мучительно долгим. Это понятно, индекс такой есть, непонятно только, как им пользоваться в моем случае - ведь объединение мне нужно по элементам классификатора, а не по товару. [/quot] В описании таблиц такого индекса нет. Полнотекстовый индекс для сортировки неприменим. (Кстати, реализован он только для MyISAM, так что если он используется -- переход на другой движок таблиц будет проблематичен.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 04:26:20 |
|
||
|
Прошу совета по оптимизации выборки из трех огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Запрос афтара вопроса естественно отрабатывается так как описано, потому что inner join так и действует. Во-первых не хватает индекса обычного на WareName, во вторых, почему обязательно связывать таблицы внутренним объединением ??? Может я не совсем понял задачу, но по моему можно связать обычным join. Согласен с DocAl, InnoDB не решит проблему, на больших таблицах этот движок работает чуть медленее. Переходить на PostgreSQL или на MS SQL не стоит, они работают медленее, но если вы не верите, закачайте туда и напишите запросы... Покрутить еще раз запросы и задачу, перейти на 5.0 версию MySQL, в ней есть соединение индексов index_merge, что тоже ускорит отбор тяжелой таблицы.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 10:57:40 |
|
||
|
Прошу совета по оптимизации выборки из трех огромных таблиц
|
|||
|---|---|---|---|
|
#18+
Сортировка по полю типа text? Рекомендую перейти на пятый мускуль, там поле varchar можно делать длиной до 64кб (255 символов точно не хватает?). Значения типа text и blob ведут себя вроде как файлы. ------------------ - А как в Интеpнете pаботать? - Сначала нужно узнать, что вам нужно rtfm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 11:22:05 |
|
||
|
|

start [/forum/topic.php?fid=47&tid=1853372]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
319ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 227ms |
| total: | 653ms |

| 0 / 0 |
