Antingen använde artikeln du läste ett dåligt exempel, eller så misstolkade du deras poäng.
select username from users where company = 'bbc' or company = 'itv';
Detta motsvarar:
select username from users where company IN ('bbc', 'itv');
MySQL kan använda ett index på company för denna fråga bara bra. Det finns ingen anledning att göra någon UNION.
Det mer knepiga fallet är när du har en OR tillstånd som involverar två olika kolumner.
select username from users where company = 'bbc' or city = 'London';
Anta att det finns ett index på company och ett separat index på city . Med tanke på att MySQL vanligtvis bara använder ett index per tabell i en given fråga, vilket index ska den använda? Om den använder indexet på company , skulle den fortfarande behöva göra en tabellsökning för att hitta rader där city är London. Om den använder indexet på city , skulle den behöva göra en tabellsökning efter rader där company är bbc.
UNION lösningen är för denna typ av fall.
select username from users where company = 'bbc'
union
select username from users where city = 'London';
Nu kan varje underfråga använda indexet för sin sökning, och resultaten av underfrågan kombineras av UNION .
En anonym användare föreslog en redigering av mitt svar ovan, men en moderator avvisade redigeringen. Det borde ha varit en kommentar, inte en redigering. Påståendet från den föreslagna redigeringen var att UNION måste sortera resultatuppsättningen för att eliminera dubbletter av rader. Detta gör att frågan går långsammare, och indexoptimeringen är därför en tvätt.
Mitt svar är att indexen hjälper till att reducera resultatuppsättningen till ett litet antal rader innan UNION inträffar. UNION eliminerar faktiskt dubbletter, men för att göra det behöver den bara sortera den lilla resultatuppsättningen. Det kan finnas fall där WHERE-satserna matchar en betydande del av tabellen, och sortering under UNION är lika dyrt som att bara göra tabellskanningen. Men det är vanligare att resultatuppsättningen reduceras av de indexerade sökningarna, så sorteringen är mycket billigare än tabellskanningen.
Skillnaden beror på data i tabellen och termerna som söks. Det enda sättet att avgöra den bästa lösningen för en given fråga är att prova båda metoderna i MySQL-frågeprofileraren och jämför deras prestanda.