Changes between Version 69 and Version 70 of QueryOptimization


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

--

Legend:

Unmodified
Added
Removed
Modified
  • QueryOptimization

    v69 v70  
    15391539}}}
    15401540
    1541 ==== Без индекс:
     1541==== 1. Примарен филтер:
     1542
     1543Примарен филтер за овој поглед е `is_available = TRUE` во комбинација со `event_id`. Ова е најфреквентниот прашалник на платформата, бидејќи секој корисник што прегледува настан сака да знае кои седишта се слободни за продажба.
     1544
     1545==== 2. Случај на употреба:
     1546
     1547Овој поглед го претставува инвентарот во реално време. Поради големиот волумен на податоци во табелата `Ticket` (околу 30 милиони записи), секое доцнење тука може да доведе до Race Condition (двајца корисници да го видат истото седиште како слободно). Ефикасноста тука не е само прашање на UX, туку и на интегритет на продажбата.
     1548
     1549==== 3. Иницијално време:
     1550
     1551Иницијалното време за извршување изнесува 948.253 ms. Иако е под една секунда, ова е премногу бавно за систем со голем сообраќај каде илјадници корисници истовремено го повикуваат овој поглед.
     1552
     1553==== 4. Анализа на планот на извршување (без индекси):
     1554
     1555Најголем проблем е '''Merge Join''' операцијата која мора да ги спои табелите `Ticket` и `Seat`. Бидејќи базата нема соодветен индекс за достапните карти, таа троши многу ресурси на сортирање и пребарување низ милиони редови.
     1556
     1557Се појавуваат високи трошоци за читање од диск бидејќи базата не може веднаш да ги „отфрли“ веќе продадените билети.
    15421558
    15431559 * '''SELECT'''
     
    16311647За овој поглед се трошат 948.13 ms бидејќи базата мора да пребарува низ 30 милиони записи. Овој процес вклучува скапи операции со трошок од 27455.75, каде се читаат милиони непотребни записи од дискот. Заради ова, потребен е индекс кој ќе ги издвои само достапните билети и ќе го елиминира ваквото чекање.
    16321648
    1633 ==== Оптимизација:
     1649==== 5. Оптимизација и индексирање:
     1650
     1651За овој поглед го воведуваме специјализираниот делумен индекс:
     1652
     1653 * `idx_ticket_is_available_true`: Овој индекс ги содржи само редовите каде `is_available` е TRUE. Наместо да пребарува низ 30 милиони записи, базата сега гледа само во мал подмножество (на пр. 50,000 слободни билети).
     1654
     1655 * idx_ticket_event_happening_id: Овозможува моментално поврзување на билетите со конкретниот настан.
     1656
     1657 * idx_ticket_seat_id: Го забрзува поврзувањето со табелата `Seat` за да се прикажат броевите на седиштата и секторите.
    16341658
    16351659{{{
     
    16461670}}}
    16471671
    1648 ==== Со индекс:
     1672==== 6. Резултат по оптимизација:
     1673
     1674Времето на извршување падна на 3.882 ms.
     1675
     1676Подобрување: Забрзување од околу 245 пати.
     1677
     1678Времето на '''INSERT''' и '''UPDATE''' операциите останува минимално, што потврдува дека делумните индекси се многу „лесни“ за одржување бидејќи не се ажурираат при секоја промена, туку само кога се менува статусот на достапност.
    16491679
    16501680 * '''SELECT'''