nagy MySQL tábla gyorsitása

 ( Robika88 | 2017. január 31., kedd - 15:38 )

Sziasztok

Adott a 500.000 sort tartalmazó tábla.(150Mb) InnoDb, valamint MyISAM motorral próbálkoztam alatta. Állítottam indexet is a fontosabb oszlopokra.
Kérdés: Hogyan tudnám meggyorsítani a selecteket, mert elég lassú még.
Maga a teljes adatbázis 50sec alatt íródik ki. (ssd a háttértár, ddr3 memo)
where select időszakra 5 sec.
Kicsit nehéz így ajax lekérdezéseket futtatnom, pl ha billentyű felemelésre mindig kérdezést indítanék.
Ötletetek van rá?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Két út van: vagy meg tudod úgy írni a selecteket, hogy ne az egész adatbázist kelljen végigtúrni, vagy memóriában kell tartani az egész adatbázist (persze ebben az esetben meg cpu fog kelleni vastagon).

Mutass egy select példát! (Úgy könnyebb)

subs

ajaxot 500e rekordra?
inkabb at kellene alakitani a rendszert

Ráadásul minden billentyűleütés után...

Az ilyet úgy szokás megoldani, hogy a keyUp után beteszel egy timeout-ot, azaz pl vár 2 másodpercet mielőtt elindítja az ajax lekérdezést. Ha közben újabb keyup történik, akkor a visszaszámlálás resetelődik és újraindul.

szerintem hagyd, leirtam én is neki ezt (http://hup.hu/node/151828#comment-2061663), semmi válasz. gyakorlatilag információkat se kapunk rendesen, és több a hiba a megoldásban.

Tudom, én is valahogy így csinálnám, de a kérdező írta ezt: "ha billentyű felemelésre mindig kérdezést indítanék"

Ahogy előttem is irták, tudni kéne a SELECT-eket, oszlopok tipusa se árthat (EXPLAIN táblanév), és az indexeket is jelöld. Pár felvetés még: milyen sűrűn iródik a tábla (cache-elési lehetőségeket behatárolja, illetve az innodb vs myisam kérdésben is döntő lehet), van-e csatolva hozzá másik tábla a legkérdezésekben, milyen lehetőségeid vannak (pl. memóriában tárolás, cache-elés), mennyire kell frissnek lennie a találatoknak (elfogadható-e egy x percenkénti cache-elés), mennyire szabad a keresés (szöveges, ...), és ezek csak kiegészitő kérdések.

Ugy hangzik, mint kulcsszavas kereses, arra pedig mysql pazarlas.

Probald: https://lucene.apache.org/core/

+1, gondolom, a ... where oszlop like '%a%' jellegu query-k nem mennek jol :-) Amugy en a sphinxsearch nevu cuccot javaslom a feladatra. Szep (kb.) sql query-ket lehet neki kuldeni...

Sphinx +1.

Ha meg nem zavar a fizetős, cloud megoldás, akkor az Algolia pontosan azt tudja, ami neked kell. Villamgyors, pontosan keres, cserébe nem olcsó.

Ugyan a kérdező nem bőszavú, és nem is kaptuk meg a teljes információhalmazt, azt feltételezem, hogy nem nagyon fér bele valami fizetős szolgáltatás, sem új technológia.

500k sor ugyan SQL szinten nem sok, de ahhoz, hogy autocomplete legyen belole minden billentyuleutesre, azert talan megis.

Szerintem ez nagyban függ az index-elhetőségtől, lekérdezésektől, amit alább irt lekérdezés nem is szabadszavas, dátumra index-elve attól függően, hogy mekkora a szórás a táblában lehet, hogy ezres nagyságrend alá kerülnek a találatok, ritkán változik az adat, nem is hiszem, hogy feltétel az 1 mp alattiság, nem rokkan bele senki ilyen esetben az 1-3 mp közötti válaszidőbe sem, ezért irtam, hogy szerintem nem lesz szükség teljesen új stack-re, hamarabb lesz itt más megoldás.

+1 Évekkel ezelőtt is kiváló volt kulcsszavas keresésre.

A tábla ritkán változik. (kb 1 hónap)
nincs több táblával összerakva.(1 magában áll)
kb 15 oszlop széles, amiben 4 index oszlop van. (dátum, egyedi szám, megnevezés, mennyiség)
innodb-t próbáltam mert bedolgozta az ibdata1 fájljába a mysql, de semmivel nem volt gyorsabb mint a myisam. (a myisam pedig közvetlen másolható formátum, nem kell többi fájlt néznem ha pl menteni akarom egy gyors ftpvel. egyszerűen menet közben pl hetente lementi egy script, úgy is én frissítem a táblát maximum)

Az kizárt dolog, hogy ha a 4 indexelt mező bármelyikére rákeresel, az ne instant találatot adjon. Talán az lehet a gond, hogy nem egyezésre keresel - akkor viszont nem ilyen struktúrát kéne használni...

- jó hir, hogy ritkán változik, ez sok lehetőséget ad, erre még visszatérek, önálló tábla, ez szintén jó, gyakorlatilag bármerre el lehet vele menni

- index: select-ből kiindulva kellene index-eket késziteni, meg tudsz osztani egy explain kimenetet és azt a select-et, amit ajaxon keresztül hivsz meg?

szerk.: alább leirták, amit én is akartam: nem egyesével kell indexelni az oszlopokat, hanem egy index-et kell késziteni a select-ed alapján

- innodb és myisam közül erre ránézésre pont a myisam a gyorsabb, ha nem használsz tranzakciókat nem tudom indokolja-e még valami az innodb-t ebben az esetben

- myisam fájlok másolgatását mérlegelném, hogy szempont-e (és jó megoldás-e), ha a sebesség a fontos, akkor heti egyszer ráér akár egy mysqldump + gzip is kimenteni (én ezt javaslom, verziófüggetlen, és feldolgozható mással is), még ha innodb lenne a jó megoldás akkor is (vagy valami teljesen más mysql engine, egyéb db)

Jelenleg a select és az explain nélkül nem sokat lehet szerintem mondani, tudni kéne, hogy a select milyen feltételekkel keres, miben, milyen alapon, lehet-e a keresési feltételek alapján darabolni a táblát, ezek a gyors megoldásokat mutathatják meg, mondhatok én is olyant, hogy tartsd memóriában, vagy használj valami nem-relációs adatbázist, de ebből még nem lehet.

Mondok egy példát: abból indulok ki, hogy a keresőre azt mondtad leütésenként ajax kérést indit (tipp: használj valamilyen idle timeout-ot, és utolsó leütés után mondjuk 500 ms-al inditsd az első keresést, már sokat nyersz a sebességen), ebből gondolom, hogy szabadszavas keresés. Ha pl. ez a szabadszavas keresés egyszavas, vagy többszavas de nem variálható sorrendben, és csak a megnevezésben keres, akkor egész más index kellhet, mintha dátum tól-ig keresést is lehet csinálni.

Kiegészités: ha a keresések között vannak gyakoriak, várhatóak, akkor megfontolandó egy cache használata, ha csak egy szöveges értéked van, ami alapján létrejön a lekérdezés, akkor legalább az eredményként létrejövő json fájlt mentsd le (backend oldalon), ha csak te módositod az adatokat, akkor még csak cache elévüléssel se kell foglalkoznod (törlöd a teljes cache-t módositáskor).

- innodb és myisam közül erre ránézésre pont a myisam a gyorsabb, ha nem használsz tranzakciókat nem tudom indokolja-e még valami az innodb-t ebben az esetben

Ezzel az allitassal nagyon is vitatkoznek. Sok minden indokolja az InnoDB-t tobbek kozt h crash safe, vagy hogy a MyISAM-ot 10 eve senki sem fejleszti vagy ami itt akar nagyon is fontos lehet hogy mig MyISAM-al csak az index kerul be memoriaba, addig InnoDB-nel a Buffer Pool az indexet es magadt az adat page-ket is tarolja telhat ha a dataset elfer a Buffer Poolban akkor lenyegeben az egesz adatbazis a memoriaban van. Igy select-kor nem szukseges egyetlen IOPs sem. Es meg van tobb mas indok is. MyISAM nagyon specialis esetekben lehet csak hasznos.

Köszönet a kiigazitásért, egyrészt rosszul fogalmaztam (nem az innodb ellen akartam, csak hogy nem azzal fog drasztikus változást elérni, hogy innodb-re vált), másrészt a témában úgy néz ki túlegyszerűsitett volt a nézőpontom, pótlom, kösz!

Ha a kulcs összetett, azaz több mezőt tartalmaz, akkor NEM a résztvevő oszlopokat kell külön-külön a indexelni, hanem értelemszerűen összetett kulcsot kell készítened, az adott lekérdezés szerint. Csak ebben az esetben fog gyorsítani, de akkor nagyon. (pl. a where feltételekben szereplő mezők neveit, azonos sorrendben felsorolod index készítésekor - ha where-t használsz a kapcsoláshoz.)

Adj peldat.

Hogy keresel? egyenloseg? kisebbnagyobb?
Indexelt oszlopra legalabb?
Tabla particionalt? Lockolja neha valami?

Ez nem olyan nagy tábla. Egy rendesen indexelt lekérdezésnek pár tizedmásodperc alatt le kell futnia. Már persze, ha nincs a szerver valami más miatt nagyon leterhelve.

Ahogy a többiek is írták, explain select ... kimenete kéne. Anélkül nem igen lehet tanácsot adni.
Innodb buffer beállítást is érdemes megnézni. Cache sokat segíthet az ilyen statikus táblák gyakori elérésénél.

Milyen Cache-re gondolsz itt?

Memcached, redis stb. Gondolom

[Feliratkozás]

Szia,

Tehat ami kell hogy barki is ertelmes valaszt tudjon adni.

1) SHOW CREATE TABLE `tablaname`\G
2) EXPLAIN `QUERY`\G
3) FLUSH STATUS;
Majd futtasd le a queryt;
SHOW SESSION STATUS LIKE 'handler_%';
4) MySQL verzio.
5) plusz meg egy my.cnf sem artana vagy `SHOW GLOBAL VARIABLES` kimenet.

udv.

CREATE TABLE `mega_ar84` (
`szamla` varchar(20) COLLATE utf8_hungarian_ci DEFAULT NULL,
`szamlatipusa` char(10) COLLATE utf8_hungarian_ci DEFAULT NULL,
`bizdate` date DEFAULT NULL,
`pkod` char(12) COLLATE utf8_hungarian_ci DEFAULT NULL,
`teljdate` date DEFAULT NULL,
`cikksz` int(10) DEFAULT NULL,
`cikkmegnevez` char(250) COLLATE utf8_hungarian_ci DEFAULT NULL,
`szlame` char(10) COLLATE utf8_hungarian_ci DEFAULT NULL,
`m1` decimal(10,3) DEFAULT NULL,
`me1` char(10) COLLATE utf8_hungarian_ci DEFAULT NULL,
`m2` decimal(10,3) DEFAULT NULL,
`me2` char(10) COLLATE utf8_hungarian_ci DEFAULT NULL,
`nettoft` int(20) DEFAULT NULL,
`partnerorszagkod` char(12) CHARACTER SET latin2 COLLATE latin2_hungarian_ci DEFAULT NULL,
KEY `szamlak` (`szamla`,`bizdate`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_hungarian_ci

query= SELECT szamla,teljdate FROM mega_ar84 WHERE teljdate>='2016-12-01' AND teljdate<='2016-12-31'GROUP BY szamla,teljdate

Futási idő 2 sec

egy SELECT * FROM mega_ar84 limit 1000 (total 0,036sec)
egy SELECT * FROM mega_ar84 (exec 0,003 sec , total 0,037)

MySQL kliens verzió: 5.1.41

nem lehet, hogy maga az eredmény gyors, csak a kiíratás lassú?

SELECT szamla,teljdate FROM mega_ar84 WHERE teljdate>='2016-12-01' AND teljdate<='2016-12-31'GROUP BY szamla,teljdate
helyett legyen
SELECT szamla,teljdate FROM mega_ar84 WHERE teljdate BETWEEN '2016-12-01' AND '2016-12-31' GROUP BY szamla,teljdate

Látom, nincs index a teljdate-re...Legyen index a teljdate-re vagy teljdate+szalma.

Explainben (EXPLAIN SELECT...) azt kell látni, hogy key_using, where const.

"Látom, nincs index a teljdate-re...Legyen index a teljdate-re vagy teljdate+szalma."

+1

Egyébként NAGYON rosszul tervezett tábla, de ez a kérdést nem befolyásolja. Csak a jövőt...

Szerintem m ár az sokat dobhatna a sebességen, ha az első varchar(20) átváltozna char(20)-ra.

Semmit nem dob 500e sornál, sem tárhelyben, sem memóriában.

Nem teljesen mindegy, hogy egy rekord adott "címek" többszörösén kezdődik a fájlban, vagy a varchar miatt akárhol.

[Elméleti vita ON]
Knuth féle könyv szerint igen, de a valóságban már nem Texas Instruments zsebszámológépeken futnak a c++ programok. Lassan az SSD cache-ébe is belefér az adatbázis egésze.
[Elméleti vita OFF]

Értsd: Nem baj, ha nem optimális a program, majd erősebb vasat tolunk alá.

Szerintem fordítva van. Azzal, hogy egyre inkább fogyasztás alapon árazott kapacitást veszünk, a műveletekhez igényelt órajelciklusok száma fontosabb, mint valaha.

Üdv,
Marci

De az egy vagy kétirányba láncolt listák elméleti eltérései már rég túlhaladottak. Igen, régen számított, hogy byte vagy int16... de amióta compilert nélkülőző script nyelvekkel is nagy teljesítmény érhető el, azóta nem szempont... szvsz.

Úgy érted, nem tér el jelentősen az órajelciklusok száma?

Üdv,
Marci

Úgy értem, hogy nem elméleti szinten vizsgálom a kérdést. Hanem üzleti értelemben: ASM-ben megvalósítva gyorsabb lesz a kód, de lassabb a fejlesztés. A mai világnak pedig ennek fordítottja kell :)

Én azt gondolom, hogy inkább ezt is számításba kell venni egy döntésnél.
És persze máshogy kell dönteni, hogyha egy Ügyfél kevés szerveren fogja futtatni nagyritkán az adott kódot mintha sok Ügyfél, sok szerveren, sűrűn. Egyik esetben a mérnökóra lehet drágább, a másikban az infrastruktúra költsége.

Üdv,
Marci

Elvileg igen, és én is azt mondom, hogy jobb az elvi alapokkal tisztában lenni, mert máshol is spórolhatunk vele erőforrást, de pont az ilyen részletek azok, amik nagyon sűrűn bekerülnek a "nem éri meg módositani, több a fejlesztés költsége mint a spórolás mértéke" cimke alá. Megjegyzem a jelen példa könnyen módositható, meg is érheti, általánosságban látom azt, hogy egyre kevesebbszer éri meg tényleg optimizálni, inkább megengedőbben kell épitkezni (lásd még optimális, de olvashatatlan kód vs. olvasható és gyorsan bővithető-módositható kód esete).

Én azt látom, hogy a Microsoft számos fejlesztésénél kulcsfontosságú az energiahatékonyság.
Nyilván speciális helyzetben van a cég, mert saját maga is futtatja saját adatközpontjaiban a termékeit, így saját zsebre is megy a dolog.
Egyik legszembetűnőbb példa az Exchange szerver diszk-kezelésének változása.

Üdv,
Marci

Egyről beszélünk, a Microsoft által készitett programot nem kis nagyságrendben futtatják, mérlegelve a spórolást, ott jóval több, mint a mérnökórák száma. Egy KKV szektoros fejlesztésnél viszont legtöbb esetben az a kérdés csak, hogy tegnapra kész lesz-e, az nem, hogy éves 10e a szerver költség, vagy 15e.

lol. sorry.
--
Gábriel Ákos
http://ixenit.com

Érdekel a véleményed, ha bővebben írod le. Így nem tudom, mire gondolsz.

Üdv,
Marci

Tapasztalatom az, hogy a Microsoft tipikus "half-assed" fejlesztő cég.
Gyakorlatilag feature-count -ra mennek rá, ha x termék tud y funkcionalitást, azt a Microsoft is fogja tudni a jövő héten.
Igaz, hogy full bugos, teljesen logikátlan, UX rémálom és tetű lassú, de a feature ott van, pipa.
Ezek után energiahatékonyságról beszélni minimum vicces.

--
Gábriel Ákos
http://ixenit.com

Jól értem, hogy Szerinted a Microsoft nem innovál, csak másol és azt is rosszul?

Üdv,
Marci

igen, de szerencsére van a pincéjükben egy belzebub kapu, az utolsó fennmaradt példány, és a sikereiket úgy érték el mindig is, hogy dolgozók lelkét áldozták az egy igaz úrnak...

nem az ms-nél dolgozom, nem is használom termékeiket, de azért azt mondani, hogy mindent, általánosan összecsapottan csinálnak biztos, hogy egy rossz egyszerűsités

Innoválgat meg összevásárol dolgokat.
De a minőség az legjobb indulat mellett is vegyes.

Mondjuk az O365 alap szolgáltatásai:
- megbízható, nem nagyon áll le
- ux borzalom
- sharepoint különösen

--
Gábriel Ákos
http://ixenit.com

Csak a nagyvállalati termékekre itt egy (régi) termékportfólió: https://markmargolis.files.wordpress.com/2013/01/msftproductsandservicesportfolio.png
Ez csak szelete annak, amiről sommás véleményt mondtál. :)

Amúgy érdekel - ha már csak az Office 365 (és benne a SharePoint) szűk szeleténél maradunk -, hogy milyen hasonló szerepű termékre gondolsz, aminek jó az UX-e, és mik a Microsoft legfontosabb hibái e téren.

Üdv,
Marci

Még mindig érdekel.

Üdv,
Marci

Valoban nem teljesen mindegy, de elhanyagolhato a kulonbseg.
Egyebkent persze szamithatna az, hogy minden sor egyforma meretu, konnyebben beazonosithato kereses eseten, illetve delete/update eseten ujra felhasznalhato pazarlas nelkul, de ekkora adatmennyisegnel foleg ugy hogy hetente 1-szer tortenik az adatok feltoltese jelentektelen kulonbsegrol van szo es a lenyegi problema nam azzal van ahogy tobben is irtak.
Amugy meg a szovegtol fugg amit tarol benne mennyire valtozo meretu, hogy megeri-e fix meret, mert lehet tobbet nyer azzal hogy kissebb az adatmereted amit kezelni kell es hamarabb kereshetove valik.
Valoban nagy meretu adatbazisoknal mar szamithatnak ilyenek is, de akkor is sok egyeb modszerrel tobbet lehet javitani elso korben.

Különösen vicces lesz, ha végül kiderül, hogy az 500e sor ahogy fentebb is irta a kérdező, másodperc alatt rendelkezésre áll, csak a frontend oldalon html-ben való megjelenés a nagyon lassú (lehet tippelni, hogy a js miatt, vagy csak egyszerűen a html table nem jó móka többszáz sor felett), itt közben azért elvi vita zajlott az adatbázis struktúrájáról (amit én élvezettel olvastam :) ).

js miatt? ugyaan :D
Inkább az a jellemző, hogy php-ben megírják a for ciklust és minden egyes sort új sql kéréssel hívnak le ahelyett, hogy sql-ben kérnék le és az eredményen lépkednének végig :)

eeeegen, mindkettő lehet, php oldalon is el lehet követni a hibát, de annak kisebb lehetőségét látom, a php manual-ból kimásolt while ciklusos feldolgozást tippelem legelterjedtebbnek

már őszintén kiváncsi vagyok mi volt a fenti esetben, ha egyszerűen annyi, hogy a html "render" tartott X x 10 sec-ig, akkor le lehet vonni a tanulságot a fenti kommentárokra, váltsunk stack-et, program nyelvet, adatokra, mérésekre nincs is szükség :), és meglep, hogy a kérdező eddig kb. felét adta ki azoknak az információknak, ami egy vastag tippeléshez minimum kellene, többszöri kérésre

a kerdezo fiatalember kamuzik ossze-vissza. Bedob egy problemat, majd mutat egy sql query-t, aminek zero koze van a topiknyitoban olvashato gondhoz, de legalabb az is szar...

akkor nem csak nekem tűnt fel, hogy először billentyűleütésről van szó (szöveges keresés?), majd dátumról (mindeközben megintcsak: alig kaptunk válaszokat, pedig elsőként én is, és mások is feltettek egyszerű kérdéseket, nekem az volt a sejtésem, hogy az explain használatával még nem ismerkedett meg)

Kétszer is elolvastam de nemértem.
Hogy érted, hogy for ciklus és minden új sort sql-be?
Vagy én még nem láttam ilyet vagy nem értem..

pch
--
http://www.buster.hu "A" számlázó
--

Olyant már láttam, hogy a query result count alapján inditott egy for ciklust a delikvens, és abban limittel kérte le a sorokat, mert: előre nem látható módon csak némelyik sor kell neki, és egy ponton le is áll a lekéréssel, feleslegesnek tartotta egyben lekérni a 10e sort, helyette hol 200, hol 1000+ lekérdezés ment egyesével. Lehet tippelni melyik volt rosszabb ötlet :) (de legalább nem hangzik ordas hülyeségnek, csak nem szerencsésnek).

Hogy valami alapján rekordonként külön lekérést szoktak csinálni az amatőrök.
Csak egy hasraütéses példa, mondjuk auto increment id mezőre csinál szűrést, hogy
select * from tábla where id= a php által behelyettesített érték és mondjuk egy while vagy for ciklus pörgeti addig, míg üres nem lesz az eredmény.

Tehát nem page-elésről van szó, amikor értelme lenne a limitekkel részletekben lekérni a táblát, hanem rekordonként kéri le a szerencsétlenje.
Sokszor láttam már ilyet, amikor pár tucat sort mutató webes felület marha lassú volt, mert mondjuk 10 látható elem nem egyben volt lekérve, hanem 10 sql hívást indított rá soronként.

szerk: eszembe jutott még amikor ilyet szoktak csinálni.
Mikor a diák programozó nem ismeri a join-t és külön select-ben lekéri az egyik táblát, majd a másik tábla szüréséhez az elsőn léptetett ciklus indít kéréseket.

sql Select * from tábla1
php while rekord_tábla1
sql select * from tábla1 where elado_id = php-ben hozzátéve a rekord_tábla1["id"]

Meg hasonló kreatív baromságok, amiket tapasztaltabb ember el sem tud már képzelni.

JUJ.

Akkor eddig szerencsém volt, hogy nem láttam ilyet.
Bár az utóbbit mintha már láttam volna valami laravel-es cuccba.
De végül nem jutottam el odáig mert egyéb okok miatt visszaadtam a munkát.

pch
--
http://www.buster.hu "A" számlázó
--

Hasonló történetet mesélt egy kollégám, de ő valamilyen NoSQL-t használó programozó vs. MySQL esetében, külön kezelte a táblákat, és módszeresen mindenhol "id" alapon kért le egy-egy sorokat. Nem láttam a kódot, de rövid egyeztetés után amikor kiderült, hogy NoSQL-ezett csak eddig az elkövető, és neki a relációs adatbázis, a join-olás "erőforrás zabáló és elmaradott", akkor azért csak megértették egymást :).

Biztos van jó use case a NoSQL-re (fenti nem kritika, nem ismerem eléggé), de egyúttal példa volt a kockát rakok a kerek lyukba esetére is.

Sok évvel ezelőtti munkahelyemen egyszer találkoztam azzal, hogy egy weboldalt párhuzamosan kiszolgáló, három mysql szerveren pörgött egyenként 8000 select/sec. Tehát összesen 24000 select másodpercenként. Amikor megkérdeztem a programozó zsenit, hogy ez mi? Akkor az volt a válasz, hogy - a php nem elég random!

A jóképességű "valahogyan generált egy véletlent" majd lekérdezte a mysql-t, hogy volt-e már olyan és ha volt akkor "generált egy másik véletlent" majd ismét lekérdezte... de egy idő után sajnos elfogytak a véletlenek mert mindig olyan jött ki a mi már volt korábban. Ezért a mysql ott próbálgatta a véletleneket a végtelenségig.

Idézet a PostgreSQL dokumentációjából:


Tip: There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

Lehet, hogy a MySQL-nél ez nem így van, de már csak emiatt is jobb a PG. :)

"nem lehet, hogy maga az eredmény gyors, csak a kiíratás lassú?"

Ha a select * ennyire gyors, akkor kérdés: egy átlagos keresésedben milyen nagyságrendű a sorok száma? Ha ezres nagyságrendről beszélünk egyrészt már a json fájl is lehet nagy, de ami még nagyobb baj, ha a javascript-ed egyszerre próbál ezres nagyságrendű sort egy táblába tuszkolni. Ha jól kezelhető keresőt akarsz, akkor használsz valamilyen lapozást, és mondjuk 100, max 500 soros megjelenitést (ha valami indokolja), nekem most az a tippem, hogy ez kb. megoldja a problémát.

Ha első körben SQL oldalon a lapozást nem tudod megoldani, akkor próbálj ki egy datatables-t: https://datatables.net/examples/basic_init/zero_configuration.html

(És javaslom ne ragadj le ennél, a datatables sem arra való, hogy többezer sort fogadjon, adatbázis oldalon kell limit-ekkel lapoznod.)

JS datatable max 100 sorig jó.
Utána már érdemes sql-es lapozást alkalmazni + datatable.
Ha jól emlékszem tudja a jsq hívásba a lapozáshoz szükséges adatokat küldeni.
Én mást használok az tud, így json-ba csak egy táblányi adat jön mindig (25-50-100) és gyors mint a villám.

pch
--
http://www.buster.hu "A" számlázó
--

1 - azt irtam én is, hogy nem megoldás, de átmenetileg segithet, és ne álljon meg ott, mert megintcsak: nem megoldás.

2 - datatables vigan elrohangál nálam 2000-3000 sorral is (workaround, a backend egyelőre nem lett átvéve-átalakitva), "max 100 sor" azért nagyon szégyen lenne, ha nem menne

3 - datatables tudja küldeni ajax-ban a paramétereket (lap sorszámát, sorok számát, rendező oszlopokat és irányukat azt hiszem sok más adattal együtt), nem túl barátságos leirás, de ez elvileg mindent tartalmaz:

https://datatables.net/manual/server-side

Nem latok indexet a teljdate-re...

Kerlek mutass EXPLAIN-t is a querykhez meg jo lenne a flush status es Handlers is.
Amugy hosznalj InnoDB-t mint fentebb irtam a Buffer Poolban az indexen kivul a dta pagek is benne vannak tehat memoriaban van az adatod ami jelentosen gyorsabb mint a disk. Persze ehez akkora buffer pool kell hogy a dataset bele ferjen. Hasznalj lehetoleg egy auto increment primamy keyt InnoDB ugyanis a primamry key szerint tarolja az adatokat a disken, ha nem hozol letre o akkor is letre fog hozni egy hidden primary keyt ami pazarlas.

A teljdate alapjan szur a queryd de nincs index rajta ez azt jelenit h minden egyes esetben vegig kell olvasnia az egesz tablat ami szinten pazarlas.

500 ezer sor az túró.
Ha végképp nem boldogulsz vele akkor tedd bele elastic -ba.
--
Gábriel Ákos
http://ixenit.com

+1
Nekem van 500 Millió rekordos táblám is PostgreSQL alatt.
Épp particionálom, mert kezd lassulni. :)

---
"A megoldásra kell koncentrálni nem a problémára."

Ha az lenne, nem fórumozgatnék itt veletek. :D

Egyébként Zabbix. Másodpercenként ~250 bejövő értékkel.

---
"A megoldásra kell koncentrálni nem a problémára."

Hát igen 500e a semmi.
Most megnéztem egyik elastic nodeunkat: 3,089,589,568 Documents

Lassúcska is a keresés már :D

Fedora 25, Thinkpad x220

Azert az jopofa, hogy nemreg lattam egy kdb+ adatbazis-tesztet, ahol 1.1 milliard sort tartalmazo tablan csinaltak aggregaciot (atlagot szamoltak egy oszlopra), es az 1 masodperc alatt megvolt. Nyilvan speci hardver, de akkor is, minden egyes sort vegig kell hozza olvasni.

----------------------
while (!sleep) sheep++;

Én is láttam már Ferrarit, de nem indokolt a SPAR-ba járáshoz. :)

(És én is tisztelem a Ferrari teljesitményét, még ha nem is használnám.)

Nekem az jutna eszembe, hogy egy triggerben az eltárolt összeghez hozzáadnám az insertelt mező értékét, majd megnövelném az osztandó értékét, (update esetén a különbséggel korrigálnám) eltárolnám... Ha kell - gyakoriságtól függően -, azonnal kiszámolnám az átlagot is és tárolnám, vagy csak lekérdezéskor. Hasonlóképp törléseknél is.. Sohasem kellene végigmenni az adatbázison, ha kell az átlag.

kérdés, hogy mit tárolunk, és mit számolunk: amit te leirtál az egy ügyes optimizáció arra az esetre, ha sűrűn kell az átlagot számolni, viszont insert,update esetén többlet terhelés, illetve az átlag vagy sum értékét tranzakcióban kell kezelni, annak is van hatása, és persze ez megoldható akár automatikusan minden szám tipusú oszlopra, de mi van, ha szűkiteni akarok benne?

Nekem az jutna eszembe, hogy egy triggerben az eltárolt összeghez hozzáadnám az insertelt mező értékét, majd megnövelném az osztandó értékét, (update esetén a különbséggel korrigálnám) eltárolnám... Ha kell - gyakoriságtól függően -, azonnal kiszámolnám az átlagot is és tárolnám, vagy csak lekérdezéskor. Hasonlóképp törléseknél is.. Sohasem kellene végigmenni az adatbázison, ha kell az átlag.

Maga, mindent kétszer? Maga mindent kétszer? (Pegid csak egyszer nyomtam...)

Meglepo, de az atlag szamolas rettento gyors muvelet es eleg konnyen parhuzamosithato. Nekem volt egy par eve egy olyan projektem, ahol syslog-ng etette orankent valtozo tablaba az adatokat es a kovetkezo ora elejen egy bash scriptbol inditott MySQL query aggregalta. Annak ellenere hogy icipici vason futott es tobb mint felmillio sor gyult ossze egy ora alatt, az aggregalas villam gyorsan (<1s) megvolt. Nyilvan itt kozre jatszott az is, hogy az a tablan csak es kizarolag insertek tortentek, es az aggregalas utan eldobtuk az adott orara vonatkozo tablat, az uj ora adatai mar masik tablaba mentek.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Saját tapasztalatok alaján, azt mondom, hogy pl sok select esetén (pl. hírportál) fel kell nyomni a MySQL cache-t és sokkal jobban lehet fejeszteni hozzá, mint a memcache, és egyéb csodamegoldásokkal. De nagyon sokat számít a WHERE feltételek sorrendje is. Az a lényeg, hogy mindig a lehető legkevesebb adattal dolgozzon az SQL. A lehető legjobban le kell szűkíteni azt a mennyiséget, amivel dolgozol. A megfelelő indexekkel, betweennel... Kerüld az OR-t az IN-t. Inkább JOIN-olj és szűr ki a NULL-os sorokat.