практика 'Индексы: Алгоритмы'
This commit is contained in:
+32
@@ -0,0 +1,32 @@
|
|||||||
|
-- Задание 1
|
||||||
|
-- 1. будет
|
||||||
|
-- 2. не будет. можно изменить запрос - убрать lower
|
||||||
|
-- 3. не будет. нужно убрать like
|
||||||
|
-- 4. не будет. нужно убрать like
|
||||||
|
-- 5. будет
|
||||||
|
-- 6. не будет, тк фильтрация по полю без индекса
|
||||||
|
|
||||||
|
|
||||||
|
-- Задание 2
|
||||||
|
-- не понял задание, сначала нужно каждому запросу сказать что индекс не нужен/бсполезен, а потом создать индекс?
|
||||||
|
-- 1. по идее есть смысл создать два индекса - по user_id и created_at, или состваной.
|
||||||
|
CREATE INDEX idx_orders_user_id ON orders(user_id);
|
||||||
|
CREATE INDEX idx_orders_created_at ON orders(created_at);
|
||||||
|
-- 2. тут никакой индекс не нужен
|
||||||
|
-- 3. тут тоже индекс не нужен, тк у status всего 4 значения
|
||||||
|
|
||||||
|
|
||||||
|
-- Задание 3
|
||||||
|
-- 1. тут hash, тк равенство
|
||||||
|
-- 2. здесь индекс и не нужен, тк у status всего 4 значения
|
||||||
|
-- 3. тут B-tree, тк интервал(<,>)
|
||||||
|
-- 4. конкретно в этом запросе лучше hash, тк равенство, но в целом думаю на user_id лучше B-tree, тк часто сортируют по нему
|
||||||
|
|
||||||
|
-- * hash иммет смысл где просто равенство
|
||||||
|
-- * B-tree обязательно там где интервалы, > или <, и где order by
|
||||||
|
-- * в варианте 2, где у столбца всего 4 уникальных значения
|
||||||
|
|
||||||
|
|
||||||
|
-- Задание 4
|
||||||
|
-- * первый составной нужен для запросов с фильтрацией по нескольким полям
|
||||||
|
-- * второй не нужен, тк user_id будет рабоать эффективно и в первом случае
|
||||||
Reference in New Issue
Block a user