Poor performance with stacked joins

Question

I'm not sure I can provide enough details for an answer, but my company is having a performance issue with an older mssql view. I've narrowed it down to the right outer joins, but I'm not familiar with the structure of joins following joins without a "ON" with each one, as in the code snippet below.

How do I write the joins below to either improve performance or to the simpler format of Join Tablename on Field1 = field2 format ?

  FROM    dbo.tblObject AS tblObject_2
            JOIN dbo.tblProspectB2B PB ON PB.Object_ID = tblObject_2.Object_ID
            RIGHT OUTER JOIN dbo.tblProspectB2B_CoordinatorStatus
            RIGHT OUTER JOIN dbo.tblObject
            INNER JOIN dbo.vwDomain_Hierarchy
            INNER JOIN dbo.tblContactUser
            INNER JOIN dbo.tblProcessingFile WITH ( NOLOCK )
            LEFT OUTER JOIN dbo.enumRetentionRealization AS RR ON RR.RetentionRealizationID = dbo.tblProcessingFile.RetentionLeadTypeID
            INNER JOIN dbo.tblLoan
            INNER JOIN dbo.tblObject AS tblObject_1 WITH ( NOLOCK ) ON dbo.tblLoan.Object_ID = tblObject_1.Object_ID ON dbo.tblProcessingFile.Loan_ID = dbo.tblLoan.Object_ID ON dbo.tblContactUser.Object_ID = dbo.tblLoan.ContactOwnerID ON dbo.vwDomain_Hierarchy.Object_ID = tblObject_1.Domain_ID ON dbo.tblObject.Object_ID = dbo.tblLoan.ContactOwnerID ON   dbo.tblProspectB2B_CoordinatorStatus.Object_ID =   dbo.tblLoan.ReferralSourceContactID ON tblObject_2.Object_ID =       dbo.tblLoan.ReferralSourceContactID

Answer 1

Your last INNER JOIN has a number of ON statements. Per this question and answer, such syntax is equivalent to a nested subquery.

Answer 2

That is one of the worst queries I have ever seen. Since I cannot figure out how it is supposed to work without the underlying data, this is what I suggest to you.

First find a good sample loan and write a query against this view to return where loan_id = ... Now you have a data set you chan check you changes against more easily than the, possibly, millions of records this returns. Make sure these results make sense (that right join to tbl_objects is bothering me as it makes no sense to return all the objects records)

Now start writing your query with what you think should be the first table (I would suggest that loan is the first table, if it not then the first table is Object left joined to loan)) and the where clause for the loan id. Check your results, did you get the same loan information as teh view query with the where clause added?

Then add each join one at a time and see how it affects the query and whether the results appear to be going off track. Once you have figured out a query that gives the same results with all the tables added in, then you can try for several other loan ids to check. Once those have checked out, then run teh whole query with no where clause and check against the view results (if it is a large number you may need to just see if teh record counts match and visually check through (use order by on both things in order to make sure your results are in the same order). In the process try to use only left joins and not that combination of right and left joins (its ok to leave teh inner ones alone). I make it a habit in complex queries to do all the inner joins first and then the left joins. I never use right joins in production code. Now you are ready to performance tune.

I woudl guess the right join to objects is causing a problem in that it returns teh whole table and the nature of that table name and teh other joins to the same table leads me to believe that he probably wanted a left join. Without knowing the meaning of the data, it is hard to be sure. So first if you are returning too many records for one loan id, then consider if the real problem is that as tables have grown, returning too many records has become problematic.

Also consider that you can often take teh view and replace it with code to get the same results. Views calling views are a poor technique that often leads to performance issues. Often the views on top of the other views call teh same tables and thus you end up joining to them multiple times when you don;t need to.

Check your Explain plan or Execution plan depending on what database backend you have. Analysis of this should show where you might have missing indexes.

Also make sure that every table in the query is needed. This especially true when you join to a view. The view may join to 12 other tables but you only need the data from one of them and it can join to one of your tables. MAke sure that you are not using select * but only returning teh fields the view actually needs. You have inner joins so, by definition, select * is returning fields you don't need.

If your select part of teh view has a distinct in it, then consider if you can weed down the multiple records you get that made distinct needed by changing to a derived table or adding a where clause. To see what is causing the multiples, you may need to temporarily use select * to see all the columns and find out which one is not uniques and is causing the issue.

This whole process is not going to be easy or fun. Just take it slowly, work carefully and methodically and you will get there and have a query that is understandable and maintainable in the end.