Желательно ли указывать индекс кластера при загрузке отсортированного загрузочного файла в новую таблицу?

Question

INFORMIX-SE:

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

(См. Скрипт REORG.SQL по адресу: SE: аномалия 'bcheck -y' )

(См. Также: customer.pk_name, присоединяющийся к транзакциям. Имя_файла против. customer.pk_id [serial], объединяющий транзакции.fk_id [целое число] по причине, по которой индекс кластера указан по имени, а не pk_id [serial] = fk_id [int])

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

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

Answer 1

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

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

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