🖥 usql - универсальный SQL-клиент для работы с любыми базами данных

usql — это интерактивный SQL-клиент, который объединяет работу с разными СУБД в одном инструменте. По ощущениям он похож на psql, но поддерживает сразу множество баз данных и не привязывает тебя к одному движку.

Главная идея usql — один клиент для всех SQL-баз.

Что умеет usql:

- Подключение к PostgreSQL, MySQL, SQLite, MSSQL, Oracle, ClickHouse, CockroachDB, MariaDB и другим СУБД
- Единый интерфейс и одинаковые команды для разных движков
- Интерактивный режим с историей команд и автодополнением
- Удобный табличный вывод результатов
- Запуск SQL-скриптов из файлов
- Гибкая настройка цветов, форматов и pager’а

Почему это удобно:

- Не нужно держать десяток разных клиентов
- Не нужно переключать мышление между psql, mysql и sqlcmd
- Один привычный REPL для аналитики и администрирования
- Отлично подходит для работы сразу с несколькими базами

Кому особенно полезен usql:
- backend-разработчикам
- аналитикам данных
- DevOps-инженерам
- всем, кто регулярно работает с разными СУБД

Если ты живёшь в терминале и часто общаешься с SQL-базами, usql быстро становится инструментом по умолчанию.

github.com/xo/usql/

🖥 SQL-совет по оптимизации - используй DISTINCT ON вместе с правильным индексом (PostgreSQL)

DISTINCT ON часто недооценивают, но в PostgreSQL это один из самых быстрых способов выбрать «последнюю запись на группу» без подзапросов и оконных функций.

Проблема
Нужно получить, например, последнюю запись по каждому user_id, отсортированную по created_at.

Типичное (медленное) решение
- оконная функция ROW_NUMBER()
- подзапрос с GROUP BY + JOIN

Редкое и очень быстрое решение
DISTINCT ON + индекс, совпадающий с ORDER BY.

Пример
Получаем последнюю сессию каждого пользователя.

SELECT DISTINCT ON (user_id)
       user_id,
       session_id,
       created_at
FROM user_sessions
ORDER BY user_id, created_at DESC;

Почему это быстро
PostgreSQL берет первую строку на каждую группу user_id согласно ORDER BY и сразу останавливается - без сортировки всего результата и без оконных функций.

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

CREATE INDEX idx_user_sessions_distinct
ON user_sessions (user_id, created_at DESC);

Что дает такой индекс
- Index Scan вместо Seq Scan
- Нет дополнительной сортировки
- Очень быстрый выбор «последней записи на группу» даже на миллионах строк

Где особенно полезно
- логины пользователей
- события
- статусы
- версии сущностей
- time-series данные

DISTINCT ON - это PostgreSQL-специфичная оптимизация, но если ты работаешь с Postgres, это один из самых мощных и редких трюков.

🖥 SQL совет: как избежать хитрой ошибки с LEFT JOIN

Одна из самых коварных SQL-ошибок возникает при использовании LEFT JOIN вместе с условиями в WHERE.

Типичная ситуация:
Ты делаешь LEFT JOIN, чтобы сохранить строки из основной таблицы,
а потом незаметно превращаешь его в INNER JOIN.

Почему так происходит
Если в WHERE есть условие на колонку из присоединенной таблицы,
строки с NULL автоматически отфильтровываются.

В итоге:
- LEFT JOIN есть
- но результат как у INNER JOIN
- данные «пропадают», и баг сложно заметить

Правильное правило
Все условия для таблицы из LEFT JOIN:
- должны быть в ON
- а не в WHERE

Иначе ты теряешь строки, где JOIN не сработал.

Когда это особенно опасно
- отчеты и аналитика
- подсчет метрик
- поиск «отсутствующих» данных
- антиджойны

Эта ошибка не ломает запрос.
Она ломает доверие к данным.

🖥 Docker большой исчерпывающий курс. Глава 1. Архитектура, понятия и первый запуск

Курс по Docker, написанный программистами для программистов. Мы выкинули историю контейнеризации и скучную теорию.

Вместо этого жесткая практика: ментальные модели через ООП, анатомия Linux-процессов, написание Dockerfile, docker-compose и подготовка к продакшену.

Экономь время: учись только тому, что реально используется в индустрии

https://uproger.com/docker-bolshoj-ischerpyvayushhij-kurs-glava-1-arhitektura-ponyatiya-i-pervyj-zapusk/

🖥 Продвинутый SQL-совет по оптимизации: делай запросы "питающимися индексом" (index-only scan) с правильным составным индексом.

Идея: не просто добавить индекс на один столбец, а так подобрать порядок полей, чтобы запрос вообще не ходил в таблицу, а читал всё из индекса. Это даёт огромный буст на "горячих" таблицах.

Допустим, у тебя часто есть такой запрос:

SELECT
    id,
    created_at,
    total_amount
FROM orders
WHERE user_id = 123
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

Типичная ошибка - делать что-то вроде:

CREATE INDEX idx_orders_user ON orders (user_id);
CREATE INDEX idx_orders_status ON orders (status);
CREATE INDEX idx_orders_created ON orders (created_at);

Планировщику всё равно приходится лазить в таблицу и склеивать условия. Гораздо эффективнее один правильный составной индекс:

CREATE INDEX idx_orders_user_status_created_at
ON orders (user_id, status, created_at DESC)
INCLUDE (total_amount);

Почему это полезно:

user_id, status - фильтруют строки

created_at DESC - сразу даёт нужный порядок для ORDER BY ... DESC

INCLUDE (total_amount) - позволяет взять сумму прямо из индекса

В результате PostgreSQL (и другие СУБД с подобной механикой) могут сделать index-only scan: прочитать подходящие строки в нужном порядке из одного индекса и почти не трогать основную таблицу.