Dziwne zachowanie :), Więcej = mniej w like %cos% Opcje

[beherit]

Mam bardzo dziwna sytuacje - zapytania ponizej powiedza wszystko, całość obcięta do totalnego minimum
MySQL 4.1.1

[SQL] pobierz, plaintext 
SELECT x1 FROM firmy f WHERE f.x1 LIKE '%anspo%';
/* 0 rows affected, 14 rows found. Duration for 1 query: 0,000 sec. */
SELECT x1 FROM firmy f WHERE f.x1 LIKE '%anspor%';
/* 0 rows affected, 3 rows found. Duration for 1 query: 0,000 sec. */
SELECT x1 FROM firmy f WHERE f.x1 LIKE '%ansport%';
/* 0 rows affected, 8 rows found. Duration for 1 query: 0,047 sec. */
[SQL] pobierz, plaintext 

jakiś pomysł?

Ten post edytował beherit 21.11.2011, 09:53:49

[maly_swd]

Normalka, like ma wiecej danych do sprawdzenia, wiec wiecej czasu zajmue operacja

[szmerak]

Mu chyba chodzi o to że
anspo zwraca 14
anspor 3
ansport 8

a im dłuższy string to zakres szukania powinnien się zmniejszać a nie zwiększać..

No trochę dziwne.. :}

Ten post edytował szmerak 28.11.2011, 02:49:41

[Adi32]

MySQL
nie pierwszy i nie ostatni bug

[maly_swd]

"a im dłuższy string to zakres szukania powinnien się zmniejszać a nie zwiększać.."

Tak, jak masz klucze. Jesli nie masz.. To zamiast porownywac 5 literek w srodku, porownuje 8 literek czy sie zgadzaja. Czyli czas sprawdzanie... rosnie.

To tak jakby Ci ktos kazal szukac w ksiazce (bez indexu) slow gdzie wystepuje w srodku literka A... w miare szybko to idze... ale jak ma byc juz acadatera to naszukasz sie i znajdziesz moze 1-2 slowa:)

[luckyps]

A możesz Nam pokazać co zwróciły Ci te trzy zapytania ?

[beherit]

Zwrotki były ogólnie zgodne z tym co było w zapytaniu i odzwierciedlały poprawnie zapytanie - tyle ze nie byly pelne.

Cos mi sie wydaje ze to jest kwestia HeidiSQL (MySQL Fronta).

[Zbychu666]

MySQL 4.1.1
(...)
jakiś pomysł?

Tak - nie używaj wersji Alpha MySQL'a sprzed ośmiu lat.