Оптимизация запроса, в котором выборка всего из одной таблицы по полю, на котором итак был индекс! Разбираемся почему индекс не работал! Команда EXPLAIN.
Больше полезного про базы данных и SQL найдешь в моём Телеграм канале или на Дзене.
В 2016 году поставило руководство одному знакомому задачу: развернуть с нуля СКУД. Да чтоб автоматизировано всё было: с выгрузкой данных в 1С, с табелированием, с отчётами по опоздунам и т.д.
Было выбрано решение под ключ за 600 тыс. рублей.
Ого, говорит, начальство, как дорого! Мы найдём дешевле. Нашли за 200.
Проработала система "за 200" не больше полугода. Обратились к подрядчику, а он обанкротился и закрылся.
Зам начальника СБ привёл "моих рексов, которые всё умеют и щас сделают по-красоте!".
По-красоте вышло на 450 тысяч.
Когда с наступлением сырого времени года начали отказывать считыватели, оказалось, что они не предназначены для применения вне помещений. "Моим рексам" подкинули ещё 150 тыс на устранение недочётов.
Через год оказалось, что рексы наэкономили не только на железе, но и на софте. И когда БД упёрлась в лимит 4 Гбайта, она сказала "кря", и отказалась дальше работать.
После рексов пришла третья контора и сделала всё с нуля под ключ за 800 тысяч. Шёл 2018 год.
Провайдер может обещать 99,9% аптайма VPS, но аптайм продукта и аптайм инфраструктурного узла остаются разными показателями. Когда сервис падает, причина часто находится за пределами зоны ответственности провайдера: в приложении, деплое, базе данных, DNS или внешних API.
SLA VPS-провайдера покрывает доступность физического узла, сетевого канала и питания. Если оборудование работает и сеть доступна, инфраструктурная часть SLA может считаться выполненной. Код, конфигурации, база данных и внешние зависимости остаются в вашей зоне ответственности.
На практике многие простои возникают не из-за сбоев инфраструктуры, а из-за ошибок в коде и операционных процессах. Неудачный деплой, утечка памяти, переполненный диск, истёкший SSL-сертификат, недоступный DNS или упавший сторонний API гасят сервис независимо от стабильности хостинга.
Релиз без стейджинга и механизма отката, отсутствие проверок состояния, ручные правки конфигурации в продакшене: всё это классические источники простоев. Мониторинг, добавленный «потом», не предупреждает о проблеме до того, как её замечают пользователи.
Стабильность сервиса на VPS складывается из нескольких пунктов. Автоматические бэкапы и снапшоты упрощают восстановление после сбоя. Проверки состояния и алерты сокращают время обнаружения инцидента. CI/CD-пайплайн с проверками и понятным откатом снижает риск ошибок при деплое.
• Бэкапы и снапшоты настроены и проверены
• Мониторинг и алерты подключены до деплоя
• Есть процедура отката для каждого релиза
• SSL-сертификаты обновляются автоматически
• DNS TTL снижен перед плановыми миграциями
Аптайм сервиса на VPS-сервере зависит от инфраструктуры, архитектуры и операционных процессов одновременно. Пересмотрите собственные процессы: деплой, мониторинг, бэкапы и восстановление после сбоев. Если нужен взгляд со стороны, можно начать с аудита инфраструктуры и точек отказа.
Сравнение Local NVMe и облачного хранилища в Cloud VPS: влияние IOPS, p99 latency, QoS, виртуализации и соседей по серверу на производительность диска.
Пометка NVMe в тарифе не гарантирует предсказуемых задержек для Cloud VPS. Реальные характеристики дисковой подсистемы зависят от архитектуры хранилища, QoS-политик и уровня виртуализации I/O. NVMe важен, но не решающий фактор.
Производительность VPS под дисковой нагрузкой ограничивается несколькими факторами одновременно. QoS-политика и burst-лимиты IOPS могут влиять на результат не меньше, чем тип накопителя. Виртуализация I/O через virtio добавляет небольшой накладной расход. Конкуренция соседей по хосту даёт непредсказуемость p99-задержек.
Local NVMe даёт наименьшую задержку: p99 в пределах 100–300 мкс. Сетевые решения (NVMe-oF, Ceph RBD, SDS) повышают p99 из-за сетевого round-trip, зато включают репликацию и снапшоты. Выбор NVMe VPS оправдан для stateful-нагрузок с жёсткими требованиями к fsync-задержкам.
PostgreSQL и MySQL создают смешанную дисковую нагрузку: случайное чтение небольших блоков, fsync для WAL и последовательные сканирования. В продакшен-среде на Cloud VPS p99-задержка fsync напрямую влияет на задержку коммита. Burst-лимиты могут скрывать ограничение дисковой подсистемы до тех пор, пока нагрузка не превысит гарантированный уровень IOPS.
Классическая ошибка: фиксировать средний throughput вместо p99-latency. Запускайте fio с параметрами --rw=randread --bs=4k --iodepth=32 и смотрите процентили задержки. Утилита ioping показывает задержку одиночного I/O. Для PostgreSQL используйте pgbench после нескольких прогонов на прогрев кэша.
• Гарантированные IOPS и burst-лимит вашего VPS
• Архитектура хранилища: локальный NVMe или распределённое хранилище
• Есть ли гарантии по p99-задержке
• Схема репликации и RPO при сбое диска
• Доступность снапшотов и периодичность их создания
• Наличие оверкоммита и политика изоляции I/O
Тип диска в тарифе – это отправная точка. Перед миграцией проверьте дисковую подсистему по чек-листу и прогоните собственные тесты: реальные p99-задержки и стабильность IOPS могут отличаться от описания тарифа.
Если вы хоть немного следите за развитием искусственного интеллекта, то наверняка замечали: терминов становится всё больше.
И происходит путаница, подмена понятий. И вообще не понятно "что было первым: курица или яйцо"
В моем канале Аналитика FM выпуски про бизнесовые метрики в разных бизнесах, про особенности SQL запросов и работы аналитика.
Канал я веду с нуля подписчиков, рассказываю про аналитику и разбираю различные кейсы на реальных примерах.
И серия постов про путь до ai агентов.
Подписывайся, если интересно как устроен мир аналитика!
Какие термины этого направления окружают нас:
- Машинное обучение
- Нейросети
- Deep Learning
- Generative AI
- Foundation Models
- LLM
- AI-ассистенты
- AI-агенты
- Multi-Agent Systems
- Agentic Systems
Иногда возникает ощущение, что все это - просто разные названия одного и того же.
Но это не так.
Проблема в том, что эти термины описывают разные уровни технологий.
Одни говорят о том, как система обучается.
Другие - о том, какая модель используется.
Третьи - о том, какой продукт построен вокруг модели.
А четвёртые - уже о том, как система самостоятельно выполняет задачи и взаимодействует с другими системами.
Если сильно упростить историю, путь можно представить как движение от:
Научить компьютер находить закономерности
к:
Научить компьютер самостоятельно решать сложные задачи
Сначала компьютеры просто выполняли инструкции, которые заранее написал человек.
Потом появились методы машинного обучения, где система могла находить закономерности в данных.
Затем развивались модели, способные работать с гораздо более сложными типами информации: изображениями, текстом, речью, видео.
С развитием глубоких нейронных сетей появились современные генеративные модели, которые научились не только классифицировать или прогнозировать, но и создавать новый контент.
Дальше появились большие универсальные модели, которые можно использовать как основу для множества разных задач.
И наконец вокруг моделей начали строить полноценные приложения и системы: с памятью, инструментами, базами данных, API и возможностью выполнять действия.
Так постепенно мы пришли к тому, что сегодня называют AI-агентами.
Представим обычную языковую модель.
Мы пишем:
Проанализируй эти данные и найди закономерности
Модель анализирует то, что ей дали, и возвращает ответ.
Теперь представим другую систему.
Мы говорим:
Каждое утро проверяй продажи. Если найдёшь аномалию - выясни причину и подготовь отчёт
Такая система уже может:
получить данные
обратиться к базе
выполнить запрос
проанализировать результат
понять, что делать дальше
использовать дополнительные инструменты
проверить результат
сформировать отчёт
отправить его человеку
То есть между "моделью, которая отвечает" и "системой, которая выполняет задачу" появляется целый набор дополнительных компонентов.
И именно этот переход сейчас особенно интересен.
Когда мы говорим "искусственный интеллект", мы часто представляем что-то единое.
На практике это скорее большая экосистема.
Внутри неё находятся:
методы обучения
алгоритмы
модели
нейронные сети
генеративные модели
большие языковые и мультимодальные модели
приложения
ассистенты
инструменты
агенты
системы из нескольких агентов
И всё это может работать вместе.
Например, современный AI-агент может использовать языковую модель, обращаться к базе данных, вызывать API, читать документы, хранить состояние задачи и передавать результат другому агенту.
Поэтому, когда говорят:
Компания внедряет AI
это ещё почти ничего не говорит о том, что именно они внедряют.
Это может быть обычная ML-модель для прогнозирования.
Может быть генеративная модель.
Может быть чат-ассистент.
А может быть целая агентная система, которая выполняет бизнес-процесс.
Чем дальше мы двигаемся от модели к агентной системе, тем меньше AI выглядит как отдельный инструмент и тем больше - как участник рабочего процесса.
Модель:
отвечает.
Ассистент:
помогает.
Агент:
действует.
Агентная система:
может организовывать выполнение целого процесса.
Именно поэтому сейчас так много разговоров об AI-агентах.
Но чтобы действительно понимать, что они собой представляют, полезно сначала разобраться, из каких уровней вообще состоит эта технология.
Я как раз решил разобрать этот путь последовательно - от самых фундаментальных понятий до современных агентных систем.
Не одним огромным постом на 20 экранов, а серией коротких разборов, где каждый следующий уровень будет опираться на предыдущий.
📌 От машинного обучения и понятия модели - к нейросетям, генеративному AI, LLM, AI-приложениям, ассистентам, агентам и в итоге к Agentic Systems.
Подписывайся на мой телеграмм канала Аналитика FM!
Будем разбираться вместе!
Плюс там различные нюансы и особенности работы аналитика.
Измерение лага репликации PostgreSQL под нагрузкой помогает найти этап, где копится WAL. Разберём физическую репликацию PostgreSQL 18.
На асинхронной реплике replay_lag приближённо показывает задержку появления последних изменений. Отсчёт идёт от сохранения WAL на основном сервере до получения подтверждения его применения на реплике. Для проверки конкретной транзакции отслеживают появление её контрольной записи на реплике в новом снимке данных.
Для бенчмарка лага репликации PostgreSQL нужны четыре позиции WAL: sent – отправлено, write – записано в ОС, flush – сохранено на диск, replay – применено. Основной сервер показывает их в pg_stat_replication, получая последние три от реплики. pg_wal_lsn_diff считает разрывы в байтах: текущий LSN–sent, sent–write, write–flush, flush–replay.
На лаг в pg_stat_replication влияют режим репликации и частота отчётов. Поэтому до теста фиксируют версии, число реплик, synchronous_standby_names, synchronous_commit и слоты. Удержание WAL слотами ограничивает max_slot_wal_keep_size. Лимит проверяется при checkpoint.
Опрос обоих серверов пишет LSN и разрывы в CSV с шагом 1 с и метками UTC. Часы узлов синхронизируют. pg_last_xact_replay_timestamp() даёт время commit/abort последней применённой транзакции с основного сервера. При простое её возраст растёт даже у догнавшей реплики, lag может стать NULL.
На тестовом стенде постепенно увеличивают нагрузку записи через pgbench и регулярно снимают позиции WAL с обоих серверов. Разрывы между этапами показывают, где растёт очередь, а метрики сети, CPU и дисков помогают найти причину. Если мощности хватает, нагрузка может вообще не вызвать заметного отставания.
В CSV отмечают фазы pgbench. Для расчёта скорости WAL прирост текущего LSN делят на интервал между замерами. Лаг LSN PostgreSQL выражают в байтах. Чтобы измерить время catch-up, после остановки записи фиксируют конечный LSN и ждут, пока реплика его применит.
За этим разрывом могут стоять сеть, запись WAL или задержка отчёта реплики. Причину ищут по пропускной способности, потерям и работе walreceiver. p99 лага streaming replication считают отдельно по фазам, указав единицы и шаг опроса.
Оба разрыва живут на реплике, но упираются в разное: первый в диск, второй в применение WAL.
1. sent–write проверяют вместе с сетью и приёмником WAL: сам разрыв не доказывает сетевую проблему.
2. write–flush сопоставляют с задержками fsync и очередью диска реплики.
3. Для flush–replay проверяют CPU, I/O и конфликты запросов, учитывая отставание flush.
При synchronous replication synchronous_commit задаёт условие завершения COMMIT: remote_apply требует применения WAL на выбранных синхронных репликах.
Задержка replay WAL под нагрузкой возможна и при стабильном WAL generation rate: конфликт с запросом задерживает применение WAL. Увеличение max_standby_streaming_delay продлевает ожидание. Отмены запросов видны в pg_stat_database_conflicts. hot_standby_feedback уменьшает конфликты очистки ценой накопления старых версий строк на основном сервере.
Порог потери данных задают по RPO, а отставание данных и время catch-up ограничивают отдельно. Сохранённый на диск реплики WAL применяется и после отказа основного сервера. Причину уточняют по network RTT, CPU и I/O обоих узлов.
Измерение лага репликации PostgreSQL под нагрузкой даёт основу для оповещений по этапам: важны размер очереди и скорость её роста. Оповещение по одному порогу lag в секундах такой картины не даёт.
Время восстановления как ключевая метрика бэкапа показывает, сколько на самом деле продлится простой. Поэтому измерение времени восстановления планируют так же, как расписание копий. Результат зависит от сценария, объёма данных и доступных ресурсов. Тест на маленькой копии не подтверждает срок для рабочей базы.
Время восстановления определяет, как долго сервис будет недоступен после сбоя. Даже быстро созданную копию ещё предстоит получить, расшифровать и развернуть, а затем проверить данные и работу приложения под нужной нагрузкой. При этом скорость создания тоже важна, если от неё зависит соблюдение графика копирования.
Удалённая таблица и потерянная площадка требуют разных действий. В первом случае можно развернуть копию отдельно и вернуть нужные записи, проверив связанные данные. Во втором придётся заново собрать окружение: базу, приложение, сеть и доступы. Отказ VM при исправных дисках отличается от повреждения самой базы. После компрометации учётной записи нужно ещё убедиться, что сохранились доверенная копия и независимый доступ к ней.
Поэтому измерение времени восстановления начинают с одного сценария: фиксируют, что именно потеряно, какие ресурсы остались доступны и к какому состоянию нужно вернуться. Для ошибочного удаления это может быть момент перед опасной транзакцией. При отказе площадки обычно нужна последняя доступная согласованная точка данных.
До запуска команда договаривается, что считать работающим сервисом. Для магазина это, например, вход, просмотр заказов и оформление нового заказа. Одного восстановленного каталога для этого недостаточно. Если на первое время часть функций может не работать, договариваются об этом заранее.
RTO означает предельно допустимое время простоя. Это цель для сервиса, с которой сравнивают фактическую длительность восстановления. RTO резервной копии сам по себе ничего не значит: один и тот же архив развернётся за разное время на разных дисках и при разной подготовке команды. RPO задаёт, за какой период допустимо потерять данные. Эти цели согласуют с требованиями бизнеса.
В полном прогоне отсчёт начинается с имитации сбоя и заканчивается после проверки сервиса. В это время входят обнаружение, решение о восстановлении, получение доступа и подготовка среды. Если прогон начинается сразу с объявления аварии, задержку обнаружения учитывают отдельно, иначе результат окажется короче реального простоя.
После распаковки база может ещё применять журналы, а приложение ждать запуска службы авторизации или обновления DNS. Поэтому таймер останавливают после согласованных проверок, включая пробную нагрузку. В журнале сохраняют достигнутую точку данных для проверки RPO: быстро поднятый сервис может содержать слишком старое состояние.
Тестовая среда должна быть сопоставима с той, которая останется после аварии. В описании стенда нужны CPU, RAM, диски, полоса сети и версии ПО. Для копии указывают размер архива и развёрнутых данных, сжатие, шифрование и место хранения.
Тест восстановления RTO и RPO должен включать получение ключей, если при сбое их придётся запрашивать. В процедуру входят выдача доступа, поиск секретов и лицензий, настройка DNS. При потере площадки доступ к этим ресурсам должен сохраниться за её пределами. Время обработки заявок тоже попадает в журнал.
Изолируют не только данные, но и приложение. Восстановленная очередь не должна повторно отправить клиентам письма или платежи. Для внешних операций используют тестовые адреса и среды, явно отмечая, какие зависимости ими заменили.
Частоту учебного восстановления выбирают по критичности сервиса, допустимому простою и скорости изменений системы. Между плановыми проверками нужен новый тест после смены формата копии, шифрования, инфраструктуры или инструкции восстановления. Единого интервала нет, он должен учитывать и последствия сбоя, и затраты на каждый полный прогон.
Учебное восстановление из бэкапа должно повторять предусмотренный для аварии порядок действий. Если копия лежит в архивном классе хранилища, ожидание её выдачи входит в срок. Если файл скачан заранее, тест не покажет время его доставки. В журнале разделяют получение копии, расшифровку, проверку, распаковку, развёртывание базы и применение журналов.
Для каждого этапа сохраняют начало и конец в UTC, объём данных, статус, ошибки и повторы. Часы серверов синхронизируют. Длительности автоматических шагов лучше считать монотонным таймером, который не скачет при коррекции времени. Для ручного ожидания нужны обе отметки: отправка заявки и получение доступа. Для каждого прогона журнал и логи команд хранят отдельно, без паролей и токенов.
В PostgreSQL восстановление к моменту времени требует физической базовой копии и непрерывной цепочки WAL от начала копирования до выбранной точки. Для логического дампа нужна отдельная процедура загрузки. Если копия инкрементальная, учитывают получение и сборку всей необходимой цепочки. Работа сторонних сервисов тоже входит в общий срок.
Проверка начинается с файлов. Для полной физической копии PostgreSQL 18, сохранённой pg_basebackup как каталог с backup_manifest и нужным WAL, подходит команда:
pg_verifybackup --exit-on-error /srv/restore/base \
> verify.log 2>&1
Здесь /srv/restore/base – каталог копии до запуска базы. При ошибке причину ищут в verify.log. Утилита той же основной версии сверяет файлы с манифестом и проверяет необходимый для копии WAL. Успех не гарантирует ни наличие всех последующих журналов до точки PITR, ни исправность приложения. Это ограничение pg_verifybackup.
После запуска нужны проверки согласованности средствами СУБД и контрольные запросы по известным данным. Для магазина это наличие выбранных заказов, их состав и итоговые суммы. Бенчмарк point-in-time recovery показывает, дошло ли восстановление до выбранной точки: при ошибочной записи нужные транзакции должны сохраниться, а ошибочная – отсутствовать. Достигнутую точку сверяют с журналом восстановления и независимым учётом операций, а её отставание от момента сбоя сравнивают с RPO. Время создания копии этой проверки не заменяет. После завершения восстановления проверяют вход, чтение и запись через приложение.
Метрики проверки бэкапа сводят на одну временную шкалу: все этапы восстановления с началом и концом каждого. Она показывает активную работу, автоматические паузы и ожидание людей. Параллельные этапы не складывают: общий срок задаёт самая долгая цепочка зависимых действий, необходимых для готовности сервиса. Её сокращают в первую очередь.
1. От сбоя до начала работ: обнаружение, решение, получение доступа и подготовка среды.
2. Возврат данных: доставка, расшифровка, проверки, развёртывание и применение журналов.
3. Возврат сервиса: запуск зависимостей, переключение доступа и проверка пользовательских операций.
Сетевую задержку отделяют от ожидания диска, расшифровки на CPU и последовательного применения журналов. Для грубой оценки: 200 ГиБ при постоянных 100 МиБ/с идут около 34 минут. Это расчёт только доставки, без ожиданий и последующих работ. Остальные этапы могут занять больше времени, чем сама передача. Улучшение подтверждает новый полный прогон с теми же условиями и проверками.
Runbook – инструкция, по которой дежурный восстанавливает сервис. Для каждого шага в ней нужны команда, ожидаемый результат и действие при ошибке. Повторный запуск должен либо продолжить работу, либо безопасно остановиться. Если скрипт заново создаёт диск, он должен отличить свой тестовый ресурс от чужого. Шаги, которые перезаписывают данные или переключают трафик, помечают в инструкции отдельно, а перед запуском требуют подтвердить адрес или имя ресурса.
Следующий прогон проводит другой инженер без подсказок автора. Поиск ключа, забытый пакет или ручная правка конфигурации показывают, чего не хватает в инструкции. Такой прогон выявляет зависимость инструкции от знаний автора.
Отдельными прогонами разбирают недоступный ключ, повреждённую копию и отказ основного хранилища. Каждый из них подтверждает запасной путь или остановку с понятной причиной. При отказе хранилища важна и скорость передачи с запасного источника: throughput запасного пути обычно ниже, чем у основного. Если данные получить не удалось, сценарий считается непройденным.
По каждой причине превышения срока команда назначает ответственного, выбирает исправление и дату повторного теста. Долгое ожидание доступа требует пересмотра процедуры выдачи, а перегруженный диск – проверки другой конфигурации. Когда скорость упирается в сеть, помогает более широкий канал. Долгое применение WAL лечится более свежей базовой копией. Задержку на сборке среды снимает заранее подготовленная резервная инфраструктура.
Такая подготовка сокращает время ценой постоянных расходов. Если staging используют как площадку восстановления, нужно заранее проверить запас ресурсов и порядок освобождения. Пропуск validation, то есть проверки результата, ускорением не считается: без неё неизвестно, можно ли вернуть пользователей.
В истории сохраняют все попытки с датой, исполнителем, версиями, объёмом данных и отклонениями от инструкции. Сравнивают одинаковые сценарии при сопоставимых ресурсах и состоянии кеша. Для нескольких прогонов показывают каждую длительность и причину разброса. Процентили имеют смысл, когда сопоставимых прогонов набралось достаточно много: p99 по трём попыткам ничего не говорит о редких задержках.
Время восстановления как ключевая метрика бэкапа полезно, когда за числом стоит проверенный результат. Копия, из которой ни разу не восстанавливали, остаётся предположением: до первого удачного прогона неизвестно ни время, ни полнота данных, ни работоспособность сервиса. Полный журнал этапов, точка данных и проверки сервиса показывают, удалось ли уложиться в RTO и RPO. Найденная задержка должна привести к изменению инструкции, ресурсов или архитектуры. После смены формата копии или окружения прежний результат нужно подтвердить повторным восстановлением.
Если вы работаете с базой данных и начали заглядывать не только в обычные SELECT, рано или поздно встретите два слова: функция и процедура.
На первый взгляд они практически близнецы.
И там, и там можно объявить переменные, поставить условия, сделать запрос к таблице, организовать циклы и вообще спрятать довольно большую часть логики внутри одного объекта.
Тогда возникает вполне логичный вопрос:
а зачем вообще два разных объекта, если они умеют примерно одно и то же?
А в моем канале Аналитика FM выпуски про бизнесовые метрики в разных бизнесах, про особенности SQLзапросов и работы аналитика.
Канал я веду с нуля подписчиков, рассказываю про аналитику и разбираю различные кейсы на реальных примерах.
Подписывайся, если интересно как устроен мир аналитика!
Разница на самом деле довольно простая.
Функция нужна тогда, когда мы хотим что-то получить в результате.
Процедура - когда нам нужно что-то сделать.
Например, представим, что в базе есть таблица клиентов, а нам нужно определить, является ли клиент активным.
Можно сделать функцию:
CREATE OR REPLACE FUNCTION is_active_client( p_client_id NUMBER )
RETURN NUMBER IS v_status VARCHAR2(20);
BEGIN SELECT status
INTO v_status
FROM clients
WHERE client_id = p_client_id;
IF v_status = 'ACTIVE' THEN RETURN 1;
ELSE RETURN 0;
END IF;
END;
Здесь функция получает client_id, что-то делает внутри и обязательно возвращает результат.
Поэтому её можно использовать непосредственно в SQL:
SELECT client_id, is_active_client(client_id) AS is_active FROM clients;
Получается довольно естественная конструкция:
«Вот тебе клиент. Скажи, активный он или нет».
Функция ответила — 1 или 0.
А теперь представим совершенно другую задачу.
Нам нужно массово обновить статус клиентов, записать информацию об операции в журнал и, возможно, выполнить ещё несколько действий.
Для этого больше подходит процедура:
CREATE OR REPLACE PROCEDURE update_client_status(
p_client_id NUMBER,
p_status VARCHAR2 )
IS BEGIN
UPDATE clients
SET status = p_status
WHERE client_id = p_client_id;
INSERT INTO client_log(client_id, action_date)
VALUES (p_client_id, SYSDATE);
END;
Здесь нам не нужно спрашивать у процедуры:
«Какой результат ты мне вернёшь?»
Мы говорим:
«Возьми этого клиента, измени ему статус и запиши информацию об изменении».
То есть процедура выполняет действие.
И вот здесь появляется важное отличие.
У функции есть RETURN.
Например:
RETURN NUMBER
Она может вернуть:
число;
строку;
дату;
другой тип данных;
иногда даже сложный объект.
Поэтому функция хорошо подходит для вычислений и получения какого-то значения.
Например:
SELECT calculate_revenue(client_id) FROM clients;
или:
SELECT order_id, calculate_discount(order_id) AS discount FROM orders;
Процедура может:
INSERT
UPDATE
DELETE
вызывать другие процедуры и функции, работать с переменными, условиями, циклами и выполнять достаточно сложную бизнес-логику.
Вызов процедуры выглядит иначе:
BEGIN
update_client_status(123, 'ACTIVE');
END;
Мы не используем её как обычное значение внутри SELECT.
Мы просто запускаем действие.
И здесь есть интересный нюанс.
Процедура тоже может что-то вернуть через OUT-параметры.
Поэтому говорить:
"процедура ничего не возвращает"
не совсем корректно.
Она может передать вызывающему коду результаты своей работы.
Но концептуально разница остаётся:
функция отвечает на вопрос "что получилось?"
процедура отвечает на вопрос "что нужно сделать?"
Вот здесь начинается самое интересное.
Представьте, что правило расчёта скидки используется в десяти разных местах системы.
Можно десять раз написать/запустить один и тот же SQL запрос.
Но тогда однажды бизнес скажет:
"Теперь скидка считается по новым правилам".
И начинается веселье.
Нужно найти все десять мест и исправить логику.
Вместо этого можно вынести правило в функцию:
calculate_discount(...)
И теперь разные запросы используют одну и ту же логику.
Изменили функцию - изменилось правило расчёта в одном месте.
С процедурами похожая история.
Если в компании есть сложная последовательность действий, её можно спрятать за одной процедурой.
Например:
создать договор → записать клиента → создать связанные записи → записать информацию в журнал → изменить статус
Вместо того чтобы каждый разработчик реализовывал всё это самостоятельно, можно вызвать одну процедуру, которая уже знает, как именно компания должна выполнить эту операцию.
И вот поэтому функции и процедуры в Oracle - это не просто "два разных вида".
Это способ собрать бизнес-логику внутри базы и переиспользовать её.
При этом аналитику не обязательно каждый день создавать процедуры и функции.
Но понимать их очень полезно.
Если вам интересны именно такие нюансы - не только синтаксис, но и то, как всё это устроено в реальной работе аналитика, - я разбираю их в своём Telegram-канале "Аналитика FM". Там как раз про SQL, данные и те самые моменты, на которых чаще всего приходится останавливаться и разбираться.
