A MySQL és MariaDB legnagyobb hiányossága: a materializált view

2019.08.24. legyes 0

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.

No Image

MariaDB hibaüzenet: ERROR 1524 (HY000): Plugin ‘unix_socket’ is not loaded

2018.05.08. legyes 0

Mindig azt mondják az okosok, hogy a MariaDB teljesen kompatibilis a MySQL-el. Hát, aki ezt mondja, még nem próbálta a JSON függvényeket (sok bosszantó hibát 1+ éve nem javítottak), vagy PureFTPd-mysql -t beüzemelni… De az egész világ megy a MariaDB felé és a stabil Debian is cserélni a MySQL-t erre. Friss teleptésnél ha konzolon akarunk ügykődni a címben szereplő hibaüzenetet kapjuk.

No Image

MySQL subselect sebessége

2017.12.05. legyes 0

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 [….]

No Image

Rendkívül lassú a PHP-MySQL (localhoston) Windows alatt

2017.09.28. legyes 0

Én nem vagyok rajongója annak, hogy Windows alatt futtassunk PHP-MySQL kombinációt. Hisz’ eleve sokkal több erőforrást adunk oda az operációs rendszernek, mint Linux alatt. Nincs meg a fájlrendszerrel való finomhangolás lehetősége sem, valamint az IIS és én sohasem leszünk barátok. Egy projekt alkalmával arra lettem figyelmes, hogy ugyanaz a kód fényévekkel gyorsabban fut Linux alatt, mint Windows alatt, egy egyszerűen semmi logikus magyarázat nem volt rá. Nos a problémát a [….]

No Image

Több sor és oszlop egy cellaként MySQL és MariaDB-ben: JSON függvények és a GROUP_CONCAT() együtt

2017.08.28. legyes 0

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 [….]

No Image

MySQL: GROUP_CONCAT() méretének növelése a sessionben

2017.04.03. legyes 0

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 [….]

No Image

JSON képes MySQL 5.7 telepítése Debian linuxra

2017.02.06. legyes 0

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.

No Image

Súlyos MySQL sebezhetőség: CVE-2016-6662

2016.09.14. legyes 0

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 [….]

No Image

HeidiSQL

2016.08.23. legyes 1

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 [….]

No Image

Településlista betöltése MySQL adatbázisba

2016.08.22. legyes 1

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.

No Image

SQL: Ügyes trükk 2 állapot közötti váltogatásra

2016.03.23. legyes 0

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

No Image

MySQL, még mindig az indexek

2015.10.13. legyes 0

Í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. [….]

No Image

PHP és MySQL adattípus túlcsordulások

2015.07.19. legyes 0

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 [….]