Pentru a schimba domeniul în WordPress este unele dureri. Recent am avut de a face mai multe lucruri se întâmplă deja sporturi rapid 😀 . Dacă eu pot sumariziram pași sunt 2 – în mod natural, fără a muta fișiere, setări în cazul în care modificările în întregime de găzduire.

1. Schimba URL-ul vechi la noul – Lucruri care fac aici cu banal. Deschideți fișierul wp-config.php și puneți-l în aceste 2 rând

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

După cum înlocuiți http://example.com cu noul.

2. Până în prezent, atât de bine acum site-ul se deschide de lucru url-lea, dar conținutul încărcat, cum ar fi imagini, documente și deci nu sunt vizibile. Aici are deja o provocare urât. Ele trebuie să înlocuiască vechea adresă URL-lea într-o nouă bază de date. Era teribil proces anevoios mai ales pentru incepatori, care nu fac bine cu sintaxa SQL, но вече има доста приятен скрипт searchreplacedb2, ceea ce face incomod pentru tine. Utilizare este banal – încărcați-l în directorul rădăcină în care WordPress pagina și deschideți-l în browser-ta. След това следвате стъпките като първо ще ви пита за потребителско име и парола който е взел от вашия wp-config.php и след това ще ви пита за новото и старото url. След последната стъпка ще се наложи да поизчакате при мен отнемаше средно 40сек -50сек.

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

Image representing MySQL as depicted in CrunchBase

Ceva timp în urmă am scris despre MySQL Full Text Search 🙂 Azi am avut o foarte interesant experience cu o interogare. În General, interogarea este în căutarea pentru rezultate care lipsesc alt tabel. A selecta o sub osnovne şi selectaţi în partea în care aplicarea. În General, scheletul şi este

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

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

În General, o simpla cerere. Am scris-o pentru 30 SEC de presă ei şi blocat mașina. După o lungă şi cu răbdare de aşteptare pe partea mea sau doar ~ 43 sec . Scuipat lol meu de scor . Pfff Madhouse. Introduceţi în maşină în căutarea CPU în mod normal este încărcată aproape la starea inactiv. Şoc şi uimire. Executaţi interogarea încă din nou acelaşi rezultat. Dracu WTF. Executa interogarea şi explica tot ce am – al doilea câmp este doar secondTextField căutare după text complet Nu index, şi există o tavă modest de aproximativ 35 k linie. Ce să citească – indexul de căutare Full text nu este. Este deja clar problema reală rapid unul

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

Şi lucrurile nap locuri de interogare a luat 0.0005 sec 😀

Fii atent cum ai pus indicii de ele depinde de rata marginală de aplicare.

p. s ansamblul greşită despre situaţia de mai sus nu sunt numai pentru că acesta lipseşte un index, deoarece nu folosind full text search metoda 😀

Consolidată prin Zemanta

Astăzi am jucat pentru a optimiza un proces lent SQL Aplicarea genul

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

În cazul în care este problema acum aici – ultima parte "% cuvânt%’ și în chiar mai multe caractere specifice % înainte de cuvântul, care fac. simbolul wildcard % ,înainte de orice valoare, face în mod direct ne interoga direct în lent, deoarece în acest fel aplicația ne împiedică să utilizeze indici de câmp. Deciziile ca întotdeauna, dar nu întotdeauna clar 😆 global MySQL Ei au o soluție la această problemă căutare fulltext câmp de indexare. Cum se schimbă terenul are o mulțime de documente scrise, dar graba va descrie modul de a schimba cererea de top, pentru că vom ajunge la o mică dramă în cele din urmă. Sledka ca domeniu fulltext de mai sus se aplică, cerere trebuie să fie modificări ale tipului de:

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

Prin urmare, structura este evidentă și are nevoie de nici o discuție inutilă. Interogarea de mai sus va intra în vigoare, în cazul în care cuvântul, pentru a face o solicitare de cel puțin 4 simboluri, Valoarea implicită este, dacă doriți să modificați trebuie să specificați valoarea, която желаете в my.cnf в частта [mysqld] declarație ft_min_word_len= 3 sau 2, 1 не е добър избор очевидно 😉 . După ce schimbați valoarea și mysql repornire server o necesitate de a face reparații în tabelele, pentru ca noua indexare intră în vigoare. Până în prezent, totul clar: a face modificări, restabili, rebildvam indici și de a face cerere și se întoarce meu 0 Verificare cu ordinul 😀

SHOW VARIABLES

Eu văd că valorile, M-am întrebat în vigoare, rebildvam din nou indexurile – același rezultat. 🙄 neplăcut, foarte inconfortabil. De aici încolo a început un blestemelor mare și zgâriere cheia vărsat 😀, care a fost destul de, destul de interesant. în ansamblu, Am început să citesc documentație nu știu ce drum și a ajuns la un pasaj interesant

Such a technique works best with large collections (de fapt, a fost reglat cu atenție acest mod). Pentru tabelele foarte mici, distribuție cuvânt nu reflectă în mod adecvat valoarea lor semantică, iar acest model poate produce uneori rezultate bizare. De exemplu, deși cuvântul "MySQL" este prezent în fiecare rând din tabelul de articole prezentat mai devreme, o căutare pentru cuvântul produce nici un rezultat

ГРЕДА 😳 Дам табличката ми беше малка – Cu toate acestea, a fost un test de. Aplicația noastră într-un tabel mare peste 2 000 000 ordine și acolo lucrurile au dormit. Ei bine, problema acum clar. Pentru a lua o decizie clară, Voi menționa pe scurt, care acceptă căutarea full text 3 modul avansat BOOLEAN , EXPRESII și LIMBA NATURAL ca ultima lucrare implicit. Pentru moduri pot verifica documentație, Voi explica 2-3 Cuvintele BOOLEAN, deoarece este cheia. Ea susține operatorii logici astfel ȘI, SAU , NU și așa mai departe și se pot face unele magie cu expresii populare, au una, nici o alta, etc.. Se menține și simboluri *, care este echivalent cu un simbol joker % Este util 😉, în cazul în care termenul de căutare este mai mică decât lungimea ft_min_word_len sau tăvi mici ;). Cel puțin pentru mine o masă cu privire la 100 comanda face treaba perfecta. Lăsând numai a se vedea și completat cerere:

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

Aici vine momentul dacă indexarea funcționează cu caractere wildcard – răspunsul este că nu știu. Принципно мисля, че да, защото не е казано друго в документацията, но в документацията очевидно не се казват или показват много неща 😀

Consolidată prin Zemanta