SQL 'LIKE BINARY' langzamer dan gewoon 'LIKE'?

Ik gebruik een django-toepassing die enkele 'startswith'-ORM-bewerkingen uitvoert waarbij longtext -kolommen worden vergeleken met een unicode-tekenreeks. Dit resulteert in een LIKE BINARY -vergelijkingsbewerking met een u'mystring ' unicode-tekenreeks. Is een LIKE BINARY waarschijnlijk langzamer dan een gewone LIKE?

Ik weet dat het algemene antwoord benchmarking is, maar ik zou graag een algemeen idee willen krijgen voor databases in het algemeen in plaats van alleen mijn applicatie, aangezien ik nog nooit eerder een LIKE BINARY-query had gezien.

Ik gebruik toevallig MySQL, maar ik ben geïnteresseerd in het antwoord voor SQL-databases in het algemeen.

6

2 antwoord

Als de prestaties een probleem lijken te worden, is het misschien een goed idee om een ​​kopie van de eerste te maken, bijvoorbeeld. 255 tekens van de lange tekst, voeg daar een index aan toe en gebruik de startswith daarmee.

BTW, deze pagina zegt : "als je het nodig hebt om hoofdlettergevoelige matching te doen, declareer je column als BINAIR, gebruik LIKE BINARY niet in je query's om een ​​niet-binaire kolom te casten. Als dat zo is, gebruikt MySQL geen indexen in die kolom. " Het is een oude tip, maar ik denk dat dit nog steeds geldig is.

5
toegevoegd
bevestigde dit gedrag in MySQL 5.5.31. Voor django betekent dit dat het belangrijk is om __istartswith te gebruiken in plaats van __startswith voor goede prestaties.
toegevoegd de auteur Julian, de bron

Voor de volgende persoon die dit tegenkomt - in onze relatief kleine database de vraag:

SELECT * FROM table_name WHERE field LIKE 'some-field-search-value';

... Result row

Returns 1 row in set (0.00 sec)

Vergeleken bij:

SELECT * FROM table_name WHERE field LIKE BINARY 'some-field-search-value';

... Result row

Returns 1 row in set (0.32 sec)

Lang verhaal kort, althans voor onze database (MySQL 5.5/InnoDB) is er een zeer significant verschil in prestaties tussen de twee lookups.

Blijkbaar is dit een bug in MySQL 5.5: http://bugs.mysql.com/bug .php? id = 63563 en in mijn testen tegen dezelfde database in MySQL 5.1 gebruikt de LIKE BINARY-query nog steeds de index (terwijl in 5.5 het een volledige tabel-scan is).

2
toegevoegd