Можно ли создать таблицу без кластеризованного индекса

Что проверяют

Понимаете ли вы, что «кластеризованный индекс» это термин конкретных СУБД, а не общее свойство SQL, и знаете ли, как хранит строки та база, с которой работаете вы.

Как отвечать

Ответ зависит от базы, и это главное, что хотят услышать.

• PostgreSQL: кластеризованных индексов нет вообще. Таблица это куча, все индексы вторичные и ссылаются на физический адрес строки. Команда CLUSTER разово переупорядочивает таблицу под выбранный индекс и дальше порядок не поддерживает.
• MySQL с InnoDB: наоборот, таблица и есть кластеризованный индекс по первичному ключу. Если ключ не объявлен, InnoDB возьмёт первый уникальный индекс по колонкам NOT NULL, а если и такого нет, заведёт скрытый ключ по номеру строки. То есть таблицы InnoDB без кластера не бывает.

Практический вывод для Java-приложения: в InnoDB вторичный индекс хранит внутри значение первичного ключа, поэтому широкий ключ раздувает сразу все индексы. Случайный UUID первичным ключом бьёт по скорости вставки, потому что новые строки ложатся в случайные страницы. Обычно берут bigint с автоинкрементом, а UUID выносят в отдельную уникальную колонку.

Где спотыкаются

Переносят словарь SQL Server на PostgreSQL и ищут кластеризованный индекс там, где его не бывает. Правильная формулировка: PostgreSQL хранит строки в куче и порядка хранения не гарантирует.

Повторяют за шпаргалками, что первичный ключ это всегда некластеризованный индекс. В InnoDB ключ и есть кластер, в SQL Server первичный ключ по умолчанию тоже создаётся кластеризованным.

Считают CLUSTER в PostgreSQL настройкой таблицы. Это разовая операция, которая переписывает таблицу целиком и держит на ней исключительную блокировку: на большой таблице получается окно недоступности, а не «включил и забыл».