Changes between Version 65 and Version 66 of QueryOptimization
- Timestamp:
- 05/17/26 13:41:59 (9 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
QueryOptimization
v65 v66 31 31 ==== 3. Иницијално време: 32 32 33 Иницијалното време за извршување на погледот изнесува 3.249 s (3249ms). Ова е исклучително бавно и неприфатливо за една веб-апликација, каде што секој одзив над 500ms се смета за критичен.33 Иницијалното време за извршување на погледот изнесува 3.249 s (3249 ms). Ова е исклучително бавно и неприфатливо за една веб-апликација, каде што секој одзив над 500ms се смета за критичен. 34 34 35 35 ==== 4. Анализа на планот на извршување (без индекси): … … 37 37 Иако базата се обидува да користи постоечки '''Primary Key''' индекси, главниот проблем се јавува во спојувањето на четирите табели `Performer`, `Event_Happening_Performer`, `Event_Happening`, `Event`. 38 38 39 Најбавниот дел е кај '''Nested Loop''' операциите и проверката на '''Foreign Keys''' при '''INSERT''' (1.424 s).40 41 Времето на планирање е исто така високо (1.8 s), што укажува на комплексност во резолвирањето на релациите без соодветни патеки.39 Најбавниот дел е кај '''Nested Loop''' операциите и проверката на '''Foreign Keys''' при '''INSERT''' (1.424 s). 40 41 Времето на планирање е исто така високо (1.8 s), што укажува на комплексност во резолвирањето на релациите без соодветни патеки. 42 42 43 43 * '''SELECT''' … … 126 126 ==== 6. Резултат по оптимизација: 127 127 128 По додавањето на индексите, времето на извршување на '''SELECT''' се намали на 0.533 ms.128 По додавањето на индексите, времето на извршување на '''SELECT''' се намали на 0.533 ms. 129 129 130 130 Подобрување: Ова е забрзување од над 6000 пати. … … 225 225 ==== 3. Иницијално време: 226 226 227 '''SELECT''': 2.164 s (2164ms)228 229 '''UPDATE''': 312.239 s (околу 5.2 минути)227 '''SELECT''': 2.164 s (2164 ms) 228 229 '''UPDATE''': 312.239 s (околу 5.2 минути) 230 230 Времето за '''UPDATE''' е критично. Ова значи дека ако системот треба да ажурира статус на седиште, целата база би била под огромен притисок. 231 231 … … 234 234 Кај '''SELECT''' операцијата, базата користи '''Parallel Index Scan''' врз табелата `Section` и троши многу време на филтрирање на редови кои не одговараат (Rows Removed by Filter: 27502). 235 235 236 Кај '''UPDATE''' операцијата се случува најлошото сценарио: '''Seq Scan'''. Базата мора да ги прочита сите 20,753,209 редови во табелата `Seat` за да го најде седиштето со број 999999. Тоа е причината за времето од 312 s.236 Кај '''UPDATE''' операцијата се случува најлошото сценарио: '''Seq Scan'''. Базата мора да ги прочита сите 20,753,209 редови во табелата `Seat` за да го најде седиштето со број 999999. Тоа е причината за времето од 312 s. 237 237 238 238 * '''SELECT''' … … 333 333 ==== 6. Резултат по оптимизација: 334 334 335 '''SELECT''': Намалено на 0.572 ms (забрзување од ~3800 пати).336 337 '''UPDATE''': Намалено на 0.461 ms.335 '''SELECT''': Намалено на 0.572 ms. 336 337 '''UPDATE''': Намалено на 0.461 ms. 338 338 339 339 * '''SELECT''' … … 429 429 ==== 2. Случај на употреба: 430 430 431 Погледот се користи во делот My Ticketsна профилот на секој регистриран корисник. Ова е критична точка на интеракција; корисникот очекува веднаш да ги добие своите билети за да може да го прикаже QR-кодот при влез на настан. Секое доцнење тука предизвикува директен застој на влезните капии.431 Погледот се користи во делот '''My Tickets''' на профилот на секој регистриран корисник. Ова е критична точка на интеракција; корисникот очекува веднаш да ги добие своите билети за да може да го прикаже QR-кодот при влез на настан. Секое доцнење тука предизвикува директен застој на влезните капии. 432 432 433 433 ==== 3. Иницијално време: 434 434 435 Иницијалното време за извршување изнесува 443.784 ms. Иако ова изгледа брзо во споредба со претходните погледи, треба да се земе предвид дека во реална околина со илјадници истовремени корисници, ова време ќе ескалира и ќе ја преоптовари базата.435 Иницијалното време за извршување изнесува 443.784 ms. Иако ова изгледа брзо во споредба со претходните погледи, треба да се земе предвид дека во реална околина со илјадници истовремени корисници, ова време ќе ескалира и ќе ја преоптовари базата. 436 436 437 437 ==== Анализа на планот на извршување (без индекси): … … 441 441 * Се извршува '''Parallel Seq Scan''' врз 3.2 милиони записи. 442 442 443 * Базата троши 389 ms само за да ги прелиста сите трансакции и да ги најде оние што му припаѓаат на `user_id = 1`.443 * Базата троши 389 ms само за да ги прелиста сите трансакции и да ги најде оние што му припаѓаат на `user_id = 1`. 444 444 445 445 * '''SELECT''' … … 554 554 ==== 6. Резултат по оптимизација: 555 555 556 Времето по оптимизација остана речиси идентично (450.880 ms).556 Времето по оптимизација остана речиси идентично (450.880 ms). 557 557 558 558 Планот покажува дека базата се уште избира '''Parallel Seq Scan''' наместо новокреираниот индекс. 559 559 560 Сепак, кај '''INSERT''' и '''UPDATE''' операциите се гледа стабилност и екстремна брзина (под 1 ms), што потврдува дека индексите се правилно поставени за интегритетот на податоците.560 Сепак, кај '''INSERT''' и '''UPDATE''' операциите се гледа стабилност и екстремна брзина (под 1 ms), што потврдува дека индексите се правилно поставени за интегритетот на податоците. 561 561 562 562 * '''SELECT''' … … 673 673 ==== 3. Иницијално време: 674 674 675 Иницијалното време за извршување е многу ниско (0.187 ms). Ова се должи на фактот што табелата `Event_Happening_Rating` е релативно мала (околу 17,800 редови), па базата може многу брзо да ја процесира дури и без екстремна оптимизација.675 Иницијалното време за извршување е многу ниско (0.187 ms). Ова се должи на фактот што табелата `Event_Happening_Rating` е релативно мала (околу 17,800 редови), па базата може многу брзо да ја процесира дури и без екстремна оптимизација. 676 676 677 677 ==== 4. Анализа на планот на извршување (без индекси): … … 771 771 ==== 6. Резултат по оптимизација: 772 772 773 По „оптимизацијата“, времето на '''SELECT''' се зголемило на 359.600 ms.773 По „оптимизацијата“, времето на '''SELECT''' се зголемило на 359.600 ms. 774 774 775 775 Анализа на аномалијата: Планот покажува дека базата во овој случај одбрала '''Seq Scan''' наместо '''Index Scan'''.
