addicted2ax: Dynamics AX 2012 & SQL Server 2008R2: Cross Join vs. Inner Join – Houston we have *NO* Problem

[Blog bot]

Источник: http://addicted2ax.de/index.php?/arc...O-Problem.html
==============

Recently I had to bulid a rather complex list page. The Dynamics AX 2012-query contained some INNER JOINS and some OUTER JOINS between tables. After finishing designing the list page the performance when running the list page was suboptimal.

After adding some indexes performance increased drastic but still had some room for improvement.

So I ran an SQL Server Profiler Trace and was a little bit shocked for a moment: The SQL statement which was created Dynamics AX 2012 to be send to SQL Server 2008 R2 was a CROSS JOIN with a WHERE-clause and not an INNER JOIN.

First thought was that I remembered that a CROSS JOIN creates a cartesian product of both tables. Cartesian product means that every of the first table is joined with every row of the second table. Then I remebered that a CROSS JOIN with a WHERE-clause delivers in the end the same result as an INNER JOIN.
Second though was that in other RDBMS and older versions of SQL Server even when the result is the same like in an INNER JOIN a CROSS JOIN with a WHERE-Clause may perform not as good as an INNER JOIN.

So my idea was to check if there is maybe a performance problem in Dynamics AX 2012 by using CROSS JOINS instead of using INNER JOINS.
Firstly I bulid a query using SalesTable-table joined with SalesLine-table using an INNER JOIN as join mode and as fetch mode “1:n”. I have also tested “1:1”. Ressults were identically.



For test purposes I used „forced Literals“ and the following SQL Statement was send to SQL Server by Dynamics AX 2012



Execution Plan looks quite good: For both tables a „Clustered Index Seek“ was performed. Then both result sets were joined. Finished. Looks quite good to me.

Let’s see what statistics say:



434 logical reads for SalesLine-table and 163 logical reads for SalesTable. CPU-time used: 47ms. Total elapsed time: round about 2 seconds.
Not bad, but maybe an INNER JOIN performs even better.

The following SQL statement using an INNER JOIN was built by me in the way how I would have built it if I was Dynamics AX 2012.



I must confess that I was a little bit surprised that both Execution Plans were identically.

Checking statistics shows the same result: Same numbers of reads for SalesTable-table and SalesLine-table. Differences in CPU-time and in total elapsed time are inside normal fluctuations when running SQL Server. So needed time when running a CROSS JOIN with a WHERE-clause and time needed when running an INNER JOIN can said to be identically.



A short Google-search showed the following result. Last version of SQL Server which seemed to perform a CROSS JOIN with a WHERE-clause worse than an INNER JOIN was SQL Server 2000. Since SQL Server 2005 query optimizer treats a CROSS JOIN with a WHERE-clause identically to an INNER JOIN.


Update 22.03.2012:
I faced a (minor) problem with a CROSS JOIN with WHERE-clause: I joined two tables in a larger query by using Expression “Relation” with value “Yes” (by setting Expression “Relation” to “Yes” relations are set automatically using the relations specified in Relations-knot of the specific table).

Even so the relation seemed to be set correctly in Dynamics AX 2012 the SQL Statement generated by Dynamics AX 2012 was not generated correctly: Only a CROSS JOIN without a WHERE-clause was generated. So the CROSS JOIN generated a cartesian product with a large amount of data.
Fastest and proper working solution I found was setting back “Relation” to “No” and rebuilding the relation manually. Manually generated relation has exactly the same values as the automatically generation.

This seems NOT to be a general problem, because the other automatically generated relations between the tables of the query work proper and without any problem. I also had no problem using Expression “Relation” with value “Yes” with other queries.


Conclusion:
When Dynamics AX 2012 generates a CROSS JOIN with a WHERE-clause instead of an INNER JOIN when performing an INNER JOIN: There is no performance gap.
If you have any with unexpected result sets which may look like a cartesian product check the relations between the tables, kill the existing automatically build relations and rebuild these relations manually.




Источник: http://addicted2ax.de/index.php?/arc...O-Problem.html