Лесно можем да избием всички mysql заявки на определн потребител с елегантното:

select concat('KILL ',id,';') from information_schema.processlist where user='user123';

Заместваме user123 с желаният от нас потребител и изпълняваме в mysql и всичко е ОК 🙂

Mivel a múlt héten vásárolt Fantastico Deluxe telepítő, amely az én szerény véleményem az egyik legtisztességesebb az CPanel szerverek. Telepítettük és teszteltük minden simán ment. Ma egy ügyfél mesélt egy probléma a kódolás wordpress telepítés. Keresztül a dolgokat, és azonnal sütött probléma bázisok voltak Latin1 kódoló alapértelmezett UTF8 helyett feltételezve. Még több móka, hogy phpmyadmin-írta és az alapértelmezett UTF8, dráma. Úgy döntöttem, hogy vizsgálja felül a fájlokat a Fantastico-, hogy hátha van valahol, hol találom magam beállítások adatbázis alapértelmezés szerint először nem látott semmit. Aztán valami TEKNA, hogy lássam, mi van my.conf-és mit kell látni nem volt megfelelő beállításokat a konfigurációs és minden villanyt, amit az alapértelmezett beállítás,. MySQL szerver hardkodnat használni UTF8 ha helytelenül van beállítva az egyéb beállításokat, és Fantastico-it nyilvánvalóan Latin1 ( ami elég hülye döntés). Решението както винаги е тривиално добавят се 2 реда в [mysqld] часста за да се окаже UTF8 като кодировка по подразбиране и всичко заспива 🙂

character-set-server=utf8
collation-server=utf8_general_ci

Нямам никаква идея поради каква причина съм пропуснал тези настройки при положение че си играх да правя няколкофининастройки на mysql-а.

Növeli Zemanta

Néhány nappal ki XAMPP 1.8.0 tegnap, miután frissítés verzió 1.7.7 Volt elég érdekes probléma. Phpmyadmin-és nem nyitja ki, és harsogva 403

Hozzáférés megtagadva!


Új XAMPP biztonsági koncepció:

Hozzáférés a kért objektum csak a helyi hálózaton.

Ez a beállítás lehet állítani a fájl “httpd-xampp.conf”.

Azonnal kinyitotta httpd-xampp.conf ami nekem az / opt / lampp / etc / extra /, Első pillantásra minden látszott finom. A szabályok a helyi hálózat között voltak. Eltekintve a nyitó localhost. WTF ??? Megnéztem a log-és látom, hogy a hozzáférés le van vágva a konfiguatsiyata. Itt most mi ziháltam és őszintén valamivel kevesebb szerencsével találta meg a problémát. Után megy át a httpd. conf, és látta a enged/tagad záradékok egy utolsó sorban Megköveteli az összes megadott. Oh EUREKA. Ez egy új ellenőrzési mechanizmus lépett Apache 2.4.x. Ez ad hozzáférést megtagadó vagy az ilyen finom, Alapvetően utánozza engedélyezése / tiltása funkciót :). A probléma hozzá szükség minden megadott, a/opt/lámpaoszlop/phpmyadmin mappa. Miután a változás bennem külleme

<Könyvtár “/opt / lampp / phpmyadmin”>
AllowOverride AuthConfig Limit
rendelés lehetővé,tagadni
Hagyjuk az összes
Megköveteli az összes megadott
</Könyvtár>

 

Viangi lehet próbálni egy másik vad, például a mappa átnevezéséhez phpmyadmin valami más, és nem álnevet. De ez csúnya és nem túl értelmes 🙂

p.s Megkérdezték tőlem, hogy miért használ XAMPP nem tiszta telepítés valamennyi komponens, mint ők az én Debian szül – a válasz az, tényleg nagyon egyszerű – LUSTASÁG. Én túl lusta, hogy írjon több parancs, akkor kap a konfovete stb.. Nagyon könnyű az veszi a egész pack razarhiviraš és a könnyű 😉

Növeli Zemanta

Image representing MySQL as depicted in CrunchBase

Néhány évvel ezelőtt írtam MySQL teljes szöveges keresés 🙂 Ma már egy nagyon érdekes tapasztalat-val egy lekérdezés. Általában a lekérdezés eredményeit, hogy hiányzik egy másik táblában keres. Válasszon egy al osnovne és részben válassza ki hol az alkalmazás. Általában, a csontváz és

SELECT DISTINCT (
`field`
)
FROM `table1`
WHERE `someID` =44
AND `firsTextField` NOT
IN (

SELECT DISTINCT (
`secondTextField`
)
FROM `table2`
WHERE `otherID` =44
)

Általában, egy egyszerű kérés. Írtam, hogy a 30 S engedje őt, és megragadt a gép. Miután egy hosszú és türelmesen vár a részemről, vagy csak ~ 43 mp . Köpni a pontszám lol . Pfff bolondokháza. Adja meg a gép látszó CPU szabályosan megterhelt szinte üresjárati állapotban. Sokk és félelem. A lekérdezés futtatásával újra mindig ugyanazt az eredményt. WTF fasz. Futtassuk a lekérdezést, és mindent megmagyaráz én – a második pedig csak secondTextField teljes szöveges keresés Nincs index, és van egy szerény tálca körülbelül 35 k-vonal. Mit olvas – teljesszöveges keresési index nincs. Már most világos, a probléma valódi gyors

ALTER TABLE `links` ADD INDEX ( `linkUrlID` ) 

És a dolgok lekérdezésének helyek 0.0005 MP 😀

Legyen óvatos, hogyan tesz az indexek közülük függ a marginális ráta az alkalmazás.

p. s egész tévedtem a fenti helyzet nem csak azért, mert hiányzik az index, mert nem használja a teljes szöveges keresési módszer 😀

Növeli Zemanta

Tegnap frissítése után a MySQL verzió, szerver látott velem kiabálni kezdett velem, hogy van egy táblázat, amely nem volt lezárva tisztán és javításra szorul, stb. blabla, mi lesz ebben a táblázatban, Még ott van a 30-valami ezen a szerveren. Az egyik lehetőség az, hogy a log-ok, mit mond a kérdés, és futás javítás az asztal vagy a másik lehetőség – messze jobb – Ez fut javítás, ellenőrzése és optimalizálása az összes táblát. Ez fogja használni mysqlcheck eszköz. Общо взето вариантите в случая са като и двете коменди са синонимни една на друга:

mysqlcheck -Aor -u root -p

mysqlcheck -u root -p --auto-repair --check --optimize --all-databases

Общо взето, която и от двете команди да използвате, ефектът ще е еднакъвароматична поправка, проверка и оптимизация на всички таблици. След като напишете която и да е от двете команди, ще бъдете попитани за root паролата на mysql server-a ви.