Когда мы много раз выполняем несколько запросов в сложной системе, мы не выбираем подходящий маршрут для достижения оптимальной производительности на уровне базы данных, учитывая текущий технический прогресс и вычислительные мощности, которые мы часто видим на наших серверах, мы можем думать, что оптимизация Базы данных - это вопрос прошлого.
Это не может быть дальше от истины, несмотря на повышение мощности оборудования, базы данных имеют важное значение для производительности приложений, поэтому хорошо написанный и высоко оптимизированный запрос может означать несколько секунд загрузки, что вы экономите на системе, если мы умножим это на число одновременных пользователей, мы увидим, как были потрачены впустую затраты и мощность.
Оптимизировать запросы
Лучший способ улучшить производительность наших баз данных - начать с хорошо написанных запросов, часто мы обнаруживаем, что запросы не очень хорошо написаны, поскольку они не так оптимизированы, как следовало бы, есть много причин для этого, одна из них - это повторное использование без распознавания кода; под этим мы подразумеваем, что если в какой-то момент мы сделали запрос, который работает с левым соединением, мы продолжим его применять, увеличив число таблиц для сверки, при его изменении и изменении некоторых предложений внутренним объединением можно сократить путь и сэкономить потребление процессор.
SQL - это язык, который, хотя он довольно прост для чтения, имеет много аспектов и множество вариаций, которые позволяют нам делать что-то, что работает наилучшим и худшим образом, но это часть наших знаний, чтобы определить, принадлежит ли наше решение к категории или другой.
Чтобы понять, что мы на правильном пути, необходимо обновить одну из самых важных вещей, то есть мы не можем продолжать кодирование на SQL в PostgreSQL, как если бы это была первая версия, когда мы находимся в версии 9 .
Об использовании подзапросов
Это одна из наиболее распространенных ошибок, которые мы совершаем, и это то, что мы рассматриваем запрос как набор частей, которые мы готовим для получения окончательного результата, однако такое поведение сильно влияет на производительность нашей базы данных.
Давайте посмотрим на пример этого типичного поведения:
SELECT tract_id, (SELECT COUNT (*) FROM census.facts как F WHERE F.tract_id = T.tract_id) Как num_facts, (SELECT COUNT (*) FROM census.lu_fact_types как Y WHERE Y.fact_type_id IN (ВЫБРАТЬ fact_type_id FROM census. факты F ГДЕ F.tract_id = T.tract_id)) As num_fact_types FROM census.lu_tracts As T;
Теперь, если мы посмотрим на график EXPLAIN этого запроса, мы поймем, как дорого это сделать таким образом:
Как мы видим, у нас есть несколько точек, которые являются узкими местами в этом запросе, кроме всех данных, которые должны быть перемещены неэффективным образом, для этого мы перепишем их более оптимальным образом и сравним с новым графом EXPLAIN .
ВЫБЕРИТЕ T.tract_id, COUNT (f.fact_type_id) в качестве num_facts, COUNT (DISTINCT fact_type_id) в качестве num_fact_types FROM census.lu_tracts в качестве T LEFT JOIN census.facts в виде F ON T.tract_id = F.tract_id GROUP BY T.tract_id;
В этой новой версии нашего запроса мы избегаем использования подзапросов, вместо этого мы делаем эквивалент с левым соединением и группировкой по, если мы видим график, мы можем увидеть разницу.
Мы можем видеть, как способ получения нашего результата был намного короче, что дает нам более высокую производительность, при этом мы не подразумеваем, что мы должны исключать подзапросы из наших рабочих инструментов, но мы должны знать, что они могут существовать лучшие пути для того, что мы можем рассматривать в данный момент.
- 0
СТАТЬИ