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

• #2213 nevemfel senior tag Panhard #2212

  Új Válasz 2023-03-31 20:05:49 #2213

  Ú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

  

  nevemfel

  senior tag

  válasz Panhard #2212 üzenetére

  Ha 5.7 vagy frissebb verziójú a mysql, próbáld ki generált mezővel, és arra rakott indexszel:

  ALTER TABLE `teszt` ADD (
`gpsdate` DATE GENERATED ALWAYS AS (CAST(`gpsdatetime` as DATE)) STORED,
KEY `gpsdateindex` (`gpsdate`)
)

• #2211 martonx veterán Panhard #2210

  Új Válasz 2023-03-30 11:38:27 #2211

  Ú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

  

  martonx

  veterán

  válasz Panhard #2210 üzenetére

  gyanítom a cast-olás lassít még rajta, bár nem hiszem, hogy ezen drasztikusan tudnál még gyorsítani. Ha ennyire kritikus a sebesség, akkor érdemes lenne eleve úgy tárolnod az adatokat, hogy ne kelljen castolni.
  Vagy ha kell datetime-ként is és date-ként is, lehet kipróbálnám, hogy mindkét módon redundánsan letárolnám ugyanazt az adatot.
  Másik lehetőség, hogy tárold le ezt az adatot napokra groupolva is, ez persze megint redundáns tárolást jelent, de biztos, hogy gyorsabb lesz az így előre groupolt adatokat lekérdezni, mint on-the-fly groupolni sok millió adatot.

• #2148 instantwater addikt Panhard #2147

  Új Válasz 2021-02-05 00:37:05 #2148

  Ú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

  

  instantwater

  addikt

  válasz Panhard #2147 üzenetére

  Én a SELECT DISTINCT környékén néznék körül.

• #2146 instantwater addikt Panhard #2145

  Új Válasz 2021-02-04 22:57:00 #2146

  Ú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

  

  instantwater

  addikt

  válasz Panhard #2145 üzenetére

  Kérlek használj parameter bindinget, mert így sérülékeny a rendszer SQL injectionnel szemben.
  Bármi SQL beküldhető a paraméterben és némi okoskodás után csúnya dolgokat lehet művelni.

  Sima indexet állíts be, ne unique indexet.
  Egy időbélyeget nincs értelme unique indexbe tenni, hiszen egy adott pillanatban történhetett több minden amit el akarsz tárolni, és ha unique az index akkor hibát fogsz kapni.

  Korábban írtad, hogy a dátum meződ a primary key.
  Erre van valami ok?
  Primary key általában egy auto increment mező, az user email címe, uuid vagy hasonló szokott lenni.

• #2144 instantwater addikt Panhard #2143

  Új Válasz 2021-02-04 21:37:06 #2144

  Ú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

  

  instantwater

  addikt

  válasz Panhard #2143 üzenetére

  Örülök, hogy sikerült.
  Valóban kissé pseudocode amit írtam de végül sikerült felhasználnod.

  A castolás és stringhez hasonlítás egyenlőség vizsgálattal vagy LIKEval gátolja az indexek használatát.

  Végül mi lett a megoldás pontos szintaktikával?
  Hátha másnak hasznos lesz.

• #2142 Panhard tag Panhard #2141

  Új Válasz 2021-02-04 18:30:35 #2142

  Ú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

  

  Panhard

  tag

  válasz Panhard #2141 üzenetére

  A DATETIME oszlop PRIMARY KEY-nek van indexelve.

  Kétféleképpen kérdeztem le, egyiknél sem használja az indexelést:
  SELECT * FROM tabla where CAST(DATETIME AS DATE) = '2020-10-15'
  SELECT * FROM tabla where DATETIME like '2020-10-15 %'

• #2140 instantwater addikt Panhard #2139

  Új Válasz 2021-02-04 17:22:03 #2140

  Ú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

  

  instantwater

  addikt

  válasz Panhard #2139 üzenetére

  column BETWEEN dátum 00:00:00 AND dátum 23:59:59 ?

  De MySQL 8 ban már vannak functional indexek, amikkel indexelni tudod a formázott tartalmat.

  Vagy akár csinálhatsz egy virtuális generált oszlopot is amit lehet indexelni.

  Épp ilyesmivel dolgozom. Fun

• #2107 SunyaMacs aktív tag Panhard #2106

  Új Válasz 2020-09-19 16:31:58 #2107

  Ú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

  

  SunyaMacs

  aktív tag

  válasz Panhard #2106 üzenetére

  UPDATE idotabla t
SET t.timestamp = FLOOR(UNIX_TIMESTAMP(CONCAT(t.date, " ", t.time)))

• #2020 martonx veterán Panhard #2019

  Új Válasz 2018-11-10 14:46:30 #2020

  Ú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

  

  martonx

  veterán

  válasz Panhard #2019 üzenetére

  Részben erre gondolok, részben meg arra, hogy könyörgöm olvass már utána, hogy mit csinálsz, és mi az anyám kínja az az sql injection, és hogy hogy illik ez ellen védekezni PHP esetén.

• #2018 martonx veterán Panhard #2017

  Új Válasz 2018-11-10 09:40:43 #2018

  Ú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

  

  martonx

  veterán

  válasz Panhard #2017 üzenetére

  Egyrészt ez így tipikusan sql injection problémás kód vagy inkább

  Másrészt, ha YEAR(date) = 2018 helyett YEAR(date) IN (2018, 2017, 2016 ... ) szintaktikát használsz, akkor máris működik, amit szeretnél. Ehhez nyilván majd egy kis PHP kód módosítás is kelleni fog, hogy ilyen kinézetre hozd a GET-ben kapott paramétereket.

• #1812 sonar addikt Panhard #1811

  Új Válasz 2016-10-19 13:56:25 #1812

  Ú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

  

  sonar

  addikt

  válasz Panhard #1811 üzenetére

  mondjuk így
  SELECT * FROM (
SELECT * FROM tabla ORDER BY datum DESC, ido DESC LIMIT 100
)sub
ORDER BY datum ASC

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