Является ли CLUSTER INDEX желательным при загрузке отсортированного загрузочного файла в новую таблицу?

Question

INFORMIX-SE:

Мои пользователи периодически запускать скрипт SQL [REORG.SQL], который выгружает все строки из таблицы в отсортированном порядке в двух отдельных файлах (Активны и Inactives), падает таблица, повторно создает table, загружает отсортированные файлы загрузки в него, создает индекс кластера в одном столбце. Я сортировал свои файлы разгрузки, создавал другие поддерживающие индексы и обновлял свою статистику.

(См REORG.SQL скрипт на: SE: 'bcheck -y' anomaly)

(Также см: customer.pk_name joining transactions.fk_name vs. customer.pk_id [serial] joining transactions.fk_id [integer] по причине, почему кластер индекс по имени и не pk_id [серийный номер] = fk_id [INT])

С моей REORG .SQL-скрипт, у меня были проблемы с постоянством индексного файла, поэтому я подозревал, что CLUSTER INDEX имеет к этому какое-то отношение и создал индекс без кластеризации, и проблемы исчезли!

Теперь мой вопрос: если мне удастся загрузить все данные о транзакциях, отсортированные по полному имени клиента во вновь созданной таблице, мне действительно необходимо создать индекс CLUSTER, если на самом деле строки уже отсортированы в том же порядке, что и кластеризация? .. Я знаю, что кластеризованный индекс начинает терять свою кластеризацию при добавлении новых строк, так что в чем преимущество создания индекса кластера? .. оптимизатор запросов использует преимущества кластеризации против. некластеризованный индекс, когда строки по существу находятся в одном кластерном порядке? .. Кто-нибудь сталкивался с проблемами IDX/DAT-файла при кластеризации таблицы? .. Возможно, у моего SQL-скрипта что-то не так? (ПОЖАЛУЙСТА, ОБРАТИТЕ МОЙ СЦЕНАРИЙ КОДА МЕНЯ, ЧТОБЫ УВИДЕТЬ, ЕСЛИ Я ЧТО-ТО ЧТОБЫ НЕПРАВИЛЬНО?)

Answer 1

Сценарий выгружает активные и неактивные транзакции в два разных файла с каждым файлом, отсортированным по имени клиента. Затем он загружает их обратно в таблицу, активные транзакции сначала, а затем неактивные транзакции. Затем создается кластерный индекс по имени клиента. Проблема заключается в том, что теперь база данных должна возвращаться и переназначать физические строки по имени клиента при построении кластерного индекса. Хотя каждый из файлов разгрузки отдельно заказывается по имени клиента, когда они объединены, результат не упорядочивается по имени клиента, что приводит к большей работе для базы данных. Если отдельные файлы для активных и неактивных транзакций не нужны в другом месте, вы можете попробовать просто сбросить все транзакции в один файл, упорядоченный по имени клиента, а затем повторно загрузить таблицу из этого единственного файла. В этот момент данные в таблице будут упорядочены по имени клиента, а кластерному индексу create не нужно будет переупорядочивать данные.

Что касается нужного кластеризованного индекса - кластерный индекс может иметь значение, если вы используете этот столбец для запроса, поскольку это должно помочь уменьшить количество операций ввода-вывода, необходимых для извлечения данных. Обычно кластерные индексы создаются в столбцах, которые монотонно возрастают, поэтому, возможно, TRX_NUM будет служить столбцом, который будет называться кластеризованным индексом.

Делитесь и наслаждайтесь.