Nie mogę sobie poradzić z prostą rzeczą, głupią relacją 1:1.
Rozwiązanie znałazem w 2 zapytaniach, ale coś czuje że można to zrobić w lepiej.

Mam 2 tabele:

[SQL] pobierz, plaintext 
//tabela user_box user_id(PRIMARY) plus setka pól z nazwami jako zwykłe cyfry. W każdej szufladzie(box) znajduje się ID prezentu.
user_box -> user_id,1,2,3,4....97,98,99,100
gift -> id,type,who
[SQL] pobierz, plaintext 

Chce pobrać wszystkie szufladki i typ prezentu który się tam znajduje.

manual mysql -> LEFT JOIN

Nawet nie muszę zaglądać do manuala.

JOIN LEFT z 2 upośledzeniami będzie wyglądało tak:

[SQL] pobierz, plaintext 
SELECT 
 user_box.*
 gift.type,
FROM 
 user_box
LEFT JOIN gift ON
 gift.id = user_box.1 OR
 gift.id = user_box.2 OR
 gift.id = user_box.3 OR
 gift.id = user_box.4 OR
 gift.id = user_box.5 OR
 .........
 gift.id = user_box.98 OR
 gift.id = user_box.99 OR
 gift.id = user_box.100
WHERE user_box.id = ?
[SQL] pobierz, plaintext 

Trudno to nazwać problemami raczej upośledzenia mySQL
1. Przy złączeniu trzeba wypisać pola 0-100. Zamienienie tego na SELECT ? WHERE id IN (SELECT? ) nic nie da bo pola i tak trzeba będzie wypisać (w klauzuli IN będziemy chcieli wszystkie pola BOXów oprócz id(PRIMARY) a nie da się tego zrobić inaczej niż wypisać).
Przy 2 SELECT używam pętli, więc na jedno wychodzi.
2.Tabele wynikowa będzie cholernie wielka. Napisze kilka przykładowych WIERSZÓW:
1. (ID) _ (ID_GIFT_1) ? (ID_GIFT_2) _ (ID_GIFT_3) - ... - (ID_GIFT_98) _ (ID_GIFT_99) _ (ID_GIFT_100) _ (TYP_GIFT_1)
2. (ID) _ (ID_GIFT_1) ? (ID_GIFT_2) _ (ID_GIFT_3) - ... - (ID_GIFT_98) _ (ID_GIFT_99) _ (ID_GIFT_100) _ (TYP_GIFT_2)
3. (ID) _ (ID_GIFT_1) ? (ID_GIFT_2) _ (ID_GIFT_3) - ... - (ID_GIFT_98) _ (ID_GIFT_99) _ (ID_GIFT_100) _ (TYP_GIFT_3)
....
99. (ID) _ (ID_GIFT_1) _ (ID_GIFT_2) _ (ID_GIFT_3) - ... - (ID_GIFT_98) _ (ID_GIFT_99) _ (ID_GIFT_100) _ (TYP_GIFT_99)
100. (ID) _ (ID_GIFT_1) _ (ID_GIFT_2) _ (ID_GIFT_3) - ... - (ID_GIFT_98) _ (ID_GIFT_99) _ (ID_GIFT_100) _ (TYP_GIFT_100)

JOIN LEFT ? Może tutaj jest błąd struktury bazy danych, którą trzeba inaczej zaprojektować i wtedy cały problem zniknie.
Mam użytkowników którzy mają plansze 10x10 -> na niej chowają prezenty. Pozostali gracze strzelają w pole odkrywając prezent który się tam skrywa. Zrobienie z tego 1 tabeli w której jest pole i od razu GIFT jest rozwiązaniem na siłę. Każdy strzelony GIFT jest zapisywany, wiec musiałbym po trafieniu go, przenieś do nowej tabeli.

Masz chorą strukturę.
5 pól:
-id,
-id_gift,
- numer_pola,
-trafiony,
-kto_trafił

No właśnie struktura jest dobra.
Powyżej oczywiście skracałem tabele, aby pokazać istotę problemu. mmmmmmm dla informacji z jednego pola (w przykładach powyżej chciałem tylko wiedzieć jaki jest typ prezentu ) Twoje rozwiązanie jest dobre.
Tabela gift jest bardziej rozbudowana, sam prezent to obiekt z 10 polami:

[SQL] pobierz, plaintext 
Gift:
 ID
 owner
 typ 
 name
 count
 prize
 reHit
 data_hit
 data_limit
 creates
[SQL] pobierz, plaintext 

Nie chce korzystać z żadnych bibliotek ORM, które zrobią to co chce w 1 linijce. Owe biblioteki muszą to jakoś robić. Sam temat założyłem tylko dla upewnienia się czy nie ma lepszego rozwiązania niż 2 odrębne SELECT, bo byłoby dziwne że mySQL nie ma nic do tak prostej relacji.

Jest to wzorcowy przykład z cyklu "jak nie budować struktury bazy"
gdybyś miał tabele:
1 użytkownicy
2 boxy
3 uzytkownicy_boxy(id_uzytkownicy, id_boxy, id_prezentu,id)
4 prezenty
To nie było by problemów z zapytaniami i ilością boxów.

Przypuszczam, że niechcący pomyliłeś się w zapisie. Masz 100% racje wprowadzenie jeszcze jednej tabeli pośredniczącej pomiędzy USER<->BOX rozwiąże problem z zapytaniem.

Poprawiona struktura:

[SQL] pobierz, plaintext 
USER -> id
BOX -> id, GIFT.id
USER_BOX -> USER.id, BOX.id
GIFT ->id
[SQL] pobierz, plaintext 

Takie rozwiązanie bardzo szybko namnoży nam wierszy w tabelach. Dla 1 użytkownika musimy utworzyć 100 wierszy w BOX i USER_BOX.
Mam przeczucie, że to jest PODRĘCZNIKOWE rozwiązaniem mojego problemu (problemu który przy tym rozwiązaniu nie istnieje). Ale jakoś nie jestem przekonany, zostanę przy 2 SELECT.

Nie chce zamykać tematu, dlatego jak ktoś miał podobny problem i rozwiązał go jakoś inaczej niż 2 SELECT to śmiało. Osobiście czekam na odpowiedź nospor'a.