Евгений Быков

А если так?

SELECT *
    FROM (SELECT dbo.PN1.date, dbo.PN2.mp_tn3, dbo.PN2.price, dbo.PN2.id
              FROM dbo.PN1 INNER JOIN dbo.PN2 ON dbo.PN1.id = dbo.PN2.mp_pn1
              WHERE (dbo.PN2.mp_tn3 = 31457)
          UNION
          SELECT dbo.NO1.date, dbo.NO2.mp_tn3, dbo.NO2.price, dbo.NO2.id
              FROM dbo.NO1 INNER JOIN dbo.NO2 ON dbo.NO1.id = dbo.NO2.mp_no1
              WHERE (dbo.NO2.mp_tn3 = 31457)
         ) t 
    ORDER BY 1

Порядок сортировки индекса сказывается только при создании индексов с составными ключами, т.е., с ключами из нескольких полей. Т.е., если у вас имеется индекс с ключом (field1, field2, field3) и более частыми являются запросы со следующей сортировкой:
ORDER BY field1 ASC, field2 DESC, field3 ASC, то тогда вам следует использовать индекс (field1 ASC, field2 DESC, field3 ASC) или (field1 DESC, field2 ASC, field3 DESC). Когда же у вас индекс имеет ключ из одного поля, то порядок сортировки его не имеет значения, т.к. SQL engine умеет сканировать индекс в обоих направлениях.
Для добавления записей и для выборок одиночных записей порядок сортировки индекса не играет роли - производительность будет абсолютно одинакова, а для выборки последовательности записей, т.е. при сканировании диапазона индекса этот порядок уже может сиграть, но надо понимать, что на достаточно больших диапазонах индекса. Если просто выгребать всего 50 первых записей и без WHERE, то различие будет незаметно.

Стандартным прямолинейным решением будет следующий запрос:

SELECT t.name, (SELECT p.price FROM products p WHERE p.id = t.max_id) AS last_price
    FROM (SELECT name, max(id) AS max_id FROM products GROUP BY name) t

Однако, очень рекомендую вам разобраться с предыдущим решением (с использованием RANK()) -- некоторые задачи просто невозможно решить без использования этой конструкции.

Вообще-то, с точки зрения архитектуры, правильно для отсутствующих значений использовать именно NULL - это значение для того и существует.
Насчет индексов - это зависит, во-первых, от того, какую RDBMS вы используете, а во-вторых, от того, содержит ли индекс другие колонки.
Так, например, в Oracle ключи состоящие из одних NULL в индекс не попадают, т.е., если, например, индекс строится по 2 колонкам: id и start_date, то в индекс этот ключ не попадет, только если обе эти колонки содержат NULL.
В то же время, в MS SQL Server значения NULL индексируются так же, как и остальные значения.

Для увеличения общей производительности надо заставить RDBMS использовать merge, а не hash join и не nested loop с использованием индекса.
Для этого сливаем две таблицы

SELECT id FROM x
UNION ALL
SELECT id FROM x
UNION ALL
SELECT x_id FROM y

В этом наборе каждый id входит 1 раз (если он содержится в y и не содержится в x), 2 раза (если он содержится в x и не содержится в y) и 3 раза (если содержится в обеих таблицах).
Затем группируем и выбираем те группы, которые содержат ровно две записи

SELECT id
    FROM (SELECT id FROM x
          UNION ALL
          SELECT id FROM x
          UNION ALL
          SELECT x_id FROM y
         )
    GROUP BY id
    HAVING COUNT(*) = 2

Такой запрос не требует индексов и будет очень эффективен даже на очень больших таблицах
Разумеется, решение основано на предположении об уникальности id в таблице x, и уникальности x_id в таблице y. Если же id не уникален в таблице x, то надо выполнять
SELECT DISTINCT id FROM x
вместо
SELECT id FROM x
Это же касается таблицы колонки x_id колонки y

Сливаем две таблицы

SELECT * FROM tbl1
UNION ALL
SELECT * FROM tbl2

затем группируем по всем полям и выбираем те группы, которые содержат более одной записи

SELECT *
    FROM (SELECT * FROM tbl1
          UNION ALL
          SELECT * FROM tbl2
         )
    GROUP BY field1, field2, ...
    HAVING COUNT(*) > 1

Такой запрос не требует индексов и будет очень эффективен даже на очень больших таблицах
Разумеется, решение основано на предположении об уникальности записей в каждой из таблиц