Comments 8
Не очень понимаю, какой смысл в таком индексе. Если имеется 2-5 значений в колонке, то эффективнее сделать частичный индекс на каждое значение (или группу). Это сильно ускорит выполнение, уберет лишние выражения из дерева запроса и упростит жизнь планировщику.
Поддержу, в статье ни слова нет про частичные индексы которые почти обязаны быть при soft del, без этого статью как будто mysqlщики писали в 2004.
Ps, а ещё можно наследование таблиц и удаленные в отдельную, что тоже сработает как частичный индекс если чеки висят (даже эффективной)
Частичные индексы упомянуты в конце статьи.
Мне хотелось разобрать случай с "обычными" индексами.
А почему частичный индекс по false в выводах? В случае с soft delete таких значений будет явно больше чем true. 🤔
Хотя в реальной жизни логичнее использовать индекс только по значениям is_deleted = True, т. к. удаленные строки чаще всего не нужны в постоянной работе.
Что-то я запутался совсем. Выводы одни, вводные другие.
Как по мне, то рассмотрение одного-единственного варианта (мягкого удаления) не сильно соответствует заявленной теме статьи. Я ожидал увидеть исследование, которое рассматривает композитные индексы как из нескольких полей с низкой cardinality, так и в совокупности с другими полями, включая и варианты покрывающих индексов, и формирование хоть каких эмпирических рекомендаций на тему "надо ли вообще, а если да, то в какой именно позиции выражения индекса". А вместо этого голый soft delete, да ещё при сознательном отказе от рассмотрения частичных индексов, хотя они доступны в используемой СУБД.
В общем, заголовок - [censored]. А к самой статье - без претензий.
Я понял вашу идею. Но нет смысла писать такую статью, ее объем будет значительно больше, а по сути это будет учебник по индексами. В этом случае лучше взять уже существующий материал (например, статья Рогова) и читать ее.
Моя цель была рассмотреть случай, когда индекс вопреки всем мурзилкам работает неплохо.
В MSSQL есть where индексы, и такие индексы становятся полезными. Например, пусть есть поле is_processed 0,1 но в основном записи уже обработаны. Нас интересуют необработанные. Пишем:
Create index ... On... Where is_processed=0
И он будет содержать только необработанные записи
Об индексах на столбцах с низкой кардинальностью