partita Mysql ... contro vs semplice come "% termine%"

Cosa c'è di sbagliato con:partita Mysql ... contro vs semplice come "% termine%"

$term = $_POST['search']; 

function buildQuery($exploded,$count,$query) 
{ 
    if(count($exploded)>$count) 
    { 
     $query.= ' AND column LIKE "%'. $exploded[$count] .'%"'; 
     return buildQuery($exploded,$count+1,$query); 
    } 
    return $query; 
} 

$exploded = explode(' ',$term); 
$query = buildQuery($exploded,1, 
'SELECT * FROM table WHERE column LIKE "%'. $exploded[0] .'%"');

e poi interrogare il db per recuperare i risultati in un certo ordine, invece di utilizzare il MyISAM-only sql match ... contro?

Riuscirà a perdere tempo drammaticamente?

fonte

2009-12-24 Gal

btw so che questo argomento è stato totalmente infestato e maltrattato. – Gal

La differenza sta nell'algoritmo che MySQL utilizza dietro le quinte per trovare i dati. Le ricerche fulltext ti consentono anche di ordinare in base alla pertinenza. La ricerca LIKE nella maggior parte delle condizioni eseguirà una scansione completa della tabella, pertanto, a seconda della quantità di dati, è possibile riscontrare problemi di prestazioni. Il motore di testo completo può inoltre presentare problemi di prestazioni quando si utilizzano insiemi di righe di grandi dimensioni.

Su una nota diversa, una cosa che vorrei aggiungere a questo codice è qualcosa che sfugge ai valori esplosi. Forse una chiamata a mysql_real_escape_string()

fonte

2009-12-24 02:01:46

quindi qualche idea che potrebbe ostacolare di più le prestazioni? e sì, certo che hai ragione, un mysql_real_escape_string() sarebbe ben posizionato lì. – Gal

Nella mia esperienza personale, le ricerche tendono ad essere più intensi in termini di prestazioni. Questo è più vero quando si usano le wild card che non permetteranno a mysql di ottimizzare la query su di noi un indice sul campo. –

È possibile controllare il mio recente presentazione che ho fatto per MySQL Università:

http://forge.mysql.com/wiki/Practical_Full-Text_Search_in_MySQL

diapositive sono anche qui:

http://www.slideshare.net/billkarwin/practical-full-text-search-with-my-sql

Nella mia prova, utilizzando LIKE '%pattern%' era più di 300 volte più lento di un indice MySQL FULLTEXT. I miei dati di test erano 1,5 milioni di post dal dump di dati di StackOverflow di ottobre.

fonte

2009-12-24 03:28:09

Ho paura che il tuo metodo di confronto fosse un po 'sbagliato. LIKE è più lento durante la ricerca in tabelle grandi, ma non influisce sulla velocità di inserimento dei dati nel DB. Le corrispondenze hanno prestazioni migliori durante la ricerca, ma influiscono seriamente sulla velocità di inserimento poiché ogni INSERT o UPDATE richiede una reindicazione. Quindi è compito dello sviluppatore che l'operazione abbia una priorità più alta. –

Ho confrontato le prestazioni dell'indicizzazione di un set di dati esistente, ma hai ragione non ho testato le prestazioni di inserimento di più dati. Non penso che l'indicizzazione fulltext di MySQL debba reindicizzare l'intero set di dati quando si inserisce, per quanto ne so, solo Sphinx ha bisogno di farlo. –

Per quanto ne so, gli indici fulltext di MySQL vengono reindirizzati automaticamente dopo ogni operazione di inserimento o aggiornamento. Se sbaglio, potresti dirmi un motivo per cui in alcuni casi gli indici fulltext rendono l'inserimento due volte più lento? Btw, una nuova versione di Sphinx supporta l'indicizzazione in tempo reale, ma nella maggior parte dei casi questi tipi di indici sono meno efficienti. –

partita Mysql ... contro vs semplice come "% termine%"

risposta

Problemi correlati