Changes between Version 70 and Version 71 of QueryOptimization


Ignore:
Timestamp:
05/17/26 14:10:12 (9 days ago)
Author:
231027
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • QueryOptimization

    v70 v71  
    103103||Execution Time: 23.621 ms||
    104104
    105 Погледот е бавен поради комплексни врски помеѓи четири табели што резултира со време од 3.2 s. Индексите на `performer_id` и `event_id` го елиминираат целосното скенирање на табелите и овозможуваат инстантно поврзување на изведувачите со нивните настани.
    106 
    107105==== 5. Оптимизација и индексирање:
    108106
    … …  
    305303||  Timing: Generation 0.405 ms (Deform 0.071 ms), Inlining 0.000 ms, Optimization 0.595 ms, Emission 6.566 ms, Total 7.565 ms||
    306304||Execution Time: 312239.424 ms||
    307 
    308 Времето за ажурирање од 312 s е неприфатливо за интеракција со мапа на седишта во реално време. Со поставување индекси на `seat_number` и `venue_id`, пребарувањето и промената на статусот на седиштата се извршуваат за милисекунди наместо за неколку минути.
    309305
    310306==== 5. Оптимизација и индексирање:
    … …  
    524520||Execution Time: 0.157 ms||
    525521
    526 Приказот на историјата на билети трае 251.9 s, што го блокира корисничкиот профил. Индексот на `user_id` овозможува базата веднаш да ги лоцира билетите на конкретниот корисник без да ги пребарува сите трансакции во системот.
    527 
    528522==== 5. Оптимизација и индексирање:
    529523
    … …  
    749743||Execution Time: 0.218 ms||
    750744
    751 Без индекси, секое пребарување на оценките по корисник предизвикува непотребно оптоварување на меморијата преку '''Seq Scan'''. Индексирањето на `user_id` и `event_happening_id` обезбедува брза филтрација и поврзување на рејтинзите со соодветните термини на настаните.
    752 
    753745==== 5. Оптимизација и индексирање:
    754746
    … …  
    951943||Planning Time: 0.136 ms||
    952944||Execution Time: 0.500 ms||
    953 
    954 Пресметката на просечни оценки бара постојано агрегирање на податоци, што е бавно при секој нов приказ. Композитен индекс на (`event_happening_id`, `rating`) овозможува математичките операции да се вршат директно врз индексот, забрзувајќи го приказот на почетната страна.
    955945
    956946==== 5. Оптимизација и индексирање:
    … …  
    11811171||Execution Time: 0.364 ms||
    11821172
    1183 Овој поглед има критично време на извршување од над 5 минути поради обработка на милиони трансакции. Индексите на `ticket_id` го намалуваат времето за 99%, овозможувајќи моментален преглед на приходите и рефундациите за секој настан.
    1184 
    11851173==== 5. Оптимизација и индексирање:
    11861174
    … …  
    14121400||Execution Time: 0.662 ms||
    14131401
    1414 Времето на извршување е релативно ниско, но базата троши 4.258 ms само на планирање на секој поединечен запис. Бидејќи редовите не се подредени по време, системот мора да врши постојани споредби за секој настан. Заради ова, потребен е индекс кој ќе овозможи моментално лоцирање на идните настани без пребарување на целата табела.
    1415 
    14161402==== 5. Оптимизација и индексирање:
    14171403
    … …  
    16451631||Execution Time: 0.393 ms||
    16461632
    1647 За овој поглед се трошат 948.13 ms бидејќи базата мора да пребарува низ 30 милиони записи. Овој процес вклучува скапи операции со трошок од 27455.75, каде се читаат милиони непотребни записи од дискот. Заради ова, потребен е индекс кој ќе ги издвои само достапните билети и ќе го елиминира ваквото чекање.
    1648 
    16491633==== 5. Оптимизација и индексирање:
    16501634