- Leégett az első Radeon a hírhedt 12V-2x6 tápkonnektorral
- Hobby elektronika
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Sony MILC fényképezőgépcsalád
- OLED TV topic
- ASUS ROG Ally
- 5.1, 7.1 és gamer fejhallgatók
- Milyen belső merevlemezt vegyek?
- Megjöttek a be quiet! Pure Loop 3 sorozatú kompakt AIO-i
- Milyen billentyűzetet vegyek?
Új hozzászólás Aktív témák
-
Hege1234
addikt
működik köszönöm
elkerülte a figyelmem
esetleg azt hogyan tudom elérni hogy be is töltse a találatokat?
mert most engedi már görgetni de pár ezret azért hosszadalmas..
(20-30 at betölt és ahogy görgetek úgy tölti be folyamatosan)kodi adatbázisáról van szó
ami most még csak a gépemen fut
de tervezem hogy routerre teszem
ott tényleg nem lenne jó egyszerre mindent betölteni
köszi a fegyelmeztetést -
#2062
digitalson78
friss újonc
sonar
#2061
-
-
robi191
csendes tag
-
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.
-
#2027
ArthurShelby
addikt
sonar
#2024
ArthurShelby
addikt
-
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). -
SaNyEe
aktív tag
Nem segitett, force index kellett, ugy lett 1.65s a futasi ido. Az alkalmazas forrasahoz nincs hozzaferesem, elegans modjat (db szintu) szeretnem valasztani a problema megoldasanak.
Ehhez egy uj app release kene es az is csupan egy szepsegtapasz lenne
Masik erdekesseg amibe botlottam es nagyon meglepett oracle utan A+B tabla inner joinnal letrehozott, mindket tabla oszlopait tartalmazo rendezett, limitalt lista letrehozasanak koltsege iszonyat magas volt. A tabla 4 millio, b tabla 4db rekordot tartalmazott.
Az eredmeny eloallitasa kb 60 sec volt, ha csak a tabla oszlopait jelenittettem meg az kb instant megjelent. (1db where clause volt a tablara, indexelt)
-
Male
nagyúr
Azzzz, most van hozzáférésem, nézem... 3306-os port 50023 - 54367 közti kimenő porttal mind TIME_WAIT-en van... pedig most épp nyugis időszak van. Ehhez jön még a 80-ashoz várakozó kupac. Hogy rohadna meg, legalább írná azt, hogy nincs szabad kimenő port, akkor egyből kiderül... kinyomozom hogyan lehet ezt a 4 percet lecsökkenteni, a tizede is bőven elég lenne (eleve nem tudom, ha close-zal zárok egy kapcsolatot, akkor mi a fenének kell még 4 percig váratni... bár lehet, hogy van valami a protokollban, de bármi is az, a 4 perc rengeteg manapság).
...aha, másodpercenként ez 18 darab port nyitásnak felel meg... nem is tippeltem rosszul a terheléssel kapcsolatban
Megint volt gond, a statot megnézve:
Aborted_connects 0
Connection_errors_accept 0
Connection_errors_internal 0
Connection_errors_max_connections 0
Connection_errors_peer_address 0
Connection_errors_select 0
Connection_errors_tcpwrap 0
Connections 7031142
Max_used_connections 6
Performance_schema_session_connect_attrs_lost 0
Ssl_client_connects 0
Ssl_connect_renegotiates 0
Ssl_finished_connects 0
Threads_connected 2 -
Male
nagyúr
Köszi!
Délután férek hozzá, akkor nekiállok nyomozni ez alapján.A max_connections-t már belőttem 10.000-re a hiba után, mert nem volt beállítva egyáltalán. Viszont gugli szerint ha azt érem el, akkor más hibakódot kapnék (12xx, nem emlékszem pontosan, de nem 2002).
A query-ket átnézem, de alapvetően kétféle megy ilyen gyakorisággal:
- egy kis méretű, mindössze 10-20 soros, és 3 oszlopból álló (int, tinyint, timestamp) táblában kell keresnie, ráadásul pkey alapján a legutolsót. ( mondjuk ezen kicsit lehet még javítani, mert kizárólag az utolsó sorra van szükségem, tehát új beírásakor akár kukázhatnám is az összes korábbi bejegyzést ). Ugyan ezekbe a táblákba írás nagyjából naponta 1-2 van.
- a bonyolultabbnál már van egy MAX és egy MIN keresés is:SELECT MIN(`tv1p`), MAX(`tv1p`), `emelkedo` FROM `{$sql}` WHERE `vastagitas_ido` != '0' AND `emelkedo` = '0' UNION SELECT MIN(`tv1p`), MAX(`tv1p`), `emelkedo` FROM `{$sql}` WHERE `vastagitas_ido` != '0' AND `emelkedo` = '1'
...a tv1p int, és indexelve is van. Ebben tippre szintén max pár száz sor van, de délután ellenőrzöm. ( ebbe írás/update napi 4-5 van )Az egésszel adatokat osztok meg programok között a gépen belül, és ami furcsa, hogy egyszerre jelentkezik mindegyik ebből olvasó programnál, és ilyenkor pont ugyan annál a táblánál (köv. eset másik tábla, de megint ugyan az mindegyik programnál)... pedig a connectnél még nem is tudhatja, hogy melyik táblából fogok olvasni
Igaz, eddig mindössze háromszor fordult elő, szóval lehet véletlen is.Gugli közben olyan tippet is adott (miután megtaláltam az angol verzióját a hibaüzenetnek... a francnak kell ezeket lefordítani), hogy igazából nem is a MySQL-nél van a gond, hanem a Windows limitációja okozza a problémát: a nyitott portot én hiába zárom, ő még 4 percig váratja, és emiatt simán kifogyok a felhasználható portokból.
-
qwertly
addikt
Szia!
köszönöm a válaszodat
ez már kiindulási alapnak jó.Mivel nem vagyok linux-ban power user ezért kérdésem lenne fedorában is így működik a dolog?Mert a linux gépek a Sulix Professional 8, használunk.Jogosultság kérdésem pedig az lenne,hogy nem attól félünk kívülről meg hackelik a hallgatót hanem,hogy egymásnak írják segitenek.Mert ha tudják az adott gép ip címét akkor betudnak jelentkezni a teremben levő másik gépre,azt szeretnénk,hogy az adott gépre bejelentkezett hallgató írhasson csak az adott gépen levő mappába.Ennek a blindelésnek van jelentősége ha így indítottuk el: böngésző címsora: localhost/phpmyadmin. Itt az lett a gond,hogy elején még szépen ment de egyre lassabb és megbízhatatlan lett.és amikor volt a próba érettségin akkor már gyakorlatilag használhatatlan lett vagyis elsőnek nem is tudtak bejelentkezni a teremben levők,de amikor újra indították a gépeket akkor ment a bejelentkezés de nem tudtak beimportálni az adatbázis kiszolgálóba.Ugyan akkor olyan termekben ahol nem dolgoztak még a mysql php ment minden.Mint írtam nem vagyok nagy linux felhasználó,még ha sulink linuxot használ akkor sem,és a suport nem ad támogatást mert,ezek nincsenek benne a repoba. Így minden tanácsot szívesen veszek 
-
csusza`
senior tag
Igen.
5.1 alól kidumpolt fájlt az 5.6.28-ba gond nélkül beemelte, e fölött verzióknál már gond volt.
5.6.9-re, sem 5.7.11-re nem ment át rendesen, valami hibával elszállt.Próbáltam utána a működő 5.6.28-at bedumpolni újabba, ugyanúgy elszállt. Pedig jó lenne a lehető legfrissebb verziót felrakni, de most egyelőre nem volt kedvem tovább próbálkozni vele.
-
csusza`
senior tag
Szia!
Megpróbáltam, az utolsó parancsnál leakadt a rendszer.
Újraindítottam, azóta a root jelszót is eldobja a rendszer, és be sem enged a MySQL parancssorba sem!
Nem gáz, le vannak mentve az adatbázisok, próbálkozom, csak pár nap alatt tényleg meg kell oldanom a dolgot.@martonx: az elméleti részéhez nem értek, nem is akarok belemerülni, csak legyen áthelyezve nekik az új szerverre ...
-
theo_76
aktív tag
kicseréltem azokat a feltételeket, bár nem értem miért nem jó, mivel pont az lenne a lényeg (és végül is működött is a feltétel), hogy azokat a sorokat válogassa ki, amik még nem kaptak semmilyen értéket. Viszont az igazi problémán nem változtat, az ORDER BY, így se teljesül...
-
theo_76
aktív tag
Azt is próbáltam már... Az a vicces, hogy ha a szűrőt kiveszem, akkor tökéletesen rendez. Mintha a WHERE utasítás semlegesítené az ORDER BY-t... Próbáltam még a phpmysql-en keresztül lefuttatni a parancsot, de ott meg null sorral tér vissza sajnos más lehetőségem meg nincs, hogy programmal (pl az MySQL Workbench) beletudjak nézni az sql működésébe... a php kód a 000webhost.com ingyenes tárhelyen fut. Sajnos otthoni körülmények között frissebb mysql-el php-vel nincs most alkalmam kipróbálni.
-
-
theo_76
aktív tag
már az első karaktereknél elcsúszik, amik nem tartalmaznak ékezetes karaktereket. Egyébként a tábla karakterkészlete utf8_hungarian_ci, és a php-ben is úgy állítottam be az sql lekérdezéseket. Ha a WHERE-el nem szűröm meg a lekérdezést, akkor tökéletesen rendez, de ha beteszem a szűrőt, hogy csak bizonyos adatok jelenjenek meg, akkor olyan mintha az ORDER BY utasítás nem is létezne. Ha kiveszem, akkor is ugyan abban a sorrendben jelennek meg, amilyen sorrendben rögzítettem a sorokat. Pl most így néz ki WHERE utasítással ORDER BY-al, és nélküle is:
Komló...
Komló...
Kozármisleny...
Komló...
Komló...WHERE nélkül, ORDER BY paranccsal:
Komló...
Komló...
Komló...
Komló...
Kozármisleny... -
qfm
őstag
Igazából a leírtak 90%-a nem valódi honlap lesz, hanem eszközök közötti kommunikációra szolgál. Emberek által látott felület minimális lesz. A rekordok száma esetén a maximálisat írtam le, amit a kiépítés megkívánhat. Pentium alatt egy modern G3220-ra gondoltam, nem egy P4-re, de valóban nem definiáltam. Ennek ellenére i3 alatti gépet nem fogok javasolni, csak érdekel mennyire lövök túl a célon. A dedikált hardver külön elvárás volt.
(#1746) martonx
1, A 4gb-os ram nem kifejezetten drága, így csak megnyugtat a tudat, hogy szerinted is bőségesen elég.
2, A forgalom csak akkor ugorhat meg, ha valamelyik hardver meghibásodik, eléggé jól leszűrt forgalom van rá tervezve.
3, A dedikált szerver külön kérés volt, én is mást ajánlottam, de bizonyos okok miatt ez volt a kérés.
4, Soha nem használtam még NoSQL-t, de utána fogok nézni a javaslatodnak.
5, A számok azért ilyen alacsonyak, és talán furák is, mert egy speciális hardver kommunikációhoz lesz csak háttér adatbázis. Az adatmennyiség limitált amit tárolni, és feldolgozni kell.
6, Valóban nagyon egyszerű, és a kimenet előállításához nem is szükséges több sql művelet. A bemenet függvényében azonban több különböző folyamat zajlik le, van amelyik 1 hívással jár, van amelyik 3-al. A legrosszabb esetet vettem alapul. A kimenet pusztán nyugtázó funkciót lát el.+1 a 6-osból adódna a kérdés, hogy miért nem az adatbázist használják a hardverek, hanem a köztes PHP oldalt. Azért mert ez volt az igény.
-
don_peter
senior tag
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t ALL NULL NULL NULL NULL 119 Using temporary; Using filesort
2 DEPENDENT SUBQUERY fu index NULL datum 6 NULL 1 Using whereEz nekem nem sokat mond.
Extrákba ez van a topik-nál: Using temporary; Using filesort
A SUBQUERY -nél: Using where -
Export the database to file
Ez nem fog menni, mert egy 3GB-os, folyamatosan változó adatbázisról beszélünk
A bármit helyettesítő karakter a százalékjel ( % ) lenne?
Mert sok ( ~12 000 ) ehhez hasonló táblám van:
wp_1_comments
wp_2_comments
wp_3_comments
wp_4_comments
stb.És ha így írom be:
wp_%_comments
Nem fogadja el, szintaxis hibát ad.
-
Így néz ki a teljes kód, amit beírok:
USE adatbazisom;
DELETE FROM wp_comments WHERE comment_approved = 'trash';
DELETE FROM wp_comments WHERE comment_approved = 'spam';
DELETE FROM wp_comments WHERE comment_approved = '0';
DELETE FROM wp_comments WHERE comment_approved = 'post-trash' -
-
don_peter
senior tag
Köszönöm, beírtam, de időt nem ad ki.
MySQL közvetlen felületén futtatom most a parancssort.A többit persze, így csináltam, és a subselect-ek szűkítésével egyre gyorsabbá vált a lefutási idő.
De ez előtte nem volt gond, viszont most közel 30szorosára emelkedett a lefutási idő.
Fura.. -
Ablakos
őstag
Centos 7-en akartam alkotni, de nem megy.
Ha beteszem a két extensiont, akkor :PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: php_pdo_register_driver in Unknown on line 0
PHP Warning: Module 'mysqli' already loaded in Unknown on line 0Mivel a distribucióhoz eléggé kötődik a mariadb, nem akarok gányolni mysql cserével.
Csőd
-
-
-
a folyamat az alábbi
-- termék lista frissítés --
1.) letöltöm a csvt (20-30.000 sor pl az egy beszállító adatbázisa)
2.) soronként md5 hasht generálok
2.a.) ha a sor md5 hash-ét megtalálom a dbben (SELECT) akkor nem csinálok semmit mert az a sor az adatokkal már szerepel
2.b.) ha a sor md5 hash nem szerepel az adatbázisba akkor lekérem a cikkszám szerint a terméket
2.b.I.) ha megvan a termék cikkszám szerint (UPDATE) és az md5 hasht is frissítem
2.b.II.) ha nincs meg a termék (INSERT)
3.) az összegyűjtött md5 hash-en kívüli termékeket inaktiválom (mert a lista mindig tartalmazza az összes elérhető terméket (de néha ki be kerülnek termékek + seo szempontból a nem kapható termék is google találat ráadásul igen elöl ... ehhez meg az ügyfél tud megadni alternatív termékeket melyre az ügyfél át tud ugrani...-- kategória frissítés --- (az ügyfél kérése, hogy minden kategóriában megjelenjen, hogy hány termék van és csak az a kategória legyen amiben van termék)
4.) lekérdezem az összes kategóriát ami egyik kategóriának se a szülője (azaz a leveleket) (SELECT)
5.) végig járom a leveleket majd a szülőiket berakom a tömbbe ha még nincsenek ha vannak akkor összeadom az adott kategória elem számát a szülőjével ... azaz egy fabejárást csinálok, és minden kategóriát csak egyszer frissítek mikor már kiszámoltam a kategóriák elemszámait ...
6.) egyesével lefrissítem a kategóriák elemszámát... Ez a lassú
pedigg a fenti query fut le ... most annyit raktam még bele, hogyUPDATE webshop__category
SET productnumber = ".$numCount."
WHERE id = 10370
AND productnumber != ".$numCountÍgy csak akkor updatel amikor valóban változott a product number ... Ma kiderül mennyivel jobb a helyzet ...
-
DNReNTi
őstag
Akkor meg készíteni kell a felhasználóknak egy felület amin ők maguk vezetik a változásokat. Na ez az amit a felhasználók majd telibeszarnak és az egész nem ér semmit.
Szerintem egy ilyen ellenőrző script nem nagy overhead, pillanatok alatt átfutja a filelistát és az adatbázist is.Én utóbbival kezdeném:
SELECT id, filename FROM files;
Egy foreach() ciklusban minden fájlnevet lehet ellenőrízni file_exists() függvénnyel.
Ha nem létezik, a bejegyzést törlöd.Ha ez lefutott jöhet a fordított eset:
A fájllistán mégy végig, és az aktuális fájlnévre keresel a táblában. Ha egy adott fájl nevére nincs találat, akkor felviszed az adatbázisba.A felülírt fájlok este így hogy a dátum nem változik már érdekesebb.
De erre megoldás lehet a filemtime() függvény, ami a legutolsó módosítás idejét adja vissza. (Bevallom még sosem használtam így erre nem esküszöm meg.) Ezt egy az egyben bele lehetne integrálni az első lépésbe, így ha egy file létezik de a legutolsó módosítás dátuma nem egyezik akkor azt frissíted.Ezzel egy viszonylag up to date táblát lehetne vezetni a fájlok változásáról teljesen automatizáltan, felhasználói hiba kizárásával.
Másik alternatíva lehet mondjuk az FTP log feldolgozása, de ott is ugyan ezt kell végigjátszani.
Egyébként érdekes kérdés, kíváncsi vagyok valaki előáll e pontosabb megoldással.
Update:
Mire leírtam eszembe jutott egy talán jobb lehetőség:
A felépítés ugyan ez lenne mint amit leírtam, annyival érdemes lehet kiegészíteni hogy tárolod az utolsó ellenőrzés idejét, és a fájlok ellenőrzésénél csak olyan fájlokat vizsgálsz amik legutolsó módosításának ideje ettől nagyobb. Ezzel kizárod a változatlan fájlok vizsgálatát. -
DNReNTi
őstag
Ha webes felületen történik a file management akkor egyszerűen csak a fájlművelethez kell kapcsolni egy sql parancsot is, új fájl -> insert, törlés -> delete stb, így folyamatosan naprakész az adatbázis. Ha nem weben hanem pl ftp-n zajlik a file cserebere akkor meg cron-nal érdemes 10-30 percenként futtatni egy szkriptet ami ellenőrzi a file listát, különbözés esetén pedig a megfelelő parancsot végrehajtja. Pl új file a szerveren, ami nincs az adatbázisba, beszúrod, egy file ami ugyan szerepel, de új dátummal, update, file nincs a listában de szerepel az adatbázisban: törlöd a bejegyzést.
-
#739
Sk8erPeter
nagyúr
sonar
#738
Sk8erPeter
nagyúr
Nem gond, dehát érted, miért szopás ez így: mindkettőnknek csak felesleges időpocsékolás az addigi egymás melletti elbeszélés.
Amúgy martonx-nek köszönd, végül ő mondta meg a megoldást.====================================
(#737) martonx : de tudod, mi az, ami ennél SOKKAL rosszabb? Amikor az embernek egy ennél hatványozottan rosszabb tulajdonságokkal rendelkező kollégája van, akinek akárhogy magyarázod el, hogy "b@szki ember, ez így szar" (csak ezt előbb egy finomabb formában), annak akkora pofája és egója van, hogy még azt is megmagyarázza, hogy én miért vagyok egy hülye f@sz, és menjek az anyámba az okoskodásommal (de persze még a főnökkel is vitatkozik) - leegyszerűsítve a szájából áradó mérgező fostenger-áradatot, aminek hatására először azt mondod, hogy ha ezt nem hagyja abba azonnal, megfojtod egy spárgával, egy vezetékes egér kábelével, vagy villát szúrsz a szemébe, vagy csak egy óvatlan pillanatban kidobod az ablakon, nem a földszintről...
de aztán veszel inkább egy nagy levegőt, kimész egy cigire, és úgy döntesz, hogy soha többé nem próbálsz vitába szállni (vagy egyáltalán szóba állni) azzal a gyerekkel, a saját egészséged kímélése érdekében. És máris boldogabban élheted az életed tovább, ignorálván egy életre nem érdemes embert. 
Szóval a lényeg az egészből, hogy a közvetlen, valós tapasztalat, egy, a leírtakhoz hasonló élőlény valóságos látványa és a tőle hallottak ezerszer rosszabbak, mint egy-egy rosszul feltett fórumos kérdés, vagy az alapvetően más véleményekre nyitott, de kezdetben hülyeségeket beszélő emberkék.
-
#736
Sk8erPeter
nagyúr
sonar
#734
Sk8erPeter
nagyúr
Nem, ebben a formában sem érthetőbb, csak már nagyjából sejteni lehetett, hogy mit szeretnél, szerencsére martonx feloldotta a misztikumot...
Elmondom, hogy lehetett volna érteni a kérdésedet egyből: "hogyan tudnám megjeleníteni az Item_Name nevű mezőből lekért rekordoknak csupán az első 4 karakterét?" .. vagy: "van egy Item_Name mezőm az adatbázisban. Hogyan tudnék olyan query-t írni, ami az ebben található rekordoknak csak az első 4 karakterét írja ki?" ... és így tovább....Ehelyett Te mindvégig a 2755-öt és 2756-ot nyomattad, ahelyett, hogy általánosítottad volna, így persze, hogy félreérthető volt.
-
#733
Sk8erPeter
nagyúr
sonar
#732
Sk8erPeter
nagyúr
Hogy mi van?
Nem értem, miért nem jó neked ez?
Nyilván ha nincs, akkor 0 lesz az eredmény, ha meg van, akkor több mint 0...
Szerk.: de ha nagyon szeretnéd a DISTINCT-et használni, akkor azt is megteheted, hogy ezt a query-t használod:
SELECT DISTINCT(1)
FROM `test_table`
WHERE
`Item_Name` LIKE "2755%"
OR
`Item_Name` LIKE "2756%"
Így ha nincs eredmény, akkor lószart sem ad vissza (üres sorok), ha van, akkor meg 1-et...
Bár nem világos, miért nem jó a korábbi. -
#731
Sk8erPeter
nagyúr
sonar
#730
Sk8erPeter
nagyúr
Nem tudom, jól értem-e a kérdésedet, de úgy értelmeztem, hogy azt szeretnéd lekérdezni, vannak-e olyan elemek az Item_Name mezőben, amik 2755-tel vagy 2756-tal kezdődnek.
Ha igen, akkor ezzel a query-vel megkaphatod, hogy mennyi van, ami ezzel a kettővel kezdődik:
SELECT COUNT(*) AS number_of_items
FROM `test_table`
WHERE
`Item_Name` LIKE "2755%"
OR
`Item_Name` LIKE "2756%" -
Jester01
veterán
-
#611
Sk8erPeter
nagyúr
sonar
#610
Sk8erPeter
nagyúr
Bár gondolom azóta megoldódott, de most néztem rá erre a topicra.
Hátha másnál is lesz ilyen, itt van egy lehetséges megoldás: [link]
Itt a problémát észlelő és megoldó hozzászóló ezt a részt:
KEY `gencompanyid` (`gencompanyid`) USING BTREE
lecserélte erre:
KEY `gencompanyid` USING BTREE (`gencompanyid`)
és így nála már működött.
Lehet, hogy MySQL-verziókülönbség az oka.Akkor nálad meg gondolom
KEY `noinol` (`noinol`) USING BTREE
helyett ez kéne:
KEY `noinol` USING BTREE (`noinol`)
Igaz, eddig mindössze háromszor fordult elő, szóval lehet véletlen is.
ez már kiindulási alapnak jó.Mivel nem vagyok linux-ban power user ezért kérdésem lenne fedorában is így működik a dolog?Mert a linux gépek a 
pedigg a fenti query fut le ... most annyit raktam még bele, hogy
de aztán veszel inkább egy nagy levegőt, kimész egy cigire, és úgy döntesz, hogy soha többé nem próbálsz vitába szállni (vagy egyáltalán szóba állni) azzal a gyerekkel, a saját egészséged kímélése érdekében. És máris boldogabban élheted az életed tovább, ignorálván egy életre nem érdemes embert. 
Új hozzászólás Aktív témák
Hirdetés
- Jövedelem
- Leégett az első Radeon a hírhedt 12V-2x6 tápkonnektorral
- Hobby elektronika
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Nintendo Switch 2
- Futás, futópályák
- Gyúrósok ide!
- Építő/felújító topik
- LEGO klub
- A fociról könnyedén, egy baráti társaságban
- További aktív témák...
- Olcsó Gamer PC-Számítógép! Csere-Beszámítás! Xeon 5650X / GTX 1650 / 24GB DDR3 / 250SSD+500HDD
- HIBÁTLAN iPhone 13 mini 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3319
- Samsung Galaxy A16 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! Intel Core i7 4770 4mag 8szál processzor garanciával hibátlan működéssel
- MacBook Pro 13, 14, 15, 16, MacBook Air M1, M2 M3 M4 bill magyarosítás lézerrel / sapkacserével
Állásajánlatok
Cég: FOTC
Város: Budapest