Таблица MySQL information_schema.processlist предоставляет большой объем информации о текущем состоянии сервера MySQL. Она важна для администраторов и разработчиков баз данных, чтобы мониторить эти данные для обеспечения оптимальной производительности и диагностики потенциальных проблем. В этой статье мы познакомимся с несколькими запросами MySQL, предназначенными для извлечения полезных идей из списка процессов, и обсудим, насколько они могут помочь нам в мониторинге и оптимизации сервера MySQL.
1. Просмотр всех процессов
Чтобы получить исчерпывающий обзор всех текущих процессов на сервере MySQL, вы можете использовать следующий запрос:
Выбор правильного формата резервной копии может составлять разницу между 10-минутным восстановлением и целым днем мучений. Утилита pg_dump в PostgreSQL предоставляет множество форматов вывода, каждый из которых оптимизирован для различных сценариев - от быстрой разработки снимков до восстановления после сбоев производственных баз. Понимание этих форматов помогает построить такую стратегию восстановления, которая сбалансирует эффективность использования хранилища, скорость восстановления и операционную гибкость. В этом руководстве рассматриваются пять ключевых форматов резервных копий с указанием, когда использовать каждую из них.
У меня есть данные, пришедшие в мой SQL Server в формате JSON. Перед началом парсинга, который довольно интенсивный, необходимо проверить, присутствуют ли некоторые значения в этом JSON. Имеется ли функция, которую я могу использовать с этой целью? Давайте посмотрим, что может делать JSON_CONTAINS, новая функция в SQL Server 2025.
В одной из предыдущих статей я описывал, как работает обеспечение целостности внешних ключей в Postgres. Краткая версия такова: каждая команда INSERT или UPDATE в таблицу, ссылающуюся на другую, запускает триггер AFTER, который проверяет, существуют ли значения столбца внешнего ключа (FK) в ссылочной (PK) таблице. Эта проверка проходит через SPI (Server Programming Interface): строится запрос, он планируется, выполняется, а затем всё уничтожается — для каждой отдельной строки.
Это дорогостоящая операция. При массовой вставке (INSERT) миллиона строк в таблицу с внешним ключом вы выполняете миллион мини-запросов к индексу таблицы первичного ключа. Каждый из них открывает отношение первичного ключа, захватывает снимок (snapshot), выполняет проверку прав, делает поиск по индексу и закрывает всё. Стоимость одной строки в абсолютном выражении невелика, но она очень быстро накапливается.
Для Postgres 19 я применил два патча (соавтором обоих является Джунванг Жао), которые полностью обходят SPI для стандартного случая и выполняют пакетную (batch) проверку индекса. Вместе они ускоряют массовые вставки с внешними ключами примерно в 2.9 раза в используемом мною тесте (int первичный ключ, int внешний ключ, 1 миллион строк, таблица первичного ключа и её индекс в памяти).Что деаёт быстрый путь (fast path)
Продолжить чтение "Postgres: более быстрые проверки внешних ключей"
Каждый, кто хотя бы по колено погрузился в фотографию, знает о существовании треугольника экспозиции: диафрагма, выдержка и светочувствительность (ISO). В зависимости от того, какого художественного эффекта вы хотите добиться, вы регулируете эти три параметра, понимая, что у каждого изменения есть своя цена. Проработав несколько реальных случаев и предложив решения заказчикам, я начал думать о настройке производительности Postgres схожим образом. Существуют базовые параметры, которые можно настраивать, и у каждого выбора администратора баз данных есть свои последствия:
Распределение памяти (Memory Allocation)
Дисковый ввод-вывод (Disk I/O)
Конкурентность (Concurrency)
Каждый из этих факторов (в общих чертах) влияет на пропускную способность — то есть на то, какой объём работы ваша система успевает выполнить.
Оговорка: Я понимаю, что с академической точки зрения понятие «пропускной способности» не полностью отражает суть баланса между этими концепциями, но, пожалуйста, отнеситесь к этому снисходительно!
Давайте поговорим о том, как каждый из этих трёх аспектов взаимодействует со всей системой и как выглядят сопутствующие компромиссы.
(Эта статья написана применительно к PostgreSQL 9.3. Если вы используете более новую версию, пожалуйста, проверьте, остались ли описанные ограничения в силе.)
PostgreSQL предлагает несколько инструментов для поиска и сопоставления текстовых шаблонов. Сложность заключается в выборе подходящего инструмента для конкретной задачи.
В течение долгого времени я работал с разными компьютерными языками и кодирование бинарных данных было необходимо в первую очередь потому, что требовалось передавать данные на другой компьютер.
Функции кодирования: BASE64_ENCODE и BASE64_DECODE
В язык T-SQL были добавлены две новых функции: BASE64_ENCODE, BASE64_DECODE . Эти функции взаимно обратны, подобно функциям шифрования. Одна функция возвращает вспять действия другого, и они предназначены для совместного использования. Продолжить чтение "T-SQL в SQL Server 2025: функции кодирования"
Вы выполняете SELECT * FROM orders в одном сеансе psql и видите 50 миллионов строк. Ваш коллега в другом сеансе выполняет тот же запрос в тот же момент и видит 49 999 999. Никто из вас не ошибается, и никто не видит устаревших данных. Вы оба читаете одни и те же страницы кучи размером 8 КБ, одни и те же байты на диске.
В этом заключается обещание MVCC (многоверсионного контроля конкурентного доступа) PostgreSQL, и именно поэтому читатели никогда не блокируют писателей, а писатели никогда не блокируют читателей. Это также одна из самых неправильно понимаемых частей механизма хранения. Люди знают, что «существует несколько версий строки», и на этом останавливаются.
При работе с очень большими таблицами в PostgreSQL традиционные индексы типа B-Tree или GiST могут чрезвычайно вырасти в размерах, что занимает значительное время на их обслуживание. Для временных рядов или последовательно упорядоченных данных PostgreSQL предлагает более разумный и облегченный вариант: BRIN (Block Range Index).
Индексы BRIN группируют данные в диапазоны блоков вместо хранения отдельных записей строк, что делает их компактными, быстрыми в построении и эффективными для запросов на диапазон или упорядоченные данные.
Легко перемещайте данные из SQL Server в Oracle 26ai Free, используя это пошаговое руководство. Узнайте как установить связанный сервер, сконфигурировать FREEPDB1 и избежать типичных ошибок.
Недавно мне пришлось перенести некоторые данные из SQL Server на Oracle 26ai в редакции Free. Я решил проверить, поможет ли связанный сервер сделать эту работу, поскольку зачастую это самый простой способ…
Это позволит мне просто писать операторы INSERT SELECT, но в SQL Server, связанные серверы с Oracle, известны своей неуклюжестью и часто имеют проблемы с некоторыми типами данных, настройками времени, и т. д.
При работе со схемами реляционных баз данных вы можете предполагать, что удаление столбца физически удаляет его из табличного хранилища. В PostgreSQL это не всегда так.
Начиная с PostgreSQL 11, операция ALTER TABLE ... DROP COLUMN стала выполняться быстрее, поскольку PostgreSQL больше не переписывает всю таблицу сразу. Напротив, он:
Помечает столбец как удаленный (невидимый и недоступный).
Временно оставляет его данные на диске.
Освобождает хранилище, только когда таблица переписывается (VACUUM FULL, CLUSTER или pg_repack).
Такой подход позволяет избежать долгого выполнения переписывания таблицы и делает изменения схемы менее деструктивными для больших таблиц.
Иногда миграция оказывается более сложной, чем ожидалось. На первый взгляд определение функции STR в SQL Server является простым: она возвращает символьное представление числовых данных, выровненные по правому краю с заданной длиной и точностью до десятичных знаков. Однако при попытке конвертации вы обнаруживаете огромное число пограничных случаев, большинство из которых плохо документированы.
