Changes between Version 29 and Version 30 of OtherTopics

Timestamp:

06/24/26 02:33:09 (33 hours ago)

Author:

221181

Comment:

--

OtherTopics

@@ -271 +271 @@
 }}}
 
-==== 1.1. Без индекс ====
-WHERE s.date_time >= Кога во базата има илјадници продажби, за да се најде само последната 1 година потребен е индекс по датум. Во спротивно, ќе се проверуваат податоците од 5 години еден по еден.
+==== 1. Предложени индекси ====
+За да се забрза филтрирањето на датумите и поврзувањето на табелите, предложени се следниве индекси:
+{{{
+CREATE INDEX idx_sale_date_time ON stock_management.sale(date_time DESC);
+CREATE INDEX idx_sale_warehouse_id ON stock_management.sale(warehouse_id);
+CREATE INDEX idx_product_supplier_id ON stock_management.product(supplier_id);
+}}}
+
+==== 2. Анализа пред креирање на индексот (Без индекс) ====
 
 {{{
@@ -375 +382 @@
 '''Времетраење: 7656.576 ms'''
 
-'''Анализа:''' Многу бавно.
-
-==== 1.2. Со индекс ====
-
-За да се забрзаат прашањата со временски опсег (WHERE date_time > ...)
-
-'''Применет индекс:'''
-{{{
-CREATE INDEX idx_sale_date_time ON stock_management.sale(date_time DESC);
-}}}
-
-Индекси на Foreign Key за подобрување на перформансите на JOIN
-
-'''Применет индекс:'''
-{{{
-CREATE INDEX idx_sale_warehouse_id ON stock_management.sale(warehouse_id);
-CREATE INDEX idx_product_supplier_id ON stock_management.product(supplier_id);
-}}}
+==== 3. Анализа по креирање на индексот (Со индекс) ====
 
 {{{
@@ -479 +469 @@
 '''Времетраење: 4630.112 ms'''
 
-'''Анализа:''' По добро.
+==== 4. Дали индексот навистина се користи во планот за извршување? ====
+Да. EXPLAIN планот по креирањето експлицитно го прикажува користењето на Bitmap Index Scan on idx_sale_date_time. Наместо да прави Seq Scan (читање на целата табела) за да ги најде соодветните датуми како претходно, системот сега директно го користи индексот за брзо лоцирање на точните блокови на податоци што одговараат на условот за последните 12 месеци.
+
+==== 5. Заклучок за перформансите ====
+Времето на извршување се намали значително од ~7656 ms на ~4630 ms (намалување за скоро 40%). За разлика од првото сценарио каде немавме филтрирање, овде B-Tree индексот поставен на date_time директно ја елиминира потребата за процесирање на историските податоци (постари од една година), што резултира со огромен перформансен скок кој ќе станува све позначаен како што расте базата на податоци.