Здравствуйте, Maniacal, Вы писали:

M>Здравствуйте, tnikolai, Вы писали:

T>>Так это Postgre, а на mssql не берёт индексы, на каждую строку tx1 перебирает все строки tx1 снова и это никак не оптимизируемо

M>У тебя индекс комбинированный: CREATE NONCLUSTERED INDEX IX_tx1 ON tx1 (x1,x2);

M>Нужно два отдельных индекса. Двойной не комбинированный, вроде, только Oracle умел пользовать как два отдельных.
M>Два независимых индекса даже на SQLite сработают, уверен. В индексе по двум полям почти у 100% СУБД поиск по второму полю происходит только после совпадения по первому. B-TREE в двух измерениях. Я с проблемами с OR ещё году в 2003ем столкнулся.

CREATE NONCLUSTERED INDEX IX_tx1 ON tx1 (x1);
CREATE NONCLUSTERED INDEX IX_tx2 ON tx1 (x2);

всё равно никак

900 миллионов переборов

Здравствуйте, Maniacal, Вы писали:

M>Здравствуйте, tnikolai, Вы писали:

T>>Так это Postgre, а на mssql не берёт индексы, на каждую строку tx1 перебирает все строки tx1 снова и это никак не оптимизируемо

M>У тебя индекс комбинированный: CREATE NONCLUSTERED INDEX IX_tx1 ON tx1 (x1,x2);

M>Нужно два отдельных индекса. Двойной не комбинированный, вроде, только Oracle умел пользовать как два отдельных.
M>Два независимых индекса даже на SQLite сработают, уверен. В индексе по двум полям почти у 100% СУБД поиск по второму полю происходит только после совпадения по первому. B-TREE в двух измерениях. Я с проблемами с OR ещё году в 2003ем столкнулся.

CREATE NONCLUSTERED INDEX IX_tx1 ON tx1 (x1);
CREATE NONCLUSTERED INDEX IX_tx2 ON tx1 (x2);

всё равно никак

900 миллионов переборов

Ещё FORCESEEK нужно, тогда сработало
select * from tx1 t1 WITH (FORCESEEK)
inner join tx1 t2 on(t1.x1=t2.x1 or t1.x2=t2.x2) and t1.id!=t2.id