Changes between Version 61 and Version 62 of QueryOptimization

Timestamp:

05/17/26 13:23:40 (9 days ago)

Author:

231027

Comment:

--

QueryOptimization

@@ -33 +33 @@
 Иницијалното време за извршување на погледот изнесува 3.249s (3249ms). Ова е исклучително бавно и неприфатливо за една веб-апликација, каде што секој одзив над 500ms се смета за критичен.
 
-==== 4. Анализа на планот на извршување:
+==== 4. Анализа на планот на извршување (без индекси):
 
 Иако базата се обидува да користи постоечки '''Primary Key''' индекси, главниот проблем се јавува во спојувањето на четирите табели `Performer`, `Event_Happening_Performer`, `Event_Happening`, `Event`.
@@ -215 +215 @@
 }}}
 
-==== Без индекс:
+==== 1. Примарен филтер:
+
+Примарен филтер за овој поглед е `venue_id`. Ова е логично бидејќи корисникот или администраторот најчесто бараат преглед на седиштата за една специфична сала. Секундарен филтер е `seat_number` при проверка или промена на конкретно седиште.
+
+==== 2. Случај на употреба:
+
+Погледот се користи за прикажување на графичката мапа на седишта при процесот на резервација. Корисникот избира настан, па сала, и системот мора моментално да ја вчита структурата на салата. Бавноста тука директно влијае на продажбата на билети - ако мапата се вчитува со секунди, корисникот може да се откаже.
+
+==== 3. Иницијално време:
+
+'''SELECT''': 2.164s (2164ms)
+
+'''UPDATE''': 312.239s (околу 5.2 минути)
+Времето за '''UPDATE''' е критично. Ова значи дека ако системот треба да ажурира статус на седиште, целата база би била под огромен притисок.
+
+==== 4. Анализа на планот на извршување (без индекси):
+
+Кај '''SELECT''' операцијата, базата користи '''Parallel Index Scan''' врз табелата `Section` и троши многу време на филтрирање на редови кои не одговараат (Rows Removed by Filter: 27502).
+
+Кај '''UPDATE''' операцијата се случува најлошото сценарио: '''Seq Scan'''. Базата мора да ги прочита сите 20,753,209 редови во табелата `Seat` за да го најде седиштето со број 999999. Тоа е причината за времето од 312s.
 
  * '''SELECT'''
@@ -289 +308 @@
 Времето за ажурирање од 312 s е неприфатливо за интеракција со мапа на седишта во реално време. Со поставување индекси на `seat_number` и `venue_id`, пребарувањето и промената на статусот на седиштата се извршуваат за милисекунди наместо за неколку минути.
 
-==== Оптимизација:
+==== 5. Оптимизација и индексирање:
+
+За да се елиминира целосното скенирање на табелите, се воведуваат:
+
+ * `idx_section_venue_id`: Овозможува веднаш да се најдат само секциите што му припаѓаат на соодветната сала.
+
+ * `idx_seat_section_id`: Го забрзува поврзувањето на седиштата со нивните секции.
+
+ * `idx_seat_number`: Клучен индекс кој го претвора петминутното пребарување во инстантно пронаоѓање на седиштето.
 
 {{{
@@ -304 +331 @@
 }}}
 
-==== Со индекс:
+==== 6. Резултат по оптимизација:
+
+'''SELECT''': Намалено на 0.572ms (забрзување од ~3800 пати).
+
+'''UPDATE''': Намалено на 0.461ms.
 
  * '''SELECT'''