Сократить время ответа на запрос, необходимо оптимизировать запрос - PullRequest
0 голосов
/ 19 сентября 2018

Я написал запрос, который выбирает запись NULL DAYS (Occasion, weekoff, чрезвычайные выходные), позже я реализовал то же самое в графическом интерфейсе, так что мой администратор может видеть список, загрузка данных займет несколько минут,даже в моем SQL-разработчике.

Как сократить время выполнения?

Вот запрос

SELECT *
FROM
  (SELECT s.null_id ,
    STRING_AGG(DISTINCT s.city) city_id ,
    STRING_AGG(DISTINCT c.name) cityName ,
    STRING_AGG(DISTINCT s.location) location_id ,
    STRING_AGG(DISTINCT l.name) locationName ,
    STRING_AGG(DISTINCT s.sublocation) sublocation_id ,
    STRING_AGG(DISTINCT sl.name) sublocationName ,
    s.department ,
    s.fromtodate ,
    s.todate ,
    s.remark ,
    s.status ,
    s.update_date ,
    s.update_by ,
    s.delete_status ,
    s.update_by_name ,
    uu.name updatedBy ,
    row_number() OVER(ORDER BY s.null_id) rnum
  FROM nullday s
  LEFT OUTER JOIN userdetail uu
  ON s.update_by = uu.user_id
  LEFT OUTER JOIN city c
  ON ','
    || s.city
    || ',' LIKE '%,'
    ||c.CITY_ID
    ||',%'
  LEFT OUTER JOIN location l
  ON ','
    || s.location
    || ',' LIKE '%,'
    ||l.LOCATION_ID
    ||',%'
  LEFT OUTER JOIN sublocation sl
  ON ','
    || s.sublocation
    || ',' LIKE '%,'
    ||sl.SUBLOCATION_ID
    ||',%'
  WHERE s.null_id = s.null_id
  GROUP BY s.null_id,
    s.location,
    s.sublocation,
    s.department,
    s.fromtodate,
    s.todate,
    s.remark ,
    s.status,
    s.update_date,
    s.update_by,
    s.delete_status,
    s.update_by_name,
    uu.name
  ORDER BY s.fromtodate ASC
  ) mytbl
WHERE rnum < :max_val
AND rnum   > :min_val

Я не могу понять, является ли joins или LISTAGG занимает время для загрузки запроса.

NULLDAY Формат данных таблицы

enter image description here

1 Ответ

0 голосов
/ 19 сентября 2018

Одна из существенных проблем, связанных с объединением таблиц в выражениях, а не в реальных столбцах.Это исключает использование индекса, который потенциально может ускорить процесс.

LEFT OUTER JOIN city c
  ON ','
    || s.city
    || ',' LIKE '%,'
    ||c.CITY_ID
    ||',%'

Возможным решением может быть создание временной (или вспомогательной) таблицы, в которой вы создаете отдельные строки, используя список через запятуюи оригинальный первичный ключ.Вы можете использовать это, чтобы получить первичный ключ быстрее.

Общий подход может быть следующим:

  • Можем ли мы разбить длинные запросы на более мелкие куски?
  • Можем ли мы использовать временные таблицы вместо выражений объединения?
  • Можем ли мы спроектировать временные таблицы для замены LEFT JOIN на INNER JOINs?
  • Можем ли мы уменьшить количество DISTINCT?
  • Можем ли мы удалить ORDER BY?
  • Можем ли мы удалить (или переработать, используя временные таблицы) row_number () OVER (ORDER BY s.null_id) ?
  • Можем ли мы перепроектировать базу данных, чтобы сохранить данные, как это должно быть в реляционной базе данных?(Надлежащие столбцы и записи можно использовать в индексе, а строки, разделенные запятыми, нельзя.)

Больше ничего я бы не предложил, не зная более подробной информации.Надеюсь, это поможет.

Редактирование на основе загруженных данных

Вы должны извлечь списки, разделенные запятыми, и создать правильные отношения один ко многим.Используйте постоянные таблицы, если вам разрешено изменять структуру базы данных, в противном случае используйте временные таблицы при переработке запроса.

...