Читая об индексе хранилища кластеризованных столбцов в SQL Server 2014, я задаюсь вопросом, является ли наличие таблицы с огромным количеством столбцов анти-шаблоном. В настоящее время, чтобы решить проблему наличия одной таблицы с большим количеством столбцов, я использую вертикальное разбиение, но Доступен кластерный индекс хранилища столбцов, в этом нет необходимости. Это правильно или я что-то упускаю?
Пример. Возьмем, к примеру, журнал счетчиков производительности. Необработанные данные могут иметь следующую структуру:
╔══════════════════╦═══════╦═══════╦═════╦═════╦═════╦══════════╗ ║ Time ║ Perf1 ║ Perf2 ║ ... ║ ... ║ ... ║ Perf1000 ║ ╠══════════════════╬═══════╬═══════╬═════╬═════╬═════╬══════════╣ ║ 2013-11-05 00:01 ║ 1 ║ 5 ║ ║ ║ ║ 9 ║ ║ 2013-11-05 00:01 ║ 2 ║ 9 ║ ║ ║ ║ 9 ║ ║ 2013-11-05 00:01 ║ 3 ║ 2 ║ ║ ║ ║ 9 ║ ║ 2013-11-05 00:01 ║ 4 ║ 3 ║ ║ ║ ║ 9 ║ ╚══════════════════╩═══════╩═══════╩═════╩═════╩═════╩══════════╝
Наличие такой таблицы с 1000 столбцов — это зло, потому что одна строка, скорее всего, будет занимать более одной страницы, потому что обычно маловероятно, что кто-то будет заинтересован во всех показателях, но запрос всегда будет нести затраты на ввод-вывод и т. д. и т. д. .. Для решения этой проблемы обычно помогает вертикальное разбиение, например, можно разделить счетчики производительности в разных таблицах по категориям (ЦП, ОЗУ и т. д.).
И наоборот, наличие такой таблицы в качестве кластеризованного индекса хранилища столбцов не должно быть такой проблемой, поскольку данные будут храниться по столбцам, а ввод-вывод для каждого запроса будет касаться только запрошенных столбцов, ничего больше независимо от общего количества столбцов в таблице.
[i]s the only index on the table. It cannot be combined with any other indexes- person criticalfix schedule 04.11.2013