SQL Server Express: ограничения и для чего подходит

SQL Server Express это бесплатная версия SQL Server с ограничениями: максимум 10 ГБ на базу данных, 1 ГБ оперативной памяти для буферного пула и 4 ядра процессора. Для небольших проектов, сайтов и стартапов этого достаточно, но для серьёзного продакшена придётся покупать Standard или Enterprise (и вот тут начинается самое интересное).

Полный список ограничений Express

Короче, давайте разложим всё по полочкам. Вот таблица, которую стоит распечатать и повесить над монитором:

Вот в чём прикол: 10 ГБ на базу это не 10 ГБ на весь сервер. Вы можете создать 100 баз по 10 ГБ. Ограничение действует на каждую базу отдельно. Это важный нюанс, который многие не знают.

Но 1 ГБ RAM это серьёзно. На самом деле SQL Server Express использует примерно 1410 МБ (не ровно гигабайт). Для базы на 2-3 ГБ хватает. Для 8-10 ГБ уже будут тормоза, потому что данные не помещаются в буферный пул и SQL постоянно читает с диска.

Тут такое дело: даже если у вашего сервера 64 ГБ RAM, Express будет использовать только 1.4 ГБ. Остальная память просто простаивает. Грубо говоря, вы покупаете мощный сервер, а SQL Server Express использует его как калькулятор.

Для чего Express подходит идеально

Express не для всего, но есть сценарии, где он прекрасен:

• Небольшие веб-сайты. Блог, интернет-магазин на 1000 товаров, корпоративный сайт. База редко превышает 1-2 ГБ
• Разработка и тестирование. Полная совместимость с Standard/Enterprise, код работает одинаково. Язык SQL тот же, хранимые процедуры те же, индексы те же
• Десктопные приложения. Встраиваемая база для клиентских программ (LocalDB). Не нужен отдельный сервер, база работает локально
• Микросервисы. Маленькие сервисы с небольшими базами. Каждый микросервис со своей базой на 1-2 ГБ
• Учебные проекты. Полноценный SQL Server бесплатно. Студенты учатся на том же движке, который используется в production
• Прототипирование. Быстро создать прототип, показать клиенту, и потом перейти на Standard для production

Если честно, для стартапа Express это подарок. Нулевые затраты на лицензирование, а когда вырастете, перейдёте на Standard. Миграция занимает час (а точнее, 15 минут на ввод ключа и перезагрузку).

Мой знакомый Максим запустил интернет-магазин автозапчастей на SQL Server Express. Комп обычный, Core i5, 16 ГБ оперативки. База 4 ГБ, 50 тысяч товаров, 200-300 заказов в день. Работает уже два года без единой проблемы. По факту, Express для него идеален, потому что база далека от лимита 10 ГБ, и нагрузка умеренная.

Для чего Express не подходит

А вот где Express буксует, и никакие оптимизации не помогут.

1С Предприятие с базой больше 5-6 ГБ. 1С активно использует tempdb, и 4 ядра + 1 ГБ RAM быстро становятся узким местом. Знаете что, если у вас 1С с 20+ пользователями, даже не думайте про Express. Проведёте на переключение на Standard всё равно, но потеряете время на диагностику тормозов.

Хранилища данных (Data Warehouse). 10 ГБ закончатся через месяц-два. Для аналитики Express не вариант.

Высоконагруженные системы. 4 ядра это потолок. Под нагрузкой процессор будет в 100%, запросы встанут в очередь, пользователи будут ждать.

Отказоустойчивость. Нет Always On Availability Groups, нет Database Mirroring (deprecated, но всё ещё используется), нет Log Shipping (вручную можно, но SQL Agent нет, поэтому автоматизация через Windows Task Scheduler).

Автоматизация. SQL Server Agent отсутствует. Нет джобов, нет расписаний, нет автоматического обслуживания (перестроение индексов, обновление статистики, проверка целостности). Всё это нужно делать через Task Scheduler и скрипты PowerShell.

Express vs Standard: когда переходить

Переход нужен когда:

• База приближается к 8 ГБ (не ждите 10, оставьте запас)
• Запросы начинают тормозить из-за лимита памяти
• Нужен SQL Server Agent для автоматизации (бэкапы, обслуживание)
• Требуется отказоустойчивость (Always On)
• Пользователей стало больше 50-100
• CPU на сервере постоянно загружен на 70%+ из-за SQL

Кстати, переход с Express на Standard это просто ввод нового ключа. Базы, настройки, логины, всё сохраняется. Никакой переустановки, никакого переноса данных.

# Обновление Express до Standard через командную строку
# Базы данных не затрагиваются, меняется только лицензия
setup.exe /ACTION=EDITIONUPGRADE /INSTANCENAME=MSSQLSERVER /PID="YOUR-STANDARD-KEY"

# Проверяем текущую редакцию
SELECT SERVERPROPERTY('Edition') AS Edition,
       SERVERPROPERTY('ProductVersion') AS Version,
       SERVERPROPERTY('ProductLevel') AS Level

Ольга, владелица веб-студии из Казани, держала 8 клиентских сайтов на одном SQL Server Express (Lenovo ThinkCentre M920). Каждая база 1-3 ГБ. Когда один из клиентов вырос до 9 ГБ, она обновила до Standard. Весь процесс занял 15 минут с перезагрузкой. Ни один сайт не пострадал.

Express Advanced Services

А ещё есть Express with Advanced Services. Та же бесплатная версия, но с бонусами:

• Full-Text Search (полнотекстовый поиск)
• Reporting Services (SSRS, отчёты)
• R и Python интеграция (Machine Learning Services)

Ограничения по RAM, CPU и размеру базы те же самые. Но если нужен полнотекстовый поиск или встроенные отчёты, берите Advanced Services. Весит столько же, устанавливается так же. На самом деле, нет причин ставить обычный Express, если можно поставить Advanced Services бесплатно.

Обход ограничения 10 ГБ

Есть легальные способы работать с данными больше 10 ГБ на Express:

Партицирование данных между базами. Старые данные в одной базе, новые в другой. Каждая до 10 ГБ. Но запросы между базами медленнее, и логика приложения усложняется.

Архивация. Переносите старые записи в архивную базу. Рабочая база остаётся маленькой. Это самый правильный подход с точки зрения архитектуры.

FILESTREAM. BLOB-данные (файлы, картинки, документы) хранятся на диске в файловой системе, а не в базе. Не считаются в лимит 10 ГБ. Подходит для приложений, которые хранят много файлов.

-- Проверяем размер базы, чтобы понимать сколько осталось
-- reserved показывает занятое место
EXEC sp_spaceused

-- Детальнее по файлам базы
SELECT
    name AS FileName,
    size * 8 / 1024 AS SizeMB,
    FILEPROPERTY(name, 'SpaceUsed') * 8 / 1024 AS UsedMB,
    (size - FILEPROPERTY(name, 'SpaceUsed')) * 8 / 1024 AS FreeMB
FROM sys.database_files

-- Мониторинг роста базы
-- Запускайте периодически, чтобы заметить приближение к лимиту
SELECT
    DB_NAME() AS DatabaseName,
    SUM(size * 8 / 1024) AS TotalSizeMB,
    SUM(FILEPROPERTY(name, 'SpaceUsed') * 8 / 1024) AS UsedMB
FROM sys.database_files
WHERE type = 0 -- только файлы данных, не логи

Бэкапы без SQL Server Agent

В Express нет Agent. Но бэкапы всё равно нужны. Используем Task Scheduler и PowerShell.

# Скрипт бэкапа для Express, запускается через Task Scheduler
# Сохраняем как backup-express.ps1
$server = "localhost"
$backupPath = "D:Backups"
$date = Get-Date -Format "yyyy-MM-dd_HHmm"
$retentionDays = 7

# Получаем список всех баз (кроме tempdb)
$databases = Invoke-Sqlcmd -ServerInstance $server -Query "SELECT name FROM sys.databases WHERE name NOT IN ('tempdb')"

foreach ($db in $databases) {
    $dbName = $db.name
    $backupFile = "$backupPath$dbName`_$date.bak"

    # Делаем бэкап с компрессией
    Invoke-Sqlcmd -ServerInstance $server -Query "BACKUP DATABASE [$dbName] TO DISK = '$backupFile' WITH COMPRESSION, INIT"
    Write-Host "Backed up: $dbName to $backupFile"
}

# Удаляем старые бэкапы
Get-ChildItem $backupPath -Filter "*.bak" |
    Where-Object {$_.LastWriteTime -lt (Get-Date).AddDays(-$retentionDays)} |
    Remove-Item -Force

Настройте Task Scheduler на запуск этого скрипта каждую ночь. Грубо говоря, это заменитель SQL Server Agent для бэкапов. Не так удобно, но работает.

Кстати, не забывайте про обслуживание баз: перестроение индексов и обновление статистики. Без SQL Agent это тоже через Task Scheduler:

# Скрипт обслуживания (запускать раз в неделю)
$server = "localhost"
$databases = Invoke-Sqlcmd -ServerInstance $server -Query "SELECT name FROM sys.databases WHERE name NOT IN ('master','model','msdb','tempdb')"

foreach ($db in $databases) {
    $dbName = $db.name
    # Обновляем статистику
    Invoke-Sqlcmd -ServerInstance $server -Database $dbName -Query "EXEC sp_updatestats"
    # Перестраиваем индексы с фрагментацией > 30%
    Invoke-Sqlcmd -ServerInstance $server -Database $dbName -Query "
        DECLARE @sql NVARCHAR(MAX) = ''
        SELECT @sql = @sql + 'ALTER INDEX ' + i.name + ' ON ' + OBJECT_SCHEMA_NAME(i.object_id) + '.' + OBJECT_NAME(i.object_id) + ' REBUILD;'
        FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') s
        JOIN sys.indexes i ON s.object_id = i.object_id AND s.index_id = i.index_id
        WHERE s.avg_fragmentation_in_percent > 30 AND i.name IS NOT NULL
        EXEC sp_executesql @sql"
    Write-Host "Maintained: $dbName"
}

Где купить лицензию при переходе

Когда Express перестанет хватать (а это произойдёт, если проект растёт), лицензию SQL Server Standard или Enterprise можно купить в keytrust24.store. Обновление с Express на Standard делается без переустановки, вводом нового ключа. Ну и Windows Server для хостинга тоже есть в наличии.

На самом деле, не откладывайте переход, если видите, что база приближается к 8 ГБ. Лучше перейти на Standard заранее и спокойно, чем экстренно, когда база упрётся в 10 ГБ и приложение начнёт падать с ошибками. Знаете что, ключик SQL Server Standard окупится в первый же день, когда вам не придётся разбираться с ошибкой «database is full».

Express и tempdb: скрытое ограничение

Про лимит в 10 ГБ на базу все знают. Но мало кто задумывается про tempdb. Эта системная база данных используется для временных таблиц, сортировок, хеш-джойнов, версионирования строк (если включён RCSI) и кучи других внутренних операций.

Вот в чём прикол: tempdb тоже ограничена теми же 1.4 ГБ буферного пула. Если ваш запрос делает большую сортировку или создаёт здоровенную временную таблицу, tempdb начинает сбрасывать данные на диск. А это медленно.

-- Проверяем размер tempdb
SELECT
    name AS FileName,
    size * 8 / 1024 AS SizeMB,
    FILEPROPERTY(name, 'SpaceUsed') * 8 / 1024 AS UsedMB
FROM tempdb.sys.database_files

-- Кто сейчас жрёт tempdb
SELECT
    t.session_id,
    t.database_id,
    t.user_objects_alloc_page_count * 8 / 1024 AS UserObjMB,
    t.internal_objects_alloc_page_count * 8 / 1024 AS InternalObjMB
FROM sys.dm_db_task_space_usage t
WHERE t.user_objects_alloc_page_count > 0
   OR t.internal_objects_alloc_page_count > 0

Короче, если видите тормоза в запросах со сложными JOIN или ORDER BY на больших таблицах, проблема может быть именно в tempdb. На Express с этим мало что можно сделать, кроме оптимизации самих запросов.

Безопасность в Express

По факту, Express поддерживает почти все механизмы безопасности полного SQL Server:

• Windows Authentication и Mixed Mode
• Transparent Data Encryption (TDE) начиная с SQL Server 2019 Express
• Row-Level Security (RLS)
• Dynamic Data Masking
• Always Encrypted (базовый)
• Firewall правила и Contained Databases

Кстати, TDE в Express появилась относительно недавно. Раньше шифрование данных «at rest» было только в Enterprise. Теперь даже на бесплатной версии можно шифровать базу. Это важно для соответствия требованиям 152-ФЗ и других нормативов.

Тут такое дело: единственное серьёзное ограничение в безопасности Express это отсутствие аудита (SQL Server Audit). В Standard и Enterprise можно логировать, кто какие запросы выполнял, кто менял данные, кто заходил. В Express придётся делать это вручную через триггеры или Extended Events.

Мониторинг Express: что следить

Без SQL Server Agent мониторинг усложняется. Но есть несколько вещей, которые нужно отслеживать постоянно:

-- Топ-5 самых тяжёлых запросов по CPU
SELECT TOP 5
    qs.total_worker_time / qs.execution_count AS avg_cpu,
    qs.execution_count,
    SUBSTRING(st.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(st.text)
          ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)+1) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY avg_cpu DESC

-- Процент попадания в буферный пул (Page Life Expectancy)
-- Если меньше 300, памяти мало
SELECT
    object_name, counter_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Page life expectancy'
  AND object_name LIKE '%Buffer Manager%'

-- Ожидания: что тормозит SQL Server
SELECT TOP 10
    wait_type,
    wait_time_ms / 1000 AS wait_sec,
    signal_wait_time_ms / 1000 AS signal_sec
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('SLEEP_TASK','BROKER_TO_FLUSH','SQLTRACE_BUFFER_FLUSH',
    'CLR_AUTO_EVENT','CLR_MANUAL_EVENT','LAZYWRITER_SLEEP','CHECKPOINT_QUEUE',
    'WAITFOR','XE_TIMER_EVENT','BROKER_EVENTHANDLER','FT_IFTS_SCHEDULER_IDLE_WAIT',
    'XE_DISPATCHER_WAIT','SQLTRACE_INCREMENTAL_FLUSH_SLEEP')
ORDER BY wait_time_ms DESC

Если честно, Page Life Expectancy (PLE) это самый важный показатель для Express. Он показывает, сколько секунд страница данных живёт в буферном пуле. Если PLE меньше 300 секунд, SQL Server постоянно выгружает данные из памяти и читает их заново с диска. Это верный признак, что 1.4 ГБ RAM уже не хватает.

Мой коллега Дима, DBA из Новосибирска, настроил мониторинг Express через PowerShell и Telegram-бота на своём домашнем сервере (Dell PowerEdge T40, Xeon E-2224G, 32 ГБ RAM). Скрипт каждые 5 минут проверяет PLE, размер базы и CPU. Если что-то выходит за пределы, бот присылает уведомление. Грубо говоря, самодельный мониторинг за ноль рублей.

Express и контейнеры

А ещё SQL Server Express отлично работает в Docker. Microsoft публикует официальные образы на Docker Hub. Для разработки и тестирования это вообще идеальный вариант:

# Запуск SQL Server Express в Docker
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_PID=Express" 
  -e "SA_PASSWORD=YourStrong!Passw0rd" 
  -p 1433:1433 
  --name sql-express 
  -d mcr.microsoft.com/mssql/server:2022-latest

# Подключение через sqlcmd
docker exec -it sql-express /opt/mssql-tools18/bin/sqlcmd 
  -S localhost -U SA -P "YourStrong!Passw0rd" -C

Контейнер с Express занимает около 1.5 ГБ на диске. Поднимается за 10-15 секунд. Для CI/CD пайплайнов, где нужна база для интеграционных тестов, Express в Docker работает на ура. Каждый тест получает чистую базу, после теста контейнер удаляется.

Кстати, в Kubernetes тоже можно запускать Express. Но для production это сомнительная идея: нет нормального кластеринга, нет Always On. Для dev/staging окружений подходит отлично.

Сравнение Express с PostgreSQL

Знаете что, в последние годы многие задают вопрос: а зачем Express, если есть PostgreSQL без ограничений и тоже бесплатный?

По факту, если ваше приложение привязано к экосистеме Microsoft (.NET, 1С, SharePoint, Active Directory), Express логичный выбор. Миграция на Standard потом безболезненная. Если приложение кроссплатформенное и нет привязки к Microsoft, PostgreSQL может быть лучше, потому что нет искусственных ограничений.

Тут такое дело: переход с Express на PostgreSQL это полная переделка слоя данных. Другой диалект SQL, другие типы данных, другие хранимые процедуры. А переход с Express на Standard это 15 минут и один ключик. Учитывайте это при выборе.