Image representing MySQL as depicted in CrunchBase

Antaŭ iom da tempo mi skribis MiSQL Plena Teksto-Serĉo 🙂 Hodiaŭ mi havis tre interesan sperton kun unu peto. Ĝenerale, la enketo serĉas rezultojn, kiuj mankas en alia tablo. Unu baza Elekto kaj unu subelekto en la KIE parto de la enketo. Ĝenerale, la skeleto estas

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

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

Esence simpla pridemandado. Mi verkis ĝin por 30 sek Mi kuras ĝin kaj la maŝino buklas. Post longa kaj pacienca atendo miaflanke aŭ pli precize ~ 43 sek . Mi elmetis la rezulton lol . Pffff-frenezulejo. Mi eniras la maŝinon, rigardante, ke la CPU estas normale ŝarĝita preskaŭ en malfirmeco. Ŝoko kaj teruro. Mi kuras la demandon denove la saman rezulton. Freneza WTF. Mi kuras klarigas la demandon kaj ĉio brilas – La dua kampo duaTextField estas nur plena teksto-serĉo sen indekso, kaj tie la plato estas modesta je ĉirkaŭ 35k linioj. Kiu legi – plena teksta serĉo ne estas indekso. La problemo estas rapide klara

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

Kaj aferoj falis en loko Query prenis 0.0005 sekundo 😀

Atentu, kiel vi forigas la indeksojn, la rapideco de la enketo dependas de vi marĝene.

p.s Ĝenerale mi kulpigas la ĉi-supran situacion ne nur ĉar ĝi mankas indekson, sed ĉar ĝi ne uzas la plenan tekstan serĉan metodon 😀

Plibonigita de Zemanta