Индексирование и Альтернативы для столбцов с низкой селективностью

Я согласен с неразумия это филиала. Но есть кое-что, что нужно знать об этом деле.

Это называется косой и косой убивает. Это идеальное использование для частичного индекса, где вы исключаете 95% оплаченных счетов-фактур и индексируете только более интересную и выборочную статистику. Но у тебя его нет. Вы можете горизонтально разбить все строки на отдельные таблицы/разделы, но затем вам нужно учитывать миграцию строк (перемещение из одного состояния в другое) и это дорого. СУБД должна выполнить обновление, удаление и вставку для изменения состояния. Если вы система с большим объемом, это будет больно.

забудьте, что вы сказали о том, следует ли индексировать на основе избирательности, потому что размещение индекса на быстро меняющемся столбце также обычно является плохой идеей. Ваш индекс будет иметь горячие блоки, где все шаги 1 удаляются, а другой, где все шаги 2 вставляются и Oh кстати, некоторые шаги 2 удаляются на то же время в Шаг 3. Это не будет хорошо масштабироваться.

Я бы рекомендовал вертикально разбить ваш статус на отдельную таблицу(ы).

ваша таблица счетов будет иметь ПК и все столбцы, кроме статуса.

ваш статус вы можете обрабатывать двумя способами. Эта таблица будет иметь значение PK как FK обратно в таблицу накладных, статус и отметку времени для ввода этого статуса. Лучше всего-горизонтально секционированная таблица состояния. У вас будет раздел для каждого статуса возможно. Таким образом, поиск всех или одного "помещенного" статуса будет разделять чернослив и читать только тот раздел, который ему нужен - это очень небольшое количество блоков. Поскольку строка настолько узкая, вы можете получить 400 статусов счетов-фактур в одном блоке. Поиск этого статуса любого счета-фактуры легко, так как на ПК есть глобальный индекс.

Если ваша СУБД не поддерживает секционирование с миграцией строк, вам нужно будет управлять этими разделами как таблицами и удалять из одного и вставлять в другую. Вы инкапсулируете эти движения в транзакцию в процедуре, чтобы сохранить данные чистыми. Каждый счет в одной и только одной таблице состояния. Более сложная часть запрашивает идентификатор счета-фактуры, вам нужно будет проверить каждую таблицу, чтобы увидеть, где она находится.

у вас есть другой выбор Вы можете писать платные статусы или нет. Если это секционированная таблица, можно просто удалить накладную из таблицы состояние накладной при ее перемещении в оплаченную. (Конечно, вы напишете оплаченная запись в таблицу истории, указанную в Бонусном материале). Затем вы сделаете внешнее соединение с таблицей состояния, и nulls будет означать paid. Если вы почти никогда не запрашиваете платный статус, Нет причин делать это быстрым запросом.

Бонусы

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