Detta är ett sätt att få resultatet.
Detta tillvägagångssätt använder korrelerade underfrågor. Varje underfråga använder en ORDER BY sats för att sortera de relaterade raderna från tabell2, och använder LIMIT klausul för att hämta 1:a, 2:a och 3:e raden.
SELECT a.PKID
, a.DATA
, (SELECT b1.U_DATA FROM table2 b1
WHERE b1.PKID_FROM_TABLE_1 = a.PKID
ORDER BY b1.U_DATA LIMIT 0,1
) AS U_DATA1
, (SELECT b2.U_DATA FROM table2 b2
WHERE b2.PKID_FROM_TABLE_1 = a.PKID
ORDER BY b2.U_DATA LIMIT 1,1
) AS U_DATA2
, (SELECT b3.U_DATA FROM table2 b3
WHERE b3.PKID_FROM_TABLE_1 = a.PKID
ORDER BY b3.U_DATA LIMIT 2,1
) AS U_DATA3
FROM table1 a
ORDER BY a.PKID
UPPFÖLJNING
@gliese581g påpekar att det kan finnas prestandaproblem med detta tillvägagångssätt, med ett stort antal rader som returneras av den yttre frågan, eftersom varje underfråga i SELECT-listan exekveras för varje rad som returneras i den yttre frågan.
Det borde vara självklart att detta tillvägagångssätt ropar efter ett index:
ON table2 (PKID_FROM_TABLE_1, U_DATA)
-eller åtminstone-
ON table2 (PKID_FROM_TABLE_1)
Det är troligt att det senare indexet redan finns, om det finns en främmande nyckel definierad. Det tidigare indexet skulle tillåta att frågan besvarades helt från indexsidorna ("Using index"), utan behov av en sorteringsoperation ("Using filesort").
@glies581g har helt rätt när han påpekar att prestanda för detta tillvägagångssätt kan vara problematiskt på "stora" uppsättningar.