|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
день добрый. есть две таблицы с одинаковой структурой, T1 и T2 пишу вьюху V1 SELECT text FROM T1 WHERE ddate > DivideDate() UNION SELECT text FROM T2 WHERE ddate <= DivideDate() -- наборы данных не пересекаются на эту вьюху приходит запрос SELECT text FROM V1 WHERE ddate = '20100202' итак: 1) будут выполняться оба селекта из юниона или сервер *догадается* выбрать только нужный? 2) какую литературу посоветуете для понимания того, как mssql разбирает и выполняет запросы? спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:30 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
Shakillна эту вьюху приходит запрос SELECT text FROM V1 WHERE ddate = '20100202'И не ругается на поле V1.ddate ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:32 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
http://%5D%5B/url]Специально для таких случаев придуманы секционированные представления Интерсная статья ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:33 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
ПаганельShakillна эту вьюху приходит запрос SELECT text FROM V1 WHERE ddate = '20100202'И не ругается на поле V1.ddate ? я не копировал запрос целиком, просто общий принцип показал. конечно же, во вьюхе select text, ddate ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:34 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
Плохо отформатировал... Специально для таких случаев придуманы секционированные представления Интерсная статья ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:35 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
И что, сервер в результате должен сделать это Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
Что-то я смысл того что в where понять не могу ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:37 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
ПаганельИ что, сервер в результате должен сделать это Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
Что-то я смысл того что в where понять не могу в результате (по идее) сервер должен искать данные только в одной таблице, которая подходит по дате, а другой селект, который не будет иметь смысла, остановится уже на этапе анализа where и лишний поиск происходить не будет ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:42 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
Shakill в результате (по идее) сервер должен искать данные только в одной таблице, которая подходит по дате, а другой селект, который не будет иметь смысла, остановится уже на этапе анализа where и лишний поиск происходить не будет А откуда сервер узнает, что значение '20100202' есть только в одной таблице ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:43 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
GloryА откуда сервер узнает, что значение '20100202' есть только в одной таблице ? я рассчитываю, что сервер сначала вычислит DivideDate(), разберет WHERE и увидит, что один из селектов может вернуть непустой набор данных, а другой - нет, и затем выполнит только один из них. вот и пытаюсь выяснить, так это или нет ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:49 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
ShakillGloryА откуда сервер узнает, что значение '20100202' есть только в одной таблице ? я рассчитываю, что сервер сначала вычислит DivideDate(), разберет WHERE и увидит, что один из селектов может вернуть непустой набор данных, а другой - нет, и затем выполнит только один из них. вот и пытаюсь выяснить, так это или нет На этапе составления плана сервер не будет вычислять никакие DivideDate() ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:51 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
GloryНа этапе составления плана сервер не будет вычислять никакие DivideDate() хорошо, попробую другими словами. допустим, индексов нет при выполнении запроса Код: plaintext 1. 2. 3.
каким образом поступит сервер: а) пройдет по всем строкам таблицы, каждый раз вычисляя DivideDate() и производя сравнение ddate б) один раз вычислит DivideDate() и пройдет по всем строкам таблицы в поисках удовлетворяющих условию записей в) один раз вычислит DivideDate(), и если получится больше чем '20100202', то без поиска сразу вернет пустой набор данных, т.к. WHERE не будет иметь смысла ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 16:03 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
Shakill каким образом поступит сервер: а) пройдет по всем строкам таблицы, каждый раз вычисляя DivideDate() и производя сравнение ddate б) один раз вычислит DivideDate() и пройдет по всем строкам таблицы в поисках удовлетворяющих условию записей в) один раз вычислит DivideDate(), и если получится больше чем '20100202', то без поиска сразу вернет пустой набор данных, т.к. WHERE не будет иметь смысла ? Откройте для себя планы выполнения(execution plans) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 16:04 |
|
выполнение только одной части UNION
|
|||
---|---|---|---|
#18+
GloryShakill каким образом поступит сервер: а) пройдет по всем строкам таблицы, каждый раз вычисляя DivideDate() и производя сравнение ddate б) один раз вычислит DivideDate() и пройдет по всем строкам таблицы в поисках удовлетворяющих условию записей в) один раз вычислит DivideDate(), и если получится больше чем '20100202', то без поиска сразу вернет пустой набор данных, т.к. WHERE не будет иметь смысла ? Откройте для себя планы выполнения(execution plans) В плане слишком обобщенно, наличие узла Filter не раскрывает подробностей, о которых я спрашивал. Как именно происходит фильтрация? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 16:31 |
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1728278]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
13ms |
get first new msg: |
9ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 285ms |
total: | 463ms |
0 / 0 |