partido contra Mysql ... vs simple como "%% término"

¿Qué hay de malo en:partido contra Mysql ... vs simple como "%% término"

$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] .'%"');

y luego consultar la base de datos para recuperar los resultados en un cierto orden, en lugar de utilizar el myisam de sólo partido sql ... contra?

¿Sorprendería el rendimiento dramáticamente?

Fuente

2009-12-24 Gal

por cierto Sé que este tema ha sido maltratado y abusado totalmente. – Gal

La diferencia está en el algoritmo que MySQL utiliza detrás de escena para encontrar sus datos. Las búsquedas de texto completo también le permiten ordenar según la relevancia. La búsqueda LIKE en la mayoría de las condiciones hará un escaneo completo de la tabla, por lo que dependiendo de la cantidad de datos, podría ver problemas de rendimiento con ella. El motor de texto completo también puede tener problemas de rendimiento cuando se trata de grandes conjuntos de filas.

En una nota diferente, una cosa que agregaría a este código es algo para escapar de los valores de explosión. Tal vez una llamada a mysql_real_escape_string()

Fuente

2009-12-24 02:01:46

¿Alguna idea que dificulte más el rendimiento? y sí, por supuesto, tiene razón, una mysql_real_escape_string() estaría bien ubicada allí. – Gal

En mi experiencia personal, las búsquedas tienden a ser más intensivas en rendimiento. Esto es más cierto cuando se usan comodines que no permitirán que mysql optimice la consulta para que tengamos un índice en el campo. –

Se puede extraer de mi reciente presentación que hice por la Universidad de MySQL:

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

diapositivas también están aquí:

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

En mi prueba, usando LIKE '%pattern%' fue más de 300 veces más lento que utilizando un índice MySQL FULLTEXT. Mis datos de prueba fueron de 1,5 millones de publicaciones del volcado de datos de StackOverflow de octubre.

Fuente

2009-12-24 03:28:09

Me temo que su método de comparación fue un poco incorrecto. LIKE es más lento cuando busca en tablas grandes pero no afecta la velocidad de inserción de datos en la base de datos. Las coincidencias tienen un mejor rendimiento cuando estás buscando pero afecta seriamente la velocidad de inserción porque cada INSERTAR o ACTUALIZAR requiere reindexación. Entonces depende del desarrollador qué operación tiene mayor prioridad. –

Comparé el rendimiento de indexar un conjunto de datos existente, pero tiene razón. No probé el rendimiento de insertar más datos. No creo que la indexación de texto completo de MySQL deba reindexar todo el conjunto de datos cuando se inserte, por lo que sé, Sphinx solo necesita hacerlo. –

Hasta donde yo sé, los índices de texto completo de MySQL se reindexan automáticamente después de cada operación de inserción o actualización. Si me equivoco, ¿podría decirme por qué, en algunos casos, los índices de texto completo hacen que la inserción sea dos veces más lenta? Btw, una nueva versión de Sphinx admite la indexación en tiempo real, pero en la mayoría de los casos este tipo de índices son menos eficientes. –

partido contra Mysql ... vs simple como "%% término"

Respuesta

Cuestiones relacionadas