- Apple iPhone 16 Pro - rutinvizsga
- iPhone topik
- Honor Magic5 Pro - kamerák bűvöletében
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Keretmentesít a Galaxy S25 FE
- Apple Watch Ultra - első nekifutás
- Honor 200 - kétszázért pont jó lenne
- Kiborult a Nothing Phone (3) pletykakosara
- Az Oppo Find X8 Ultra lett a legvékonyabb kameramobil
- Magisk
Új hozzászólás Aktív témák
-
#2231
martonx
veterán
hellsing71
#2229
martonx
veterán
válasz
hellsing71
#2229
üzenetére
Rosszul állsz hozzá. Mivel lapozást használsz, soha nem kell a teljes táblát listáznod. És biztosra veszem, hogy kettő lekérdezés elég.
Select akármi from tábla
Where feltételek (nyilván az alap eset, amikor még where sincs) queryEz az alap lekérdezésed, ami csak egy alap, de ilyen formában sose kell lefuttatnod.
1. lekérdezés: alap query count-ja, azaz maxmimum hány sornyi adatod van (ez is erőforrásigényes tud lenni, de amit mondtál 250k adatsor nudli, majd 6 milliárd sornál ráérhetsz ezen aggodni)
2. lekérdezés: alap lekérdezés az aktuális page-nek megfelelően (pl. 20-dik pagenek megfelelő 10 sor)azaz sose fogsz a megjelenített sorok számánál (pl. 10/20/50/100) többet elkérni a db-től. Hiszen pont erre való a pagelés.
-
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. -
martonx
veterán
a régi jó hányadék MySQL Ez 2012 óta ismert feature, nem bug. MySQL Bugs: #64197: "Impossible WHERE noticed after reading const tables" messageCsak szar az üzenet, ha jól értem nincs hiba, csak valószínűleg nem hozott találatot a WHERE.
Talán ideje lenne a garázs szolgáltatókat örökre elfelejteni a vicc MySQL-jeikkel együtt, és a felhőbe menni?
-
martonx
veterán
válasz
mlaci01
#2194
üzenetére
Áhá, csak kezded kinyögni, hogy mi is a konkrét problémád.
Én a helyedben a következő lépéseket tenném:
1. megcsinálnám az új táblát üresen
2. írnék egy adat migráló scriptet (te tudod milyen programnyelv áll hozzád a legközelebb ehhez, akár SQL is lehet egy kurzorral), ami minden egyes soron végigmegy, az azokban talált adatokat összefűzi az új struktúrának megfelelően, majd azt beleírja az új táblába
3. a régi táblát átnevezném régitáblanév_backup-ra
4. az új táblát átnevezném a régi tábla nevére
5. amikor látom, hogy minden szép és jó, akkor elpusztítanám a backup táblát (ez időben akár heteket, hónapokat, ha nem zavar ott a backup tábla akár éveket is jelenthet ). -
#2181
martonx
veterán
Harcipocok84
#2180
martonx
veterán
válasz
Harcipocok84
#2180
üzenetére
Szia, ilyen string konkatenációval nem kellene értéket adnod az SQL-nek, mert ez az SQL injection melegágya.
1. Ettől eltekintve az elképzelés jó, és működhet.
2. hibát fog dobni -
martonx
veterán
válasz
Dißnäëß
#2172
üzenetére
A MySql cache-e nagyon nem egyenlő egy Redis-el. Ettől még simán lehet felesleges a redis.
Nekem már önmagában az is fura, hogy ha a DB bőven belefér 10-30 gigába, akkor ehhez minek cluster?
Szóval fingom sincs, hogy mi a célotok, milyen egyéb cachelési stratégiát használtok rendszer szinten, egyáltalán mennyi request fog beesni percenként
Nem mindegy, hogy 20 vagy 2 millió. Ehhez képest a DB mérete kb. lényegtelen. -
martonx
veterán
válasz
laracroft
#2079
üzenetére
Közben rájöttem, hogy a Dbfiddle sokkal jobb, mint az sqlfiddle, ami konkrétan nem működik.
MySql 8-al csináltam meg, ami már lassan felnő a normális adatbáziskezelők szintjére (ismeri a window függvényeket, és a common table expression-öket).Szóval itt a megoldásom, remélem jól értettem, és ezt szeretted volna: [link]
-
#2063
martonx
veterán
digitalson78
#2062
martonx
veterán
válasz
digitalson78
#2062
üzenetére
Google Sheet, Office 365-ös online excel teljesen jók erre. Legalábbis kezdésnek, egyáltalán kipróbálni, hogy működik-e a koncepció.
Aztán majd, ha esetleg kezd szűkös lenni a mögöttes Google Sheet / Online Excel, akkor majd valóban érdemes lehet egy saját webes admin felületre átültetni, saját DB-vel. -
martonx
veterán
-
martonx
veterán
Én még csak alkalmankent se, pont az ilyen peldakodok a nagyvilágból miatt, amiktől sírni tudnék. Hiszen paramezerett querynel nem kellene bohockodni extra validaciokkal, és csak azt validalni, amit tenyleg kell, hogy mondjuk a bejövő string az tényleg email-e, nem pedig kikapni belőle az sql injectiont okozó bármit, validacio címszó alatt. Ebből lesznek aztán a katyvasz spagetti kódok, ami ironikus módon nem a PHP mint nyelv hibája, de valahogy mégis mindig php kodokban jönnek elő ezek az allatorvosi ló esetek.
-
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.
-
martonx
veterán
Nyilván bármit meg lehet írni végtelen szarra. Ezért is írtam, hogy az egy dolog, hogy aggódunk, hogy milyen vas kell 15-20 user, meg akár több tízezer adatsor alá
Első körben azt kell elérni, hogy a programozók írják meg normálisra a rendszert, mert addig olyan kényelmes bemagyarázni a naív ügyfélnek, hogy ehhez 8 magos vas kell, meg nem elég a 16 Gb ram
Miközben normálisan megírva akár egy Celeronon 2 Gb rammal röhögve kellene futnia.
Nyilván a konkrétumok ismerete nélkül mindez csak okoskodás, de mennyi ilyet láttam már.Legutóbb olyanba futottunk bele, hogy megkeresett egy ügyfél, hogy már több programozó csapat vérzett el azon, hogy másfél millió soros adattáblában kellene keresni, mindenféle szűréssel, a szűrések kombinációjában részeredményeket mutatni az egyes elemekhez, azaz tényleg elég komplex a dolog, és senki nem tudja az egyes szűrések közötti időt 5 másodperc alá vinni a 8 magos 30Gb memóriás szerverén futtatva (miközben a szerver is vért izzad).
Mi nulláról megírtuk neki a rendszert úgy, hogy 40ms körül szórva jönnek meg a keresés eredmények, és ritkán jár 5% felett a szerver terhelés
Ezen úgy belelkesedett, hogy most íratja velünk újra az összes régi PHP - MySql-es szarját (Asp.Net Core + MSSQL-re, de az architektúra ebben a kontextusban nem is annyira érdekes). -
martonx
veterán
Még mindig nem írtál éppen semmi konkrétumot, ami alapján bullshiten kívül bármi érdemi választ lehetne neked adni
Nyilván mivel nem te írod a rendszert, nem is fogsz tudni ennél konkrétabbat kérdezni, ergo ez így parttalan.Mindenesetre annak esetleg járj utána, hogy a fejlesztők valóban jól végzik a dolgukat? Mert a 10-20 felhasználó, aminek a fele párhuzamosan használja a rendszert, nagyon kicsi számok, szinte nulla terhelést kellene, hogy okozzanak.
Hogy mi a nagy adatbázis, hidd el az is relatív. Van aki a több ezer rekordot már nagynak érzi, van aki meg milliárd rekordokkal, és TerraByte-okkal számol. -
martonx
veterán
válasz
baracsi
#1991
üzenetére
Az oké, hogy ebben a linkelt listában a Facebooktól kezdve egy csomóan benne vannak, de vajon ők tényleg MySql-t használnak out-of-the-box? Vagy az itt szereplő felhasználók döntő többsége már rég saját storage engine-el megy MySql alatt, mint pl. a Facebook is, csak épp lehet rájuk hivatkozni, hogy szegről-végről némi közük van a MySql-hez.
-
martonx
veterán
Simán lehet, de ha megtennéd, hogy pontokba szedve cáfolod (több szinten is ), nem pedig pont hogy az igazamat bizonyítod, a szimpla select, index nem használós bizonyítással? Ettől még persze nincs baj a MySql-lel móricka projektekhez simán jó, és ingyenes, de komoly enterprise üzletmenetet biztos, hogy soha nem bíznék rá. Szerintem. -
martonx
veterán
Egyrészt úgy rémlik mintha írtad volna a MySql verziót, és mintha valami elég elavult verziót használnál. Másrészt a MySql közismerten az Oracle ingyenes alternatívája, és nyilván nem véletlenül ingyenes
Ha mindenképpen az ingyen vonalon akartok mozogni akkor MariaDB vagy PostgreSql sokkal jobb választás, mint a MySql. Szerintem. -
martonx
veterán
válasz
Panthera
#1963
üzenetére
Mindenképpen érdemes latest stable-re váltani, ha már úgyis dolgozni kell vele. Viszont ez esetben picit izgi tud lenni a DB migrálás, illetve ha szarul megírt PHP használta (más komolyabb programnyelvet nem tudok elképzelni, ami MySql-re alapozna
), akkor lehet annak is lesznek bajai egy újabb MySql verzióval. -
#1927
martonx
veterán
toth_janika
#1926
martonx
veterán
válasz
toth_janika
#1926
üzenetére
-
martonx
veterán
válasz
qwertly
#1890
üzenetére
Miért kell minden gépre MySql???
Én egy gépre (a legizmosabbra) tenném fel, és tennék alá X darab adatbázist, X darab userrel, minden user csak a saját adatbázisát láthatná.
Azt az egyet belőném normálisan, minek szopni mysql telepítéssel beállítással, minden egyes gépnél? -
-
#1875
martonx
veterán
Chesterfield
#1874
martonx
veterán
válasz
Chesterfield
#1874
üzenetére
Hehe, egy sqlfiddle példa se ártana, hogy legyen hol eljátszani.
-
martonx
veterán
válasz
kezdosql
#1859
üzenetére
Így már másabb. Ekkor sem igaz, hogy a MariaDB utódja lenne a MySql-nek, párhuzamosan léteznek. MySQL-t InnoDB-vel illik használni, igaziból ez a belinkelt motor összehasonlítás kicsit fals, mert a MySQL-ben alapvetően MyISAM és InnoDB motorok vannak. Vagy már csak InnoDB van a legújabb verziókban, rég nem használtam, azt tudom, hogy a MyISAM deprecated egy jó ideje.
Az összes többi motor nem olyan könnyen átjárható, teljesen külön kell a komplett kiszolgálókat telepíteni velük. Végeredményben szerintem érdemes az InnoDB-vel kezdeni, aztán ha majd elkezd az igény specifikáltabb lenni, akkor el lehet kezdeni Oracle, MS SQL, valamilyen NoSQL, netán másik MySQL fork felé menni. -
martonx
veterán
válasz
kezdosql
#1857
üzenetére
Úristen ember. A MySQL egy relációs (hagyományos) SQL, míg a MongoDB egy no sql. Szerinted melyikben van inkább tranzakció? A kettő semmilyen szinten nem függ össze (na jó, mindkettőben lehet adatokat tárolni), egyik se elődje, utódja a másiknak.
Légyszi a baromságok kérdezése helyett egy pindurit olvass utána magadtól, hogy mit jelent a nosql és a realtional databaseMár múltkor pedzegettem, hogy nem jó helyen dolgozol, nem feltétlenül benned van a hiba, hanem a melóhelyben. Ahol ilyenek merülnek fel, onnan menekülni kellene.
-
martonx
veterán
válasz
SirRasor
#1808
üzenetére
Hi, a varchar pont abban különbözik a sima char-tól, hogy csak a ténylegesen szükséges helyet foglalja, azaz ha üres, akkor semmit nem foglal.
Másrészt a problémát, amit írtál nagyon nem így kellene megoldanod. Erre tipikusan csinálni szoktak a Tabla1-hez tartozó Tabla1Log táblát. És ebben szépen le lehet tárolni, hogy ki és mikor módosította az adott kulcsú sort. Akár csak teszel egy triggert a Tabla1-re, ami minden update-re elsül, és beteszi a log táblába a szükséges adatokat.
-
martonx
veterán
Én a helyedben a dátum mezőt módosítanám mysql-ben, hogy feleslegesen ne is tárolj perc, másodpercet (ennek mellesleg az sql engine is örülni fog). És ha minden igaz, ezzel a huszárvágással meg is oldottad a problémát
Mondjuk lehet, hogy mindegyik dátumhoz ekkor még hozzá kell adni egy napot, te ismered a használt összehasonlító logikáidat. -
martonx
veterán
válasz
csusza`
#1795
üzenetére
Mármint valóban a MySQL-hez van 30 felhasználód, vagy a MySQL-en futó rendszerben van 30 felhasználó? Mert általában magához az SQL-hez nem szokott sok felhasználó lenni. Gondolnám, hogy a MySql Workbench nem teljesen kompatibilis az ősi 5.1-es MySql-lel, és ezért jön ez a hiba.
-
#1785
martonx
veterán
Apollo17hu
#1784
martonx
veterán
válasz
Apollo17hu
#1784
üzenetére
A tökéletes példa arra, hogy miért nem így kellett volna a táblát felépíteni, hanem egy a többhöz kapcsolattal külön táblába tenni a Zone-okat.
-
martonx
veterán
válasz
laracroft
#1781
üzenetére
Tudom csak kívülről beleokoskodás valós megoldás helyett, de milyen hülyeség már, hogy Zone1-16 mezők vannak a táblában, miközben sokkal normálisabb megoldás lenne, ha egy a többhöz kapcsolatban a Zone-ok ki lennének szervezve egy külön táblába. És máris elég lenne egy group by rájuk az ilyen lekérdezésekhez
Ha pedig valahol mégis egymás mellett kellene megjeleníteni őket, akkor mehetne egy view a táblára benne egy pivot-tal. Sokkal normálisabb adatbázis szerkezet lenne.
-
#1758
martonx
veterán
fordfairlane
#1756
martonx
veterán
válasz
fordfairlane
#1756
üzenetére
Ja, hogy arra? Na, azt még soha nem használtam.
-
-
martonx
veterán
Szia!
Előre bocsátom, hogy semmi háttérinfóm nincs, így lehet, hogy az alábbiak csak okoskodásnak fognak hatni. Észrevételeim:
1. Ehhez a feladathoz ha jól tippelem ramból kb. semennyi nem kell, a 4Gb abszolút feleslegesen felülméretezettnek tűnik egy pár tíz Mbyte-os adatbázishoz. Cakkumpakk be fog férni a komplett adatbázis a memóriába.
2. CPU-ból egy négy magos vígan ki kellene, hogy tudja szolgálni mindezt. A Pentium necces lehet, és mi van például, ha megduplázódik a terhelés? Akár csak percekre?
3. Pont a fentiek miatt, ma már senki nem gondolkozik saját vas beszerzésében, hanem sokkal érdemesebb szervert bérelni valahol, leginkább mondjuk a felhőben. Így kb. egy csúszka arrébb tolásával meg tudod többszörözni az erőforrásokat, ha épp arra van szükség.
4. Nem vagyok egy nagy NoSQL rajongó, de ez tipikusan olyanfeladatnak tűnik, ahol teljesen felesleges tranzakciós SQL-t használni, egy NoSql sokkal kevesebb erőforrás használatával, sokkal nagyobb teljesítményt tudna elérni.
5. Másrészt megfontolandó, hogy tényleg jól van felépítve az adatbázisotok? Lehet, hogy nem a NoSQL a megoldás, csak alapból szar az SQL-etek architektúrája?
6. Nekem gyanús a backendetek is. Ahogy írod elég faéknek tűnik, mégis miért van szükség egy minimális adat kimenethez több SQL query-re? Lehet érdemes lenne tárolt eljárást írnotok, sql view-t használnotok, php oldalon optimalizálni a kódon, cache-elést bevezetni stb... -
-
martonx
veterán
válasz
don_peter
#1683
üzenetére
Segítettem is, sőt szerintem az én segítségem lesz a leghasznosabb, hiszen közel nulla ráhatásod van a dologra, így a szolgáltató kezében vagy, és én pont oda irányítottalak.
De ha már csak egy pici részletet is mutattál a kódodból, akkor az ember hagy tegyen finom utalást annak szakmaiatlan mivoltára. Ezen be lehet sértődni és mindent hagyni ugyanúgy (elvégre sok légy nem tévedhet), vagy pozitívan is lehet fogadni, és meg is lehet írni normálisra. -
martonx
veterán
válasz
don_peter
#1677
üzenetére
"Milyen izé, és milyen ledegradáló jelző az, hogy tákoltad.?"
Bocsi, akkor meg is van, hogy ki tákolta, össze, te. A kódot látva az a legkisebb baj, hogy miért lett most lassú. Sőt inkább azon csodálkozok, hogy miért nem volt lassú eddigDe, hogy konstruktív is legyek, tényleg nézd meg az indexeket, illetve én jelezném az üzemeltetőnek, hogy nagyságrendekkel lassabb lett az új mysql, és konfigolják be normálisan legyenek szívesek.
-
-
#1658
martonx
veterán
Peter Kiss
#1657
martonx
veterán
válasz
Peter Kiss
#1657
üzenetére
Jogos, a default mysql szerver beállítások egy kalap szart se érnek
-
martonx
veterán
válasz
laracroft
#1655
üzenetére
Nem kötözködésképpen, de nudli 800.000 sorhoz egy ennyire alap group by-hoz megkockáztatom, hogy nem kellene 1 másodperc sem. Az elég árulkodó, hogy ez a te gépeden 10 másodperc volt (hacsak nem valami P4-esen futtatod a db-t). Ha a két db séma ugyanaz, akkor szinte biztos, hogy nincs jól indexelve az adatbázis.
Én a helyetekben utána néznék. -
-
martonx
veterán
Vagy itt pl. havi 5 dollárért kapsz egy komplett linux-os szervert, amit 1 kattintással létrehozol, majd másik kattintással teszel rá LAMP-ot. Percek alatt kész tud lenni a komplett mysql-ed, szerverestől, pár admin felületes kattintással. Viszont ennek a cégnek a szerverei amerikában vannak, szóval minden innen induló mysql lekérdezésednél szép nagy ping időkkel lehet számolni.
-
martonx
veterán
Mondjuk egész konkrétan itt egy ingyenes: link
Igaz ingyenesen csak 20Mb, és minimális teljesítmény jár, de játszani így is jó. Kemény havi 10 dollárért (nettó), már 1GB-nyi adatbázisod lehet, egész vállalható tejlesítménnyel.Érdemes még szétnézni az AmazonWS-en (itt pl. 12 hónapig abszolút ingyen tudod a szolgáltatást használni), illetve amit a kolléga belinkelt Google Cloud is jó alternatíva. Nekem Azure-ban futnak az adatbázisaim, de ott nincs MySQL. Melóhelynek AWS-en futnak az adatbázisai.
Hopsz és itt a mysql hivatalos oldala a cloud szolgáltatókról
-
martonx
veterán
Ne viccelődjünk már. Manapság bármelyik felhőben kb. ingyen szerzel MySql-t, és onnan kapcsolódsz hozzá, ahonnan akarsz.
Miért, ha ma 2015-ben egy barátod azt kéri, hogy segíts már neki áramot keríteni a lakásába, akkor nem egyszerűbb beköttetni azt a helyi villamosművektől, mint elrohanni generátort vásárolni, meg nem árt hozzá egy villanyszerelő is, meg különben is mi van ha elromlik, kifogy az üzemanyag stb...
-
martonx
veterán
válasz
tzimash
#1612
üzenetére
jéhé, most vettem a fáradtságot, és helyetted megnéztem a linkelt guglizás első két találatát. Hát mit nem mond a MySql dokumentáció?
"The CHECK clause is parsed but ignored by all storage engines."
Akkor már tényleg csak a triggeres ötletem maradt, mint egyetlen működőképes alternatíva.
Vagy pedig itt van a legfőbb ideje SQL-t váltani, mert a mysql egy rakás szar. Ha ragaszkodsz az opensource-hoz, akkor a PostgreSql sokkal jobb választás. -
a régi jó hányadék MySQL 
Új hozzászólás Aktív témák
Hirdetés
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Apple iPhone 16 Pro - rutinvizsga
- Mielőbb díjat rakatnának a görögök az olcsó csomagokra az EU-ban
- OTP Bank topic
- Path of Exile (ARPG)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- DUNE médialejátszók topicja
- E-roller topik
- Építő/felújító topik
- iPhone topik
- További aktív témák...
- Lenovo Legion 5 Pro Gamer Laptop 2év garanciával (i7 13700HX, RTX 4060)
- IPhone 11 Pro max 64GB megkímélt új emelt kapacitású akku!
- Apple Pencil Pro bontatlan 1 év Apple jótállás
- Nitro ANV15-51 15.6" FHD IPS i5-13420H RTX 4060 32GB 512GB NVMe magyar vbill gar
- Apple watch Series 9 41mm cellular hibátlan 2026.02. 24. Apple jótállás
- Bomba ár! Lenovo IdeaPad V110 - i3-6GEN I 4GB I 128GB SSD I 15,6" I HDMI I Cam I W10 I Garancia!
- Lenovo Yoga Pro 9 (16IMH9) - Intel Core Ultra 9 185H, RTX 4060, 32GB, érintős ELKELT
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
- VÉGKIÁRUSÍTÁS - REFURBISHED - Lenovo ThinkPad 40AC Thunderbolt 3 docking station
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest