Да сменяш домейн във WordPress си е известна болка. Напоследък ми се наложи да направя няколко такива и вече нещата се случва спортно бързо 😀 . Ако мога да сумаризирам стъпките са 2 – естествено без местенето на файловете, настройките ако се сменя изцяло хостинга.
1. Промяна на старото URL със новото – тука нещата са тривиални. Отваряте си wp-config.php файлът и във него поставяте следните 2 реда
Като замествате http://example.com със вашият нов.
2. До тук добре вече сайтът се отваря url-тата работят но каченото съдържание като картинки, документи и прочие не се вижда. Тука вече се налага по груба намеса. Трябва да се заместят старите url-та със новите във базата данни. Това беше ужасно неприятен процес особено за начинаещи потребители, които не се справят добре със SQL синтаксисът, но вече има доста приятен скрипт searchreplacedb2, който прави всичко неприятно вместо вас. Използването му е тривиално – качвате го във основната директория където се намира wordpress страницата ви и го отваряте през browser-а си. След това следвате стъпките като първо ще ви пита за потребителско име и парола който е взел от вашия wp-config.php и след това ще ви пита за новото и старото url. След последната стъпка ще се наложи да поизчакате при мен отнемаше средно 40сек -50сек.
Това е във общи линии нищо трудно или супер сложно.
Преди известно време бях писал за 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 метода 😀
Днес си играх да оптимизирам една бавна SQL заявка от вида
SELECT * FROM 'table' WHERE `field` LIKE '%word%'
Къде е проблемният момент тука – последната част ‘%word%’ и в още по-голяма конкретност знака % преди думата, за която правим. Wildcard символът % ,преди която и да е стойност, директно ни превръща заявката директно в бавна, защото по този начин заявката ни спира да ползва индекси на полето. Решения както винаги има, но не винаги са ясни 😆 Общо взето MySQL си имат решение на тоя проблем с fulltext search индексиране на полето. Как става смяната на полето има много написано в документацията, но набързо ще опиша как се променя горната заявка, защото ще стигнем и до една малка драма накрая. Следка като приложим fulltext на полето горе, заявката трябва да се промени във вида:
SELECT * FROM `table` WHERE MATCH (field) AGAINST ('word')
Така структурата е очевидна и няма нужда от излишна дискусия. Горната заявка ще влезе в сила, ако думата, за която правите заявка е поне 4 символа, по подразбиране е това стойността, ако искате да я модифицирате трябва да укажете стойността, която желаете в my.cnf в частта [mysqld] с декларацията ft_min_word_len=3 или 2, 1 не е добър избор очевидно 😉 . След като смените стойността и рестартирате mysql server-a трябва да направите repair на таблиците си, за да може новото индексиране да влезе в сила. До тук всичко ясно: правя промените, рестартирам, ребилдвам индексите и правя заявката и ми връща 0 реда 😀 Проверявам с
SHOW VARIABLES
Виждам че стойностите, който съм задал са влезли в сила, ребилдвам пак индексите – същия резултат. 🙄 Неприятно, много неприятно. От тук нататък започна едно голямо ругаене и ровене за ключа за бараката 😀 Който се оказа доста, доста интересен. Като цяло, като започнах да чета документацията за не знам кой път и стигнах до един интересен пасаж
Such a technique works best with large collections (in fact, it was carefully tuned this way). For very small tables, word distribution does not adequately reflect their semantic value, and this model may sometimes produce bizarre results. For example, although the word “MySQL” is present in every row of the articles table shown earlier, a search for the word produces no results
ГРЕДА 😳 Дам табличката ми беше малка – все пак беше тестова. Наших заявката в една голяма таблица с над 2 000 000 реда и там нещата заспаха. Добре вече е ясен проблемът. За да стане ясно решението, ще спомена накратко, че full text search поддържа 3 разширени режима BOOLEAN , EXPRESSIONS и NATURAL LANGUAGE като последния работи по подразбиране. За различните режими може да проверите документацията, аз ще обясня с 2-3 думи за BOOLEAN понеже в него е разковничето. Той поддържа логически оператори от типа AND, OR , NOT и прочие и може да се правят разни магии с търсените фрази, да има една, да няма друга и прочие. Поддържа и символа *, който е еквивалент на wildcard символа % 😉 Той е полезен, когато търсената дума е под дължината на ft_min_word_len или за малки таблички ;). Поне при мен на таблица с около 100 реда върши идеална работа. Остана само да видим и завършената заявка:
SELECT * FROM `table` WHERE MATCH (field)
AGAINST ('*word*' IN BOOLEAN MODE)
Тука вече идва момент дали ни работи индексирането с wildcard символа – отговорът е не знам. Принципно мисля, че да, защото не е казано друго в документацията, но в документацията очевидно не се казват или показват много неща 😀
