How to Tune Cold Cache SQL Statements for SQL Server?

Discussion in 'SQL Server' started by Richard To, May 5, 2021.

  1. Richard To

    Richard To Member

    Joined:
    Sep 18, 2017
    Messages:
    88
    Likes Received:
    36
    Trophy Points:
    18
    Gender:
    Male
    For SQL statements that are not executed frequently, so that the relevant data is no longer exists in the buffer cache, a cold cache will significantly affect the performance of a SQL statement. A good performance SQL for hot cache may not be performing well in a cold cache environment. Experience developers will tune their SQL running well for both environments.

    Here the following is an example SQL:

    select * from
    EMPLOYEE A
    where A.EMP_ID IN (SELECT B.EMP_ID from EMP_SUBSIDIARY B
    where B.EMP_DEPT < 'D')​

    Here the following is the query plan in the Tosska proprietary tree format, it takes 8.024 seconds for the first execution with cache delay and it takes 3.7 seconds for the second execution without caching time.
    [​IMG]
    According to the query plan, you may find that the most significant IO consumption is the Table Scan of [EMPLOYEE] table. To simulate the cold cache environment, we can use the DBCC DROPCLEANBUFFERS command to clear the data cache before each execution of rewritten or optimized SQL statement.

    Let me add an optimizer hint OPTION(LOOP JOIN) to the SQL and try to change the query plan from a Hash Match to a Nested Loop join. So, the EMP_ID(EMPLOYEE_PK) and a RID Lookup to [EMPLOYEE] will be used instead of using Table Scan. I hope that the RID Lookup can select fewer data from hard disk with matched EMP_ID in both [EMPLOYEE] and [EMP_SUBSIDIARY].

    select *
    from EMPLOYEE A
    where A.EMP_ID in (select B.EMP_ID
    from EMP_SUBSIDIARY B
    where B.EMP_DEPT < 'D') OPTION(LOOP JOIN)

    Here the following is the query plan, the time is reduced from 8.024 seconds to 1.565 seconds with data cache overhead, and the physical reads are also dropped from 190,621 to 39,044. It shows a wrong IO estimation If you just rely on the SQL Server’s EstimateIO x EstimiateExecutions in the query plan.
    [​IMG]
    There are other even better tuning solutions for this SQL with the A.I. SQL tuning tool in the following:

    Tosska SQL Tuning Expert (TSES™) for SQL Server® - Tosska Technologies Limited

    The following SQL with an optimizer hint generate a more complicated query plan with the best execution time of 0.7 seconds. The SQL is tuned by cold cache simulation that data will be flushed before each execution of SQL alternatives.
    [​IMG]
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice