SQL · Подзапрос в WHERE · Процессоры Intel

Подзапросы SELECT в базе данных процессоров Intel

Таблица «processor_families» — 20 строк детерминированно сгенерированных данных. Показанный ниже Подзапрос в WHERE реально выполнен движком FileDB: 9 строк в результате, 1.3 мс на выполнение, полным сканом таблицы.

Структура таблицы processor_families

Поля и типы данных

Поле	Тип	Nullable	Индекс
`id`	int	нет	да (PK)
`family_name`	varchar(80)	нет	—
`segment`	varchar(80)	нет	—
`introduced_year`	int (2000–2024)	нет	—

Пример строк (8 из 20)

id	family_name	segment	introduced_year
1	Core 2 Duo	Desktop	2010
2	Celeron	Mobile	2018
3	Core Ultra 5	Server	2015
4	Xeon W	HEDT	2014
5	Core 2 Duo	Embedded	2020
6	Core Ultra 5	Desktop	2011
7	Core 2 Duo	Desktop	2018
8	Core i9	Server	2002

SQL-запрос: Подзапрос в WHERE

Задача: найти строки, где introduced_year выше среднего по таблице — среднее считает подзапрос.

SELECT * FROM processor_families WHERE introduced_year > (SELECT AVG(introduced_year) FROM processor_families) LIMIT 20;

SQL Playground · processor_families.fdbFileDB Engine

результат появится ниже

Результат выполнения

20строк в таблице

9строк в результате

1.3 мсвремя выполнения

В результате 9 строк из 20 (около 45%). Если бы условие возвращало почти всю таблицу, фильтр был бы бесполезен; ноль строк — повод проверить значения в данных, а не синтаксис.

Первые строки результата

id	family_name	segment	introduced_year
12	Core i5	Mobile	2023
15	Core Ultra 5	Desktop	2022
18	Celeron	HEDT	2020
2	Celeron	Mobile	2018
3	Core Ultra 5	Server	2015

Показаны 5 из 9 строк результата.

Как читать этот запрос

Подзапрос в WHERE вычисляется первым, его результат подставляется в условие внешнего запроса. Здесь это скалярный подзапрос (возвращает одно число — среднее), поэтому с ним можно сравнивать оператором >.

Фактическое время: 1.29 мс. Для сравнения: тот же запрос через сетевой протокол добавил бы миллисекунды на сериализацию и round-trip — встраиваемый движок исполняет его in-process.

Подзапрос в WHERE в разных СУБД

СУБД	Синтаксис	Отличие
PostgreSQL	`WHERE x > (SELECT AVG(x) …)`	планировщик может материализовать подзапрос
MySQL	`WHERE x > (SELECT AVG(x) …)`	исторически слабее оптимизирует коррелированные подзапросы
SQLite	`WHERE x > (SELECT AVG(x) …)`	скалярный подзапрос вычисляется один раз, если не коррелирован
FileDB	`WHERE x > (SELECT AVG(x) …)`	скалярные подзапросы в WHERE поддержаны

Скачать структуру и данные

Файлы собираются из текущего датасета (seed v1): структура таблицы, 20 строк данных и этот запрос.

⬇ CREATE TABLE + INSERT (.sql) ⬇ Для PostgreSQL (.sql) ⬇ Тестовые данные (.csv) ⬇ processor_families.fdb (бинарный файл для FileDB)

Вопросы и ответы

Сколько раз выполняется подзапрос?

Некоррелированный скалярный подзапрос (как здесь, AVG по всей таблице) — один раз. Коррелированный, ссылающийся на текущую строку, — потенциально на каждую строку.

Чем подзапрос отличается от JOIN?

Подзапрос отвечает на «вычисли значение/множество для условия», JOIN — «пристыкуй колонки другой таблицы к результату». Часто выразимо и так и так; выбирайте читаемое.

Что вернёт сравнение, если подзапрос дал NULL?

Неизвестность: строка не пройдёт условие. На пустой таблице AVG вернёт NULL — и внешний запрос не вернёт ничего.