Esta es una forma de obtener el resultado.
Este enfoque utiliza subconsultas correlacionadas. Cada subconsulta usa un ORDER BY cláusula para ordenar las filas relacionadas de la tabla 2 y usa el LIMIT cláusula para recuperar las filas 1, 2 y 3.
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
SEGUIMIENTO
@gliese581g señala que puede haber problemas de rendimiento con este enfoque, con una gran cantidad de filas devueltas por la consulta externa, ya que cada subconsulta en la lista SELECT se ejecuta para cada fila devuelta en la consulta externa.
No hace falta decir que este enfoque exige un índice:
ON table2 (PKID_FROM_TABLE_1, U_DATA)
-o, como mínimo-
ON table2 (PKID_FROM_TABLE_1)
Es probable que el último índice ya exista, si hay una clave externa definida. El índice anterior permitiría que la consulta se cumpliera por completo desde las páginas de índice ("Uso de índice"), sin necesidad de una operación de ordenación ("Uso de ordenación de archivos").
@glies581g tiene toda la razón al señalar que el rendimiento de este enfoque puede ser problemático en conjuntos "grandes".
