Лесно можем да избием всички mysql заявки на определн потребител с елегантното:
select concat('KILL ',id,';') from information_schema.processlist where user='user123';
Заместваме user123 с желаният от нас потребител и изпълняваме в mysql и всичко е ОК 🙂
От миналата седмица закупихме Fantastico Deluxe инсталатора, който по мое скромно мнение е един от най приличните за CPanel сървъри. Инсталирахме го тествахме и всичко мина гладко. Днес един клиент ми съобщи за проблем с енкодинга на wordpress инсталация. Прегледах нещата и веднага лъсна проблема базите бяха с енкодинг по подразбиране Latin1 вместо UTF8 като се предполагаше. Още по забавното е, че в phpmyadmin-а пише че се използва UTF8 по подразбиране, драма. Реших да прегледам файловете на Fantastico-то да видя дали няма някъде където мога да окажа настройките за базите данни по подразбиране на пръв поглед не видях нищо. След това нещо ме текна да видя какво има в my.conf-а и какво да видя нямаше съответните настройки във конфигурация и всичко си пали на каквото му е зададено по подразбиране. Mysql сървъра е хардкоднат да ползва UTF8 ако не е конфигуриран с други настройки и Fantastico-то явно е с Latin1 ( което е доста глупаво решение). Решението както винаги е тривиално добавят се 2 реда в [mysqld] часста за да се окаже UTF8 като кодировка по подразбиране и всичко заспива 🙂
character-set-server=utf8
collation-server=utf8_general_ci
Нямам никаква идея поради каква причина съм пропуснал тези настройки при положение че си играх да правя няколко „фини“ настройки на mysql-а.
Преди няколко дни излезе XAMPP 1.8.0 вчера след надграждане от версия 1.7.7 имах доста интересен проблем. Phpmyadmin-а не ми се отваряше и изгърмяваше със 403
Access forbidden!
New XAMPP security concept:
Access to the requested object is only available from the local network.
This setting can be configured in the file „httpd-xampp.conf“.
Веднага отворих httpd-xampp.conf който при мен се намира в /opt/lampp/etc/extra/, на пръв поглед всичко изглеждаше наред. Правилата за локалната мрежа бяха наред. Отделно че отварях от localhost. WTF ??? Погледнах log-а гледам че достъпа ми е отрязан от конфигуацията. Тука вече нещата ме ахнаха и честно казано донякъде малко на късмет открих проблема. След като преглеждах httpd.conf-а видях в Allow/Deny клаузите един последен ред Require all granted. О да еврика. Това е новия контролен механизъм който влезе в apache 2.4.x. С него се дава достъп или се отказва такъв на всички изискани, в общи линии се имитира Allow/Deny функционалността :). За да поправим проблема добавяме Require all granted в директивите за папката /opt/lampp/phpmyadmin. След промените при мен изглежда така
<Directory „/opt/lampp/phpmyadmin“>
AllowOverride AuthConfig Limit
Order allow,deny
Allow from all
Require all granted
</Directory>
Вианги може да се пробва и друга дивоти, например да се преименува папката phpmyadmin на нещо други и да се направи alias към не. Но е по грозно и не особено смислено 🙂
p.s Питаха ме защо ползвам XAMPP а не чиста инсталация на всички компоненти както си ги е моя Debian родил – отговорът е много много прост – МЪРЗЕЛ. Мързи ме да напиша няколко команди после да си пипна конфовете и прочие. Доста по лесно е сваляш целия пакет разархивираш и палиш 😉
Преди известно време бях писал за MySQL Full Text Search 🙂 Днес имах много интересно преживяване с една заявка. В общи линии заявката търси за резултати който липсват друга таблица. Един основне Select и един sub select в WHERE частта на заявката. В общи линии скелета и е
SELECT DISTINCT ( `field` ) FROM `table1` WHERE `someID` =44 AND `firsTextField` NOT IN ( SELECT DISTINCT ( `secondTextField` ) FROM `table2` WHERE `otherID` =44 )
В общи линии елементарна заявка. Написах я за 30 сек пускам я и зацикли машината. След дълго и търпеливо чакане от моя страна или по точно ~43 сек . Ми се изплю резултат lol . Пффф лудница. Влизам в машината гледам процесора е нормално натоварен почти в idle състояние. Шок и ужас. Пускам пак заявката пак същия резултат. Fuck WTF. Пускам explain на заявката и всичко лъсна – второто поле secondTextField е само full text search без index, а там табличката е скромна от около 35к реда. Кой да чете – full text search не е индекс. Вече е ясен проблема набързо едно
ALTER TABLE `links` ADD INDEX ( `linkUrlID` )
И нещата си дойдоха на местата Query took 0.0005 sec 😀
Внимавайте как си слагате индексите от тях ви зависи маргинално скоростта на заявката.
p.s Като цяло аз съм си крив за горната ситуация не само защото липсва индекс ами защото не ползва full text search метода 😀
Вчера след обновяване на версията на mysql, server-ът ми започна да ми крещи, че има табличка, която не е била затворена чисто и има нужда от поправка и прочие. Блах, коя ще е тая таблица, все пак са ми около 30-тина на тоя сървър. Единият вариант е да видите в log-овете какво пише по въпроса и да пуснете поправка на съответната таблица или другият вариант – далеч по-добрият – е да пуснете поправка, проверка и оптимизиране на всички таблици. За тази цел ще използвам mysqlcheck инструмента. Общо взето вариантите в случая са като и двете коменди са синонимни една на друга:
mysqlcheck -Aor -u root -p mysqlcheck -u root -p --auto-repair --check --optimize --all-databases
Общо взето, която и от двете команди да използвате, ефектът ще е еднакъв – ароматична поправка, проверка и оптимизация на всички таблици. След като напишете която и да е от двете команди, ще бъдете попитани за root паролата на mysql server-a ви.