СОЕДИНЕНИЕ быстрее, чем ГДЕ?

@MSalters: Хорошая идея.

, Если целочисленное вычисление требуется (для точности), но плавающая точка доступна, Вы могли сделать что-то как:

uint64_t foo( uint64_t a, uint64_t b ) {
    double   dc;

    dc = pow( a, b );

    if ( dc < UINT_MAX ) {
       return ( powu64( a, b ) );
    }
    else {
      // overflow
    }
}
54
задан Carl Manaster 15 July 2009 в 17:31
поделиться

10 ответов

Теоретически нет, быстрее не должно быть. Оптимизатор запросов должен иметь возможность генерировать идентичный план выполнения. Однако некоторые механизмы БД могут создавать лучшие планы выполнения для одного из них (что вряд ли произойдет для такого простого запроса, но для достаточно сложных). Вы должны протестировать оба и посмотреть (на вашем движке БД).

43
ответ дан 7 November 2019 в 08:02
поделиться

It is a "standard" to use the INNER JOIN syntax, although practically equivalent. The main reason it should be used is for clarity and mobility purposes as it is consistent with OUTER JOIN syntax.

2
ответ дан 7 November 2019 в 08:02
поделиться

There is no way to correctly answer this without limiting to a target database.

For MS-SQL both queries result in the same execution plans, but keep in mind:

SELECT *
FROM Document, DocumentStats
WHERE DocumentStats.Id = Document.Id
  AND DocumentStats.NbViews > 500

Is really risky since it is easy to forget the join condition in the WHERE clause and end up with a nasty cross join.

12
ответ дан 7 November 2019 в 08:02
поделиться

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

4
ответ дан 7 November 2019 в 08:02
поделиться

Если вы говорите конкретно о SQL Server, вам определенно следует использовать синтаксис INNER JOIN. Помимо того, что (оповещение о личном мнении!) Легче читать и яснее намерения, в SQL Server 2005 нет эквивалентного синтаксиса для внешних соединений. Синтаксис * = и = * не поддерживается по умолчанию в 2005 году - для его поддержки необходимо включить режим совместимости. В конечном итоге он будет удален, возможно, в следующем выпуске (или, возможно, нет!)

Это означает:

  • Если вам нужно изменить запрос с внутреннего соединения на внешнее соединение, вам нужно либо его переписать (argh ) или включите режим совместимости (yuk)
  • Без режима совместимости вы не сможете согласовываться с тем, как вы реализуете разные типы объединений (внутренние и внешние), что приведет к кошмару обслуживания (и, где они объединены в один запрос, некоторое поведение, которое не является интуитивным.)

Обратите внимание, что вопреки распространенному мнению, эти два понятия не эквивалентны. Некоторые вещи намного более неудобны, а некоторые просто невозможны. Кален Делани Внутри SQL Server 2000 содержит несколько примеров; не уверен, что это делают новые версии, потому что этот синтаксис соединения в любом случае устарел.

2
ответ дан 7 November 2019 в 08:02
поделиться

Явные объединения легче поддерживать, поскольку цель запроса намного яснее. Кроме того, они не подвержены случайным перекрестным соединениям, поэтому, если у вас есть перекрестное соединение в запросе, сопровождающий знает, что оно предназначено для этого.

Если вам когда-либо понадобится использовать внешние соединения, вы должны знать, что синтаксис * = устарела в SQL Server и скоро будет удалена. Кроме того, в настоящее время он не всегда работает должным образом и может не давать правильных результатов, поэтому его НИКОГДА не следует использовать. Сочетание явных внешних соединений и соединений с предложением where (неявные соединения) значительно усложняет чтение и понимание запроса специалисту по обслуживанию.

2
ответ дан 7 November 2019 в 08:02
поделиться

When you use Sqlite: The where-syntax is slightly faster because Sqlite first translates the join-syntax into the where-syntax before executing the query.

2
ответ дан 7 November 2019 в 08:02
поделиться

В MSSQL оба запроса компилируются с одним и тем же планом выполнения, поэтому нет никакой разницы. Это больше о удобочитаемости - я думаю, что JOIN легче читать, поэтому я использую его.

1
ответ дан 7 November 2019 в 08:02
поделиться

I guess that it doesn't make a difference too. To be sure you can check if the explain plan of those two queries is identical. In order to look at the explain plan in MySQL you have to put the "explain" keyword before the statement, eg:

EXPLAIN
SELECT *
FROM Document, DocumentStats
WHERE DocumentStats.Id = Document.Id
  AND DocumentStats.NbViews > 500

I'm sure there exists an equivalent in MSSQL too.

By the way: This looks like this is a 1:1 relationship so I'd just include the nbviews attribute directly in the Document table, therefore you can save a join.

1
ответ дан 7 November 2019 в 08:02
поделиться

Производительность «JOIN» по сравнению с «WHERE» ... все зависит от того, насколько хорошо ядро ​​базы данных может оптимизировать запрос для вас. Он будет учитывать любые индексы, которые могут быть у возвращаемых столбцов, и учитывать, что производительность предложений WHERE и JOIN также зависит от самого физического файла базы данных и уровня его фрагментации и даже от технологии хранения, которую вы используете для хранения файлов базы данных. .

Сервер MSSql выполняет запросы в следующем порядке (это должно дать вам представление о функциях предложений WHERE и JOIN)

Порядок обработки запросов Microsoft Sql Server

следующее взято из превосходной серии книги о Microsoft SQL Server, Inside Microsoft SQL Server 2005:
(Шаг 1) ИЗ left_table
(Шаг 3) join_type JOIN right_table
(Шаг 2) ON join_condition
(Шаг 4) ГДЕ where_condition
(шаг 5) GROUP BY group_by_list
(шаг 6) WITH [CUBE | ROLLUP]
(шаг 7) HAVING using_clause
(Шаг 10) ORDER BY order_by_list

18
ответ дан 7 November 2019 в 08:02
поделиться
Другие вопросы по тегам:

Похожие вопросы: