Наткнулся на интересный кейс на Хабре — DBA с 15-летним опытом решил создать собственную систему мониторинга СУБД.

Так появился Lumen — инструмент для мониторинга SQL Server и PostgreSQL, вдохновлённый Spotlight for SQL Enterprise.

Он собирает данные о сессиях, блокировках, запросах, планах выполнения, памяти, дисках, бэкапах и репликации. Есть Playback для разбора прошлых инцидентов, 100 встроенных правил алертов и отдельный AI Operator на базе локальной LLM, который следит за состоянием серверов и помогает разбирать возникающие проблемы.

Выглядит как довольно интересный проект для DBA и тех, кто плотно работает с базами данных.

https://habr.com/ru/articles/1080080/

👉 @SQLPortal

SQL Debugging: вопрос с собеседования

Этот запрос должен возвращать всех клиентов, а также их отправленные заказы, если они есть.

Что с ним не так? Сработает ли такой запрос? Если нет, как его исправить?

👉 @SQLPortal

Шпаргалка по системному дизайну для собеседований

Если ты хочешь уверенно пройти системное интервью в Google, Meta, Amazon или Netflix — тебе сюда

Автор собрал шпаргалку с ключевыми концептами, книгами и курсами для подготовки

⏩Архитектура масштабируемых систем
⏩Балансировка нагрузки, кэширование, очереди (Kafka, Redis)
⏩SQL vs NoSQL, шардирование, репликация
⏩REST vs gRPC, WebSockets, CDN
⏩CQRS, event-driven, микросервисы vs монолит
⏩Надёжность: circuit breaker, leader election (Raft, Paxos)
⏩Безопасность: OAuth, JWT, rate limiting

—> Полный гайд тут

👉 @SQLPortal

Сегодня узнал, что SQLite преобразует целые числа в текст сразу по две цифры.

Обычно преобразование числа в строку делают циклом с делением на 10 и взятием остатка от деления на 10.

SQLite избегает большей части этих операций: внутри хранится строка длиной 200 байт со всеми двузначными комбинациями от 00 до 99.

Затем SQLite просто берёт по две цифры за раз по нужному индексу, вместо того чтобы вычислять каждую цифру отдельно.

👉 @SQLPortal

SQL-вопрос:

Какое из следующих утверждений верно относительно результата этого запроса?

👉 @SQLPortal

Загружать 100 000 строк, чтобы посчитать одну итоговую сумму, — странный способ защитить базу данных от лишней работы.

SQL и сам прекрасно умеет считать суммы.

👉 @SQLPortal

SQL-вопрос: Будьте внимательны — здесь есть подвох.

Что вернёт этот запрос и почему?

👉 @SQLPortal

Главное правило SQL GROUP BY, которое должен знать каждый

Если в SELECT используются неагрегированные столбцы, убедитесь, что они добавлены в GROUP BY. Это не просто хорошая практика — в некоторых базах данных это обязательное требование.

Почему это важно?

GROUP BY определяет, что представляет собой одна строка результата. База данных должна точно понимать, какое единственное значение поместить в каждую ячейку этой строки.

В запросе ниже одна строка = одна должность (job_title) внутри конкретного отдела (department). Поэтому и department, и job_title должны присутствовать в GROUP BY.

Если пропустить неагрегированный столбец:

• Некоторые СУБД вернут ошибку
• Другие могут вернуть произвольное значение
• Запрос может «работать» сегодня, но завтра вернуть некорректный результат

Общее правило

Каждый столбец в SELECT должен быть функционально зависим от GROUP BY. Если внутри одной группы столбец может содержать несколько значений, его нужно либо добавить в GROUP BY, либо использовать с агрегатной функцией.

👉 @SQLPortal

Я написал два почти одинаковых SQL-запроса.

Один оказался в 451 раз быстрее. Я реализовывал cursor pagination и добавил composite index, чтобы ускорить запрос. Но вместо этого он стал медленнее.

Query plan показывал Index Scan — так в чём же была проблема? Дело было не в размере dataset. Проблема заключалась в том, как сравнивались значения cursor.

После перехода на tuple comparison PostgreSQL смог эффективно использовать composite index. Время выполнения: 0,668 мс.

Та же логика pagination, но совершенно другой query plan.
Без проверки query plan эту проблему можно было бы легко пропустить.

👉 @SQLPortal

Большой бесплатный гайд по SQL для начинающих

На freeCodeCamp лежит полноценный текстовый курс по SQL, который ведёт от самых основ до более серьёзных тем. Материал построен последовательно и подойдёт тем, кто только начинает разбираться в реляционных базах данных.

Внутри: таблицы и типы данных, CRUD, SELECT и WHERE, constraints, агрегатные функции, подзапросы, нормализация, JOIN и основы оптимизации запросов. Для практики в курсе используется SQLite, при этом отдельно разбираются различия между SQL-базами.

Хороший материал, чтобы системно пройти SQL с нуля или освежить базу.

👉 @SQLPortal

SQL-вопрос: Какой запрос возвращает только premium-пользователей?

👉 @SQLPortal

SQL-вопрос: Интересно, как вы ответите на этот вопрос.

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

Ну что, знатоки SQL, погнали!

👉 @SQLPortal

ОЧЕНЬ ПЛОХАЯ ПРИВЫЧКА

Зачем вообще использовать номера позиций столбцов в GROUP BY?

Ну серьёзно, ЗАЧЕМ, ЗАЧЕМ, ЗАЧЕМ? 😬
По-моему, это просто ленивый способ писать SQL-код. Всё, я это сказал.

Убедите меня, что я неправ.

👉 @SQLPortal

SQL-вопрос:

Какой запрос находит клиентов, которые сделали хотя бы один заказ?

👉 @SQLPortal

SQL-вопрос:

Какой запрос вы бы выполнили?

👉 @SQLPortal