Приведите реальный случай, где SQL делал запрос яснее или эффективнее: сложная агрегация, оконные функции, CTE или массовая операция. Переход оправдывают планом и поддерживаемостью, а не неприязнью к ORM.
FOR UPDATE конфликтует со всеми четырьмя режимами. NO KEY UPDATE допускает KEY SHARE; SHARE допускает SHARE и KEY SHARE; KEY SHARE блокирует UPDATE, но совместим с остальными названными режимами.
Опишите уровень владения SQL на реальных задачах: join, агрегации, транзакции, планы и индексы. Уточните, где использовали ORM, а где осознанно переходили к чистому SQL.
Оптимизация начинается с измерения и понимания запроса: что он должен вернуть, с какими параметрами, как часто выполняется и где тратит время. Затем изучают план, объёмы строк и ожидания.
B-Tree индексирует значения с точным поиском по упорядоченной структуре, а BRIN хранит сводки по диапазонам страниц. BRIN особенно полезен на огромных таблицах с корреляцией значения и физического порядка данных.
Penetration — промахи по отсутствующим данным, avalanche — массовое истечение или потеря кеша, warmup — его предварительное заполнение. Для распродажи нужны прогрев и защита БД от лавины промахов.
Нужны минимальные стартовые настройки вне БД: адрес, способ авторизации и параметры подключения. Затем процесс должен дождаться готовности БД, а не только факта запуска её контейнера или службы.
Сначала оценю блокировки, объём переписываемых данных и влияние на живую нагрузку. Затем выберу безопасный поэтапный план, окно выполнения, наблюдаемые ограничения и способ остановки или отката.
При WAL журнал изменений должен попасть на устойчивый носитель раньше соответствующих страниц данных. После отключения питания содержимое RAM теряется, но зафиксированные изменения восстанавливаются по журналу.
Ответьте, где и для чего использовали SQLAlchemy: Core или ORM, синхронный или асинхронный доступ, какие БД и объёмы задач. Затем приведите конкретный пример работы с запросами и транзакциями.
Сначала подтвержу узкое место измерениями, затем изучу план, объём данных, блокировки и частоту выполнения. Решение может быть в индексе, изменении запроса, устранении лишних вызовов или другой модели чтения.
В одном процессе можно защитить проверку и изменение баланса общим Lock. Важно блокировать весь read-check-write, а не только присваивание; все обращения к состоянию должны соблюдать тот же протокол.