Esta é uma forma de obter o resultado.
Essa abordagem usa subconsultas correlacionadas. Cada subconsulta usa um
ORDER BY cláusula para classificar as linhas relacionadas da tabela2 e usa o LIMIT cláusula para recuperar a 1ª, 2ª e 3ª linhas. 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
SEGUIR
@gliese581g aponta que pode haver problemas de desempenho com essa abordagem, com um grande número de linhas retornadas pela consulta externa, pois cada subconsulta na lista SELECT é executada para cada linha retornada na consulta externa.
Não é preciso dizer que essa abordagem exige um índice:
ON table2 (PKID_FROM_TABLE_1, U_DATA)
-ou, no mínimo-
ON table2 (PKID_FROM_TABLE_1)
É provável que o último índice já exista, se houver uma chave estrangeira definida. O índice anterior permitiria que a consulta fosse satisfeita inteiramente a partir das páginas de índice ("Usando índice"), sem a necessidade de uma operação de classificação ("Usando classificação de arquivos").
@glies581g está certo em apontar que o desempenho dessa abordagem pode ser problemático em conjuntos "grandes".
