Ŝanĝi vian domajnon en WordPress estas iu doloro. Ĵus mi devis fari plurajn aferojn jam okazanta rapida sportoj 😀 . Se mi povas sumariziram paŝoj estas 2 – nature sen movi dosierojn, fiksojn se ŝanĝoj tute retprovizanton.

1. Ŝanĝi la malnovan URL al la nova – Tion mi tie kun bagatela. Malfermu vian wp-config.php dosieron kaj metas ĝin en ĉi tiuj 2 vico

define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');

Kiel anstataŭi http://example.com kun via nova.

2. Ĝis nun tiel bona nun retejon malfermas url-a laboro sed alŝutita enhavo kiel ekzemple bildoj, dokumentoj kaj do ne videbla. Jen ĝi jam havas aĉan defio. Ili devas anstataŭi la malnovan URL-a en nova datumbazo. Estis terure ĝena procezo speciale por komencantoj, kiu ne faras bonon al SQLa sintakso, но вече има доста приятен скрипт searchreplacedb2, kion faras malkomforta por vi. Uzo estas triviala – alŝutu ĝin al la radika dosierujo kie la wordpress via paĝo kaj malfermu ĝin en la retumilo-via. След това следвате стъпките като първо ще ви пита за потребителско име и парола който е взел от вашия wp-config.php и след това ще ви пита за новото и старото url. След последната стъпка ще се наложи да поизчакате при мен отнемаше средно 40сек -50сек.

Това е във общи линии нищо трудно или супер сложно.

Image representing MySQL as depicted in CrunchBase

Преди известно време бях писал за MySQL Plena Teksto Serĉo 🙂 Днес имах много интересно преживяване с една заявка. В общи линии заявката търси за резултати който липсват друга таблица. Един основне 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 метода 😀

Plibonigita per Zemanta

Hodiaŭ mi ludis optimumigi malrapida SQLa Apliko de la genro

SELECT * FROM 'table' WHERE `field` LIKE '%word%'

Kie estas la problemo nun tie – la lasta parto '% word%’ kaj eĉ pli specifaj karakteroj % antaŭ la vorto, farantojn. ĵokero simbolo % ,antaŭ ajna valoro, rekte igas nin konsulti rekte en malrapida, ĉar tio la apliko haltas nin uzi indeksoj Kampo. Decidoj kiel ĉiam, sed ne ĉiam klara 😆 Entute MySQL Ili havas solvon por tiu problemo plenteksta serĉo indeksado kampo. Kiel ŝanĝi la kampo havas multajn skribita dokumentado, sed rapidado priskribos kiel ŝanĝi la supro peto, ĉar ni ricevos por iom dramo finfine. Sledka kiel aplikebla plena teksto kampo supre, apliko devas esti ŝanĝoj en la tipo:

SELECT * FROM `table` WHERE MATCH (field) AGAINST ('word')

Do la strukturo estas evidenta kaj ne bezonas nenecesa diskuto. La supre sercxmendo ekvalidos, se la vorto, cxar vi fari peton almenaŭ 4 simboloj, La defaŭlta valoro estas, se vi volas modifi devas specifi la valoro, която желаете в my.cnf в частта [mysqld] deklaracio ft_min_word_len= 3 aŭ 2, 1 не е добър избор очевидно 😉 . Post vi ŝanĝas la valoron kaj rekomenco mysql servilo-bezono fari riparon en via tabloj, ordo por la nova indeksado ekvalidos. Ĝis nun ĉio klara: fari ŝanĝojn, reset, rebildvam indeksoj kaj fari mian deziron kaj revenoj 0 Kontrolanta kun la celo 😀

SHOW VARIABLES

Mi vidas ke la valoroj, Mi demandis en forto, rebildvam denove indeksoj – sama rezulto. malagrabla 🙄, tre malkomforta. De tie sur ĝi komencis grandan malbenado gratante la ŝlosilo al la barako 😀 kiu estis tute, sufiĉe interesa. sur la tuta, Mi komencis legi dokumentaron ne scias kiun vojon kaj venis al interesa paŝo

Such a technique works best with large collections (fakte, estis zorge agordita tiel). Por tre malgrandaj tabloj, vorto distribuo ne adekvate reflekti ilia semantika valoro, kaj tiu modelo povas foje produkti bizaraj rezultoj. Ekzemple, kvankam la vorto "MySQL" ĉeestas en ĉiu vico de la artikoloj tablo montris pli frue, serĉo por la vorto ne produktas rezultojn

ГРЕДА 😳 Дам табличката ми беше малка – Tamen ĝi estis testo. Nia apliko en granda tablo super 2 000 000 ordon kaj aferoj dormis. Nu nun klara problemo. Fari klaran decidon, Mi mencios koncize, kiu elportu tekstoserĉon 3 altnivela reĝimo Buleaj , ESPRIMOJ kaj NATURA LINGVO kiel la lasta laboro defaŭlte. Por modoj povas kontroli dokumentado, Mi klarigos al 2-3 думи за BOOLEAN понеже в него е разковничето. Той поддържа логически оператори от типа AND, OR , NOT и прочие и може да се правят разни магии с търсените фрази, да има една, да няма друга и прочие. Поддържа и символа *, който е еквивалент на wildcard символа % 😉 Той е полезен, когато търсената дума е под дължината на ft_min_word_len или за малки таблички ;). Поне при мен на таблица с около 100 реда върши идеална работа. Остана само да видим и завършената заявка:

SELECT * FROM `table` WHERE MATCH (field)
AGAINST ('*word*' IN BOOLEAN MODE)

Тука вече идва момент дали ни работи индексирането с wildcard символаотговорът е не знам. Принципно мисля, че да, защото не е казано друго в документацията, но в документацията очевидно не се казват или показват много неща 😀

Plibonigita per Zemanta