Блог

У меня есть тест Post&resql на 10.13 и я ищу несколько ответов по индексам. Давайте возьмем для примера эту таблицу и допустим, что в ней 40 тысяч записей :

 CREATE TABLE "public"."ecom_input"
(
    "id"            serial PRIMARY KEY,
    "ecom_id"       INTEGER NOT NULL,
    "sku_supplier"  CHARACTER VARYING(100) NOT NULL
);
  

1. Имеет ли ПЕРВИЧНЫЙ КЛЮЧ свой собственный индекс автоматически?
   С помощью этого запроса :

 EXPLAIN SELECT * FROM ecom_input WHERE id = 27846;
  

Я получаю одинаковые результаты независимо от того, использую ли я ПЕРВИЧНЫЙ КЛЮЧ или ИНДЕКС :

 --&&t; Index Scan usin& ecom_input_pkey on ecom_input  (cost=0.29..8.31 rows=1 width=853)      
--&&t; Index Scan usin& "ecom_input_id_idx" on ecom_input  (cost=0.29..8.31 rows=1 width=853)
  

2. После создания индекса с несколькими столбцами в одной таблице :

 CREATE INDEX idx_ecom_input ON ecom_input (ecom_id, sku_supplier);
  

Попробуйте :

 EXPLAIN SELECT * FROM ecom_input WHERE ecom_id = 22 AND sku_supplier = 'MATHILDEJAS';
  

У меня хорошая производительность по затратам:

 --&&t; Index Scan usin& idx_ecom_input on ecom_input  (cost=0.41..8.43 rows=1 width=853)
  

Небольшая потеря производительности при использовании только WHERE sku_supplier = 'MATHILDEJAS'; :

 --&&t; Index Scan usin& idx_ecom_input on ecom_input  (cost=0.41..1044.64 rows=1 width=853)
  

Но при использовании только WHERE ecom_id = 22; :

 --&&t; Bitmap Heap Scan on ecom_input  (cost=5.58..547.25 rows=150 width=853)
      Recheck Cond: (ecom_id = 22)
        -&&t;  Bitmap Index Scan on idx_ecom_input  (cost=0.00..5.54 rows=150 width=0)
                Index Cond: (ecom_id = 22)
  

Почему оптимизатор использует сканирование кучи растровых изображений при использовании только ecom_id в предложении WHERE, но не при использовании sku_supplier в предложении WHERE ? Есть 150 строк, где ecom_id = 22, но только 1 строка, где sku_supplier = ‘MATHILDEJAS’, в этом причина?

3. Обычно мы используем JOIN для столбца ‘id’ наших таблиц (которые являются ПЕРВИЧНЫМИ КЛЮЧАМИ). Используется ли индекс во время операций объединения? Если да, является ли хорошей практикой всегда ОБЪЕДИНЯТЬСЯ по ПЕРВИЧНОМУ КЛЮЧУ?

4. В какой момент (приблизительно) мы можем увидеть реальную разницу в производительности при запросе с использованием индекса, а когда НЕТ? Мы используем облачные базы данных, и даже если сеть хорошая, переход сервер-клиент туда и обратно через Интернет занимает больше времени.

Exemple :

 EXPLAIN ANALYZE SELECT * FROM ecom_input WHERE sku_supplier = 'MATHILDEJAS' AND ecom_id = 22;
  

С помощью индекса :

 "Index Scan usin& idx_ecom_input on ecom_input  (cost=0.41..8.43 rows=1 width=853) (actual time=0.017..0.018 rows=1 loops=1)"
"Index Cond: ((ecom_id = 22) AND ((sku_supplier)::text = 'MATHILDEJAS'::text))"
"Plannin& time: 0.086 ms"
"Execution time: 0.034 ms"
  

Без индекса :

 "Seq Scan on ecom_input  (cost=0.00..10034.43 rows=1 width=853) (actual time=0.006..13.555 rows=1 loops=1)"
"Filter: (((sku_supplier)::text = 'MATHILDEJAS'::text) AND (ecom_id = 22))"
"Rows Removed by Filter: 40561"
"Plannin& time: 0.097 ms"
"Execution time: 13.572 ms"
  

В общей сложности мы получаем 13 мс. Для передачи этих запросов на сервер и обратно требуется до 250-700 мс. На самом деле это не влияет на таблицу с 40 тысячами записей. Знаете ли вы, сколько записей и индексов было бы полезно?