Új hozzászólás Aktív témák

• #20901 dabadab titán inf3rno #20898

  Új Válasz 2025-10-04 21:12:57 #20901

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dabadab

  titán

  válasz inf3rno #20898 üzenetére

  Teljesen tippre az első tűnik a gyorsabbnak, de 100 értéknél tulajdonképpen mindegy is.

  Ha viszont tényleg le akarod mérni, hogy a te konkrét adatbázisodnál, a te adataiddal melyik a gyorsabb, akkor meg kapcsold be a slowlogot (egy long_query_time=0 után minden query slow querynek fog számítani) és nézd meg.

• #20899 coco2 őstag inf3rno #20898

  Új Válasz 2025-10-04 20:57:02 #20899

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  coco2

  őstag

  válasz inf3rno #20898 üzenetére

  A use case-edet nem igazán sikerült leírni.

  Ha adatok vizsgálata nélkül kiírhatnál, akkor csak kiírnál. Viszont ott van a (3), ami miatt azt feltételezem, vizsgálnod kell előbb. És azt viszont kihagytad a számítás egészéből. Így egy kicsit nehézkes tippet adni.

  Az (1) esetében konkrétan hogyan gondoltad kiválasztani, hogy melyik értékek változtak ? Pláne hogy teljesítményen filozol, bizonyos környezetekben egyáltalán nem kicsike probléma az.

  A (2) esete legalább érthető, felülvágnál valamit kérdés nélkül, és ha fix értékek vannak, én is azt csinálnám. Egybe írni a halom insert/update-et, aztán had szóljon. Viszont van egy tippem, hogy nem egészen úgy van az.

  A (3) esetében gondjaid lehenek egy write-heavy környezetben. Az adatok már akkor mások lehetnek, mire hozzád megérkeztek, ha meg nem fogod tranzakcióval. Ha meg megfogod, azzal blokkolsz minden mást, ami ugyan ahhoz akarna hozzáférni. Teljesítmény szempontjából nem igazán előnyös.

  És persze az a teljesítményoptimalizálás használni kell, vagy csak kirakatba tenni díszelegni?

Új hozzászólás Aktív témák