Opierając się na przykładzie FIND_IN_SET() z @Jeremy Smith, możesz to zrobić za pomocą złączenia, dzięki czemu nie musisz uruchamiać podzapytania.
SELECT * FROM table t
JOIN locations l ON FIND_IN_SET(t.e_ID, l.city) > 0
WHERE l.e_ID = ?
Wiadomo, że działa to bardzo słabo, ponieważ musi wykonywać skanowanie tabel, oceniając funkcję FIND_IN_SET() dla każdego kombinacja wierszy w table i locations . Nie może korzystać z indeksu i nie można go ulepszyć.
Wiem, że powiedziałeś, że starasz się jak najlepiej wykorzystać kiepski projekt bazy danych, ale musisz zrozumieć, jak bardzo jest to drastyczne.
Objaśnienie:Załóżmy, że prosiłbym cię o wyszukanie w książce telefonicznej wszystkich, których pierwszy, środkowy lub ostatni inicjał to „J”. W tym przypadku nie ma mowy, aby uporządkowana kolejność książki była pomocna, ponieważ i tak musisz zeskanować każdą stronę.
LIKE rozwiązanie podane przez @fthiella ma podobny problem z wydajnością. Nie można go zindeksować.
Zobacz także moją odpowiedź na Czy przechowywanie rozdzielanej listy w kolumnie bazy danych jest naprawdę takie złe? dla innych pułapek tego sposobu przechowywania zdenormalizowanych danych.
Jeśli możesz utworzyć dodatkową tabelę do przechowywania indeksu, możesz przypisać lokalizacje do każdego wpisu na liście miast:
CREATE TABLE location2city (
location INT,
city INT,
PRIMARY KEY (location, city)
);
Zakładając, że masz tabelę przeglądową dla wszystkich możliwych miast (nie tylko tych wymienionych w table ) możesz raz znieść nieefektywność tworzenia mapowania:
INSERT INTO location2city (location, city)
SELECT l.e_ID, c.e_ID FROM cities c JOIN locations l
ON FIND_IN_SET(c.e_ID, l.city) > 0;
Teraz możesz uruchomić znacznie wydajniejsze zapytanie, aby znaleźć wpisy w Twojej table :
SELECT * FROM location2city l
JOIN table t ON t.e_ID = l.city
WHERE l.e_ID = ?;
Może to wykorzystać indeks. Teraz wystarczy zadbać o to, aby wstawić/uaktualnić/usunąć wiersze w locations wstawia również odpowiednie wiersze mapowania w location2city .
