Ha olvasod a blogom korábbi bejegyzéseit, tudhatod, hogy nem vagyok híve a vegyünk minden hónapban egy erősebb szervert, ha valami webes szolgáltatás kezd kifogyni az erőforrásokból. Ahogy sokszor hangoztatom azt is, hogy nem a PHP lassú, hanem az, ami kiszolgálja: a legtöbb esetben az adatbázis válaszideje.
Végre elérkeztünk oda, hogy részletesebben elemezhetjük, ingyen a MySQL query futását az új MySQL Workbench (ingyenes) programban: https://dev.mysql.com/downloads/workbench/
Már egy egyszerű weboldalnál is gyakran előfordul, hogy a kapcsolódó adatokat egy subselect állítja elő, így csökkentve a lekérések számát az oldal generálásakor. Csak épp nem mindegy, hogy hogyan is csináljuk. A MySQL sebességét nagyon erősen az határozza meg, hogy hány sorral kell dolgoznia. Ezért is nagyon fontos, hogy mindig a lehető legkevesebb sorral dolgozzon az adatbázis, akkor is, ha csak egy köztes folyamatról van szó. Az alábbi 2 query [….]
A fejlesztők 2 fajtája nem foglalkozik az adatbázis lekérdezések sebességével több kapcsolódó adatnál: a kezdők és a profik. A kezdők lekérdezik az alap adatokat, majd egy foreach()-en belül futatják le a kapcsolódó adatok lekérdezését: foreach ( $products as $product ) { $db->query( „SELECT id, thumbnail, url FROM product_images WHERE product_id = :product_id” ); } A profik is ez csinálják, csak sokkal csillibb kivitelben. Először csinálnak egy Image class-t. Majd egy [….]
Sokan elkövetik azt a hibát, hogy a MySQL lekéréseket PHP ciklusba teszik, mert másképpen szerintük nem megoldható, hogy több soros eredményt tegyünk bele 1 SQL cellába a lekérdezés eredményénél. Ez a rossz módszer természetesen nagyon erőforrás pazarló és a weboldalak sebesség problémáinak nagy részét is ez okozza. Az egyik jó megoldás ennek elkerülésére, ha a GROUP_CONCAT() paranccsal egyesítjük a subquery sorait. Viszont alapértelmezetten ebbe csak viszonyag rövid eredmény fér, így [….]
A NoSQL hullám nagyon hódít, amivel én nem feltétlenül értek egyet, mert azt vallom, hogy mindent arra kell használni, amire való (azaz adatok tárolására, szűrésére, stb. SQL-t). Az egyik fő indok mellette azt szokott lenni, hogy JSON objektumokat lehet benne tárolni és azokkal lehet dolgozni. Így kliens oldal eleve készen kapja, nem kell a backenden összerakni és szétszedni újra és újra.
Sajnos megjelent egy olyan rendkívül súlyos MySQL sebezhetőség, ami a korlátozott jogokkal rendelkező felhasználókat is hozzásegíti a teljes MySQL jogosultság megszerzéséhez. Ez a jelenleg elérhető legfrissebb rendszereken is megtalálható, a biztonsági csomagok még nem tartalmazzák. Ez a sebezhetőség ugyanúgy problémát okoz a weblapokon keresztül – így a PHPMyAdminban – is. Érintett a MySQL és azok klónjai (pl. MariaDB). Affected MySQL versions (including the latest): <= 5.7.15 <= 5.6.33 <= 5.5.52 [….]
Próbáltam már használni a MySQL Workbenchet, a ToadSQL-t és egyéb népszerűbb programot, de valahogy mindig a HeidiSQL-nél kötöttem ki. Nem profi cucc, de az alap dolgokhoz épp elég. Jelenleg 3 féle adatbázist kezel: MySQL (MariaDB specifikus dolgokat is kezeli!), Microsoft SQL, PostgreSQL. Ezekhez több módon is képes kapcsolódni, akár SSH tunnelen keresztül is, amit a plink segítségével valósít meg. Ja és beszélni magyar 🙂 Van benne pár bug, ezért érdemes [….]
Az egyik projektemben szükség van a magyar települések listájára, lehetőleg koordinátákkal a későbbi távolság számítás és térképen ábrázolások miatt. Nagyon sok szolgáltató kínál ilyen adatbázisokat vagy webes API-kat horror árakon. Találtam egyet, ahonnan letölthető ez a lista txt-ben: http://download.geonames.org/export/zip/ . A fájl UTF-8 formátumú, tabbal elválasztott szöveges fájl, ahol a sorvége jel a \n.
Sok esetben előfordult már, hogy szükségem volt egy elem láthatóságának 2 állapota közötti váltogatásra. Igazi amatőr módon eddig vizsgálgattam, hogy látható-e és ha igen, akkor el kell rejteni és fordítva. Na, ettől jóval egyszerűbb a megoldás: UPDATE table SET field = 1 – field forrás: http://stackoverflow.com/questions/603835/mysql-simple-way-to-toggle-a-value-of-an-int-field
Íratlan törvény, hogy a táblák kapcsolódási pontjaiból érdemes indexet csinálni. A Zandagort kódban ezt már korábban átnéztem. Viszont volt néhány query, ami viszonylag sok tábla kapcsolatából állt és egyre nagyobb részt vett ki a körváltóból, így utána kellett nézni, nem-e lehet gyorsabbá tenni. Végig néztem a használt táblákat és volt már rajtuk index, szép számmal, több helyen már redundánsnak is tűntek. Próbáltam a lekérdezés WHERE feltételének sorrendjét módosítani, de kb. [….]
Azt ügye tudjuk, hogy a PHP-ben automatikus típuskonverzió van, amire oda kellene figyelni. A PHP-ban a számok ábrázolására 2 típus áll rendelkezésre (+boolean): – (signed) integer – (signed) float Ezek minden esetben előjellel vannak ellátva, így az integer típusban maximum 2^63 érték tárolható egy 64 bites rendszeren, 64 bites PHP-val. Viszont! A MySQL-ben rendelkezésre áll az előjel nélküli változat, az unsigned bigint, ami ugyanezen körülmények között 2^64 tud ábrázolni, előjel [….]
Amennyiben adatbázisokat költöztetünk, előfordulhat, hogy a view-t létrehozó felhasználó az új helyen már nem létezik. Ez jó kis galibát tud okozni, mert a hibaüzenetek nem utalnak egyértelműen a hiba valódi okára. root@z:~# ERROR 1143 (42000) at line 1: SELECT command denied to user ”@’85.90…..’ for column ‘oszlop’ in table ‘tabla’ Persze a szokásos MySQL használatot megkönnyítő programok nem működnek. A PHPMyAdmin csak részben listázza a táblákat és az information schema-ban [….]
Arra adtam a fejem, hogy egy picit bővebben belevetem magam a MySQL-be. Ez nem jelenti azt, hogy enterspájz adatbázisokat optimalizálok, csak picit tovább megyek a „SELECT * FROM tabla ORDER BY RAND()” szinten. Erre igazából azért van szükség, mert úgy gondoltam, hogy összeütök magamnak egy parányi űrstratégiát PHP, MySQL, JavaScript, HTML4 alapon (lásd: www.zandagort.hu). No nem azért, hogy játsszak kicsit, hanem azért, hogy fejlesszem picit képességeimet. Korábban már használtam az [….]
