Приводит ли выбор только индексированных атрибутов к более быстрым запросам? - PullRequest
1 голос
/ 26 марта 2009

При выполнении запроса, когда выбранные атрибуты составляют компоненты индекса, это приводит к более быстрому запросу? Я полагаю, что планировщик / оптимизатор запросов мог видеть, что запрошенные столбцы могут быть полностью удовлетворены сканированием индекса.

Тривиальный пример

CREATE TABLE "liked" (
  "id" BIGINT NOT NULL DEFAULT nextval('liked_id_seq'),
  "userid" BIGINT NOT NULL,
  "storyid" BIGINT NOT NULL,
  "notes" TEXT,
  PRIMARY KEY ("id")
);
CREATE INDEX "liked_user" ON "liked" (
  "userid",
  "storyid"
);
ALTER TABLE "liked" ADD FOREIGN KEY ("userid") REFERENCES "users" ("id") ON DELETE CASCADE;
ALTER TABLE "liked" ADD FOREIGN KEY ("storyid") REFERENCES "story" ("id") ON DELETE CASCADE;


SELECT storyid from liked where userid = 1;

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

Ответы [ 4 ]

3 голосов
/ 26 марта 2009

Он называется «индексом покрытия» и несколько повышает эффективность, варьируя количество в зависимости от того, какую СУБД вы используете (и если вы используете MySQL, какой тип хранилища).

Попробуйте привести пример конкретной ситуации, если она у вас есть.

1 голос
/ 26 марта 2009

Можно, но есть некоторые оговорки. Эти комментарии основаны на Oracle, кстати.

Например, SELECT COL1 FROM MY_TABLE может использовать индекс, но если все столбцы индекса обнуляются, то могут быть строки, не включенные в обычный индекс btree, поэтому индекс может не использоваться.

Также возможно, что индекс может быть больше (и, следовательно, более дорогостоящим для полного сканирования), чем базовая таблица (например, где таблица имеет только один столбец), потому что индекс должен также включать в себя идентификатор строки для каждой записи. в качестве значения столбца. В этом случае, если запрос не может использовать информацию индекса каким-либо особым образом (например, вы включаете предложение ORDER BY, которое индекс может предоставить без необходимости сортировки), индекс может не использоваться.

Вам также следует изучить различные методы доступа к индексам, которые СУБД может использовать, чтобы понять их сильные и слабые стороны. В Oracle это, как правило, будет СКАНИРОВАНИЕ ДИАПАЗОНА ИНДЕКСА, СКАНИРОВАНИЕ ПОЛНОГО ИНДЕКСА, СКАНИРОВАНИЕ БЫСТРОГО ПОЛНОГО ИНДЕКСА и СКАНИРОВАНИЕ ИНДЕКСА. Эти знания помогут вам понять, может ли индекс использоваться и каким образом.

1 голос
/ 26 марта 2009

Не так много, по моему опыту. Вы ускоряете запросы, оптимизируя их условия и пытаясь использовать наилучший из возможных индексов в этих условиях. Есть много способов замедлить запрос, основанный на том, что вы выбираете, например, используя подзапросы, возможно, некоторые UDF - и, конечно, вы можете замедлять запросы, используя неоптимальные объединения.

1 голос
/ 26 марта 2009

В общем, да, но это зависит от того, как вы к ним обращаетесь. Использование LIKE для отключения совпадения в середине строкового поля не будет быстрее с индексом.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...