Come viene implementato LIKE?

Qualcuno può spiegare come viene implementato l'operatore LIKE negli attuali sistemi di database (ad esempio MySQL o Postgres)? o mi punta ad alcuni riferimenti che lo spiegano?

L'approccio ingenuo sarebbe quello di ispezionare ogni record, eseguendo un'espressione regolare o una corrispondenza di stringa parziale sul campo di interesse, ma ho la sensazione (speranza) che questi sistemi facciano qualcosa di più intelligente.

No, è praticamente quello che stanno facendo. Ora, se non è presente un carattere jolly iniziale e il campo è indicizzato, come al solito, il motore di database può applicare l'espressione regolare all'indice. Quindi, per esempio, se scrivi

SELECT *
  FROM employees
 WHERE last_name LIKE 'Cav%'

il database può utilizzare l'indice su LAST_NAME per trovare tutte le righe in cui il cognome inizia "Cav". D'altra parte, se avessi qualcosa del genere

SELECT *
  FROM employees
 WHERE last_name LIKE '%av%'

il database dovrebbe scansionare l'intera tabella (o l'intero indice) e valutare l'espressione rispetto al LAST_NAMEvalore completo . Ovviamente, è molto costoso.

La maggior parte dei migliori database relazionali dispone di strutture per eseguire ricerche full-text in modo più efficiente costruendo diversi tipi di indici e cataloghi di testo, ma questi non usano la parola chiave LIKE. Ad esempio, ecco un bell'articolo che discute della ricerca full-text in PostgreSQL .

Oltre a ciò che ha scritto Justin Cave, da PostgreSQL 9.1 puoi velocizzare qualsiasi ricerca con LIKE( ~~) o ILIKE( ~~*) e anche corrispondenze di espressioni regolari di base ( ~). Utilizzare le classi di operatori fornite dal modulo pg_trgm con un indice GIN o GiST per accelerare le LIKEespressioni che non sono ancorate a sinistra. Per installare l'estensione, eseguire una volta per database:

CREATE EXTENSION pg_trgm;

Crea un indice del modulo

CREATE INDEX tbl_col_gin_trgm_idx ON tbl USING gin (col gin_trgm_ops);

O:

CREATE INDEX tbl_col_gist_trgm_idx ON tbl USING gist (col gist_trgm_ops);

Creazione e manutenzione di un indice GIN o GiST comporta un costo, ma se la tabella non è scritta in modo pesante, questa è una grande funzionalità per te.

Depesz ha scritto un eccellente articolo nel suo blog sulla nuova funzionalità.

GIN o GiST?

Queste due citazioni del manuale dovrebbero fornire alcune indicazioni

La scelta tra l'indicizzazione GiST e GIN dipende dalle caratteristiche relative alle prestazioni di GiST e GIN, che sono discusse altrove. Come regola generale, un indice GIN è più veloce da cercare rispetto a un indice GiST, ma più lento da costruire o aggiornare; quindi GIN è più adatto per dati statici e GiST per dati spesso aggiornati.

Ma per il tipo di query "vicino più vicino" con l'utilizzo dell'operatore distanza <->:

Questo può essere implementato in modo abbastanza efficiente dagli indici GiST, ma non dagli indici GIN.

Parlando di MySQL, la posizione del carattere jolly (%) fa la differenza. Se la prima parte del testo è specificata come where first_name like 'Sta%', allora il motore DB cercherà solo un sottoinsieme più piccolo di parole che fissano con S, poi vanno a St, e poi a Sta, ecc. Se si fa qualcosa di simile where first_name like '%stan%', allora e l'intera scansione del sarà richiesta la colonna. Puoi anche esaminare gli indici full-text che eseguono anche ricerche in linguaggio naturale. Dai un'occhiata ai documenti di MySQL qui.