Changes between Version 62 and Version 63 of QueryOptimization

Timestamp:

05/17/26 13:31:46 (9 days ago)

Author:

231027

Comment:

--

QueryOptimization

@@ -423 +423 @@
 }}}
 
-==== Без индекс:
+==== 1. Примарен филтер:
+
+Примарен филтер за овој поглед е `user_id`. Ова е најчестото сценарио бидејќи погледот служи за корисникот да ја види сопствената историја на купени билети и нивниот статус (дали се рефундирани или не).
+
+==== 2. Случај на употреба:
+
+Погледот се користи во делот My Tickets на профилот на секој регистриран корисник. Ова е критична точка на интеракција; корисникот очекува веднаш да ги добие своите билети за да може да го прикаже QR-кодот при влез на настан. Секое доцнење тука предизвикува директен застој на влезните капии.
+
+==== 3. Иницијално време:
+
+Иницијалното време за извршување изнесува 443.784ms. Иако ова изгледа брзо во споредба со претходните погледи, треба да се земе предвид дека во реална околина со илјадници истовремени корисници, ова време ќе ескалира и ќе ја преоптовари базата.
+
+==== Анализа на планот на извршување (без индекси):
+
+Главниот проблем е идентификуван кај табелата `Ticket_Purchase`:
+
+ * Се извршува '''Parallel Seq Scan''' врз 3.2 милиони записи.
+
+ * Базата троши 389ms само за да ги прелиста сите трансакции и да ги најде оние што му припаѓаат на `user_id = 1`.
 
  * '''SELECT'''
@@ -508 +526 @@
 Приказот на историјата на билети трае 251.9 s, што го блокира корисничкиот профил. Индексот на `user_id` овозможува базата веднаш да ги лоцира билетите на конкретниот корисник без да ги пребарува сите трансакции во системот.
 
-==== Оптимизација:
+==== 5. Оптимизација и индексирање:
+
+Со цел да се избегне целосното скенирање, се предлагаат следните индекси:
+
+ * `idx_ticket_purchase_user_id`: За директен пристап до билетите на корисникот.
+
+ * `idx_ticket_refund_purchase_id`: За побрзо извршување на '''LEFT JOIN''' операцијата со табелата за рефундации.
+
+ * `idx_ticket_purchase_ticket_id` и `idx_event_happening_event_id`: За побрзо поврзување на релациите.
 
 {{{
@@ -526 +552 @@
 }}}
 
-==== Со индекс:
+==== 6. Резултат по оптимизација:
+
+Времето по оптимизација остана речиси идентично (450.880 ms).
+
+Планот покажува дека базата се уште избира '''Parallel Seq Scan''' наместо новокреираниот индекс.
+
+Сепак, кај '''INSERT''' и '''UPDATE''' операциите се гледа стабилност и екстремна брзина (под 1ms), што потврдува дека индексите се правилно поставени за интегритетот на податоците.
 
  * '''SELECT'''