Скажем, что у меня есть таблица order
как
id | clientid | type | amount | itemid | date
---|----------|------|--------|--------|-----------
23 | 258 | B | 150 | 14 | 2012-04-03
24 | 258 | S | 69 | 14 | 2012-04-03
25 | 301 | S | 10 | 20 | 2012-04-03
26 | 327 | B | 54 | 156 | 2012-04-04
-
clientid
- это внешний ключ обратно в таблицуclient
-
itemid
- это внешний ключ обратно в таблицуitem
-
type
- это толькоB
илиS
-
amount
- целое число
и таблицу processed
как
id | orderid | processed | date
---|---------|-----------|---------
41 | 23 | true | 2012-04-03
42 | 24 | true | 2012-04-03
43 | 25 | false | <NULL>
44 | 26 | true | 2012-04-05
Мне нужно получить все строки из order
, которые для того же clientid
на одном и том же date
имеют противоположные значения type
. Помните, что type
может иметь только одно из двух значений - B
или S
. В приведенном выше примере это будут строки 23
и 24
.
Другим ограничением является то, что соответствующая строка в processed
должна быть true
для orderid
.
Мой запрос пока
SELECT c1.clientid,
c1.date,
c1.type,
c1.itemid,
c1.amount,
c2.date,
c2.type,
c2.itemid,
c2.amount
FROM order c1
INNER JOIN order c2 ON c1.itemid = c2.itemid AND
c1.date = c2.date AND
c1.clientid = c2.clientid AND
c1.type <> c2.type AND
c1.id < c2.id
INNER JOIN processed p1 ON p1.orderid = c1.id AND
p1.processed = true
INNER JOIN processed p2 ON p2.orderid = c2.id AND
p2.processed = true
ВОПРОС: Сохранение processed = true
как части предложения соединения замедляет запрос вниз. Если я переведу его в предложение WHERE, производительность будет намного лучше. Это вызвало мой интерес и , я хотел бы знать, почему.
Первичные ключи и соответствующие столбцы внешнего ключа индексируются, а столбцы значений (value
, processed
и т.д.) не являются.
Отказ от ответственности: я унаследовал эту структуру БД, а разница в производительности составляет примерно 6 секунд.