|
|
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
Суть, есть вектор строковых значений, длинна вектора динамическая, строковые значения ограниченны длинной 255 символов. Для расчетов нужно получить численные представления этих строковых значений(грубо говоря построить все уникальные в ряд и пронумеровать). После этого нужно сделать выборку всех векторов по условию при этом заменив строковые данные - численными. C переназначением проблем нет. А вот с выборкой проблема. Выборку делает вот такой сгенерированный запрос (на примере вектора из 4х параметров): Код: plsql 1. 2. 3. 4. 5. 6. данный запрос при 15 тысячах данных (1400 уникальных элементов в remap и 15тысяч всего данных в collect) вешает MySql намертво ( 20-25секунд запрос идет), PostreSql на той же машине выдает 615 мсек что приемлемо. Вопросы: 1. Можно ли оптимизировать данный запрос под mysql? 2. Какие есть еще варианты решения подобной задачи? 3. Какие в этом случае стоит использовать индексы? 4. Можно ли в явном виде сделать join с пересечением по всем 4м параметрам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 18:27:56 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
Покажите план запроса и DDL обоих таблиц с индексами. Подзапрос за какое время выполняется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 18:34:41 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
1 PRIMARY rm0 ref PRIMARY PRIMARY 54 const,const 4 Using where 1 PRIMARY rm1 ref PRIMARY PRIMARY 54 const,const 4 Using where 1 PRIMARY rm3 ref PRIMARY PRIMARY 54 const,const 8 Using where 1 PRIMARY rm2 ref PRIMARY PRIMARY 54 const,const 395 Using where 1 PRIMARY <derived2> ALL NULL NULL NULL NULL 1498 Using where; Using join buffer 2 DERIVED collect ALL NULL NULL NULL NULL 16442 Using where; Using temporary; Using filesort Подзапрос выгребает за 0.0011 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. вектор условно ограничен длинной 10(по колонкам oN), в дальнейшем может быть увеличен. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Групп может быть сразу много, соотв ключи для ремапа делались из расчета того что в одной группе все o_n названия уникальные и соотв их числовые эквиваленты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 18:56:45 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
При практически полном отсутствии индексов не удивительно, что запрос тормозит. Для начала попробуйте remap (group_id, o_n, name) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 21:06:04 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
авторПодзапрос выгребает за 0.0011 подзапросы выполняются на каждую строку. надо переводить на джойн/времянку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 22:19:26 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
Первая серьезная выявленная проблема, если поменять INNER JOIN на LEFT JOIN, а потом выбросить все где есть NULL то время запроса сокращается с 25 до 4 секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 23:22:12 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
план покажи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 23:37:47 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
ScareCrowавторПодзапрос выгребает за 0.0011 подзапросы выполняются на каждую строку. надо переводить на джойн/времянку.Там уже JOIN. Только он выполняется не в том направлении. Индексов практически нет, поэтому оптимизатору сложно угадать правильное направление. undiablerПервая серьезная выявленная проблема, если поменять INNER JOIN на LEFT JOIN, а потом выбросить все где есть NULL то время запроса сокращается с 25 до 4 секунд.Это не "проблема". Это вы методом "молотком по пальцам" заставили оптимизатор выполнять JOIN в правильном направлении. Но лучше создать нормальные индексы. Вариант я уже предлагал. ScareCrowплан покажиВот же - 17246330 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2015, 00:53:58 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
miksoft, Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2015, 01:47:45 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
ScareCrowmiksoft, Код: sql 1. И толку от него? Из всех полей этой таблицы, участвующих в запросе, насколько я понимаю, самое селективное поле это name, а оно в этот индекс не входит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2015, 02:07:37 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
Да, индексы помогли, стало по 1.2-1.8 секунды отрабатывать. Метод "молотка по пальцам" в принципе уместен т.как логика работы не страдает. А влияет ли размер таблицы на такую вот перекрестную выборку? В том плане что если я напишу генератор который будет отдельно создавать динамические таблицы под каждую колонку и хранить в них данные, это в теории повысит скорость работы или нет? Т.е Код: plsql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2015, 17:12:21 |
|
||
|
Оптимизация запроса (MySql vs PostgreSql)
|
|||
|---|---|---|---|
|
#18+
undiablerДа, индексы помогли, стало по 1.2-1.8 секунды отрабатывать.Покажите новый план. Возможно, можно еще что-то улучшить. undiablerМетод "молотка по пальцам" в принципе уместен т.как логика работы не страдает.Все равно он менее эффективен, чем правильные индексы. Хотя иногда имеет право на жизнь в случае ограниченных ресурсов и/или при отсутствии требований по времени выполнения запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2015, 17:29:43 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38876291&tid=1833585]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
45ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 194ms |
| total: | 317ms |

| 0 / 0 |
