LUB warunki, gdy nie są w tym samym polu lub zakresie na podstawie (takich jak < , > , LIKE ) naprawdę zmniejszają zdolność MySQL do korzystania z indeksów; możesz zmienić strukturę zapytań, dzieląc je na oddzielne, prostsze, które możesz następnie UNION. Oddzielenie go w ten sposób pozwala MySQL na korzystanie z innego indeksu każdego zapytania w ramach UNION
SELECT `u`.`user_id`, `c`.`company`
FROM `users` AS `u` LEFT JOIN `companies` AS `c` ON `c`.`user_id` = `u`.`user_id`
WHERE `u`.`user_id` = 'search_term'
UNION DISTINCT
SELECT `u`.`user_id`, `c`.`company`
FROM `users` AS `u` LEFT JOIN `companies` AS `c` ON `c`.`user_id` = `u`.`user_id`
WHERE `u`.`lname` LIKE 'search_term%'
UNION DISTINCT
SELECT `u`.`user_id`, `c`.`company`
FROM `users` AS `u` LEFT JOIN `companies` AS `c` ON `c`.`user_id` = `u`.`user_id`
WHERE `u`.`email` LIKE 'search_term%'
UNION DISTINCT
SELECT `u`.`user_id`, `c`.`company`
FROM `users` AS `u` INNER JOIN `companies` AS `c` ON `c`.`user_id` = `u`.`user_id`
WHERE `c`.`company` LIKE 'search_termeo%'
;
Zauważ też, że zmieniłem JOIN ostatniego na INNER, ponieważ każdy warunek na prawym stole LEFT JOIN (który nie jest „bez dopasowania z tego stołu”) i tak jest w zasadzie INNER JOIN.
UNION DISTINCT służy do zapobiegania powtarzaniu rekordów spełniających wiele warunków, jednak... jeśli companies.company nie jest unikalny (tj. identyfikator firmy 1 zwany „Blah” i identyfikator firmy 12 zwany również „Blah”), zostaną one również scalone w miejscach, w których nie byłoby ich w pierwotnym zapytaniu; jeśli jest to potencjalny problem, można temu zaradzić poprzez uwzględnienie identyfikatora firmy w każdym SELECT .
