Adding an additional “order by” column gives me a much worse planHelp optimizing MySQL slow...

In the late 1940’s to early 1950’s what technology was available that could melt a LOT of ice?

Who deserves to be first and second author? PhD student who collected data, research associate who wrote the paper or supervisor?

Placing subfig vertically

How do I deal with a powergamer in a game full of beginners in a school club?

What wound would be of little consequence to a biped but terrible for a quadruped?

Accountant/ lawyer will not return my call

Why does Captain Marvel assume the people on this planet know this?

Word for a person who has no opinion about whether god exists

Are babies of evil humanoid species inherently evil?

Why does the negative sign arise in this thermodynamic relation?

Should I tell my boss the work he did was worthless

Things to avoid when using voltage regulators?

Replacing Windows 7 security updates with anti-virus?

PTIJ: How can I halachically kill a vampire?

Do items de-spawn in Diablo?

Should I take out a loan for a friend to invest on my behalf?

Why is there a voltage between the mains ground and my radiator?

Built-In Shelves/Bookcases - IKEA vs Built

Is "history" a male-biased word ("his+story")?

Could you please stop shuffling the deck and play already?

What Happens when Passenger Refuses to Fly Boeing 737 Max?

Norms on fields

Do Bugbears' arms literally get longer when it's their turn?

Do f-stop and exposure time perfectly cancel?



Adding an additional “order by” column gives me a much worse plan


Help optimizing MySQL slow queryOptimizing ORDER BY for simple MySQL queryDatabase Implementations of ORDER BY in a Subqueryquery performance gains by removing operator hash match inner joinWhy are these two queries having such different executions?How can I update statistics adding the data of the last day only?left outer join - sort operations in the query plan - any ways of tuning this simple query?Why does changing the declared join column order introduce a sort?When can SARGable predicates be pushed into a CTE or derived table?Why does the location of a join change performance?













2















in other words, how can I get rid of the sort operator on the picture below?



enter image description here



the picture above shows the execution plan of the following 2 selects together:



                SELECT   TOP 1 so.OrgType, 
ch.Status,
rcs.DBSstatusDescription,
cid.ApplicationId
FROM tbl_application_crb_initialData cid

INNER JOIN tbl_season_organisationId so
ON cid.OrganisationId = so.OrgId

LEFT JOIN tbl_crbHistory ch
ON cid.ClientReference = ch.ClientReference

LEFT JOIN ref_crbStatus rcs
ON ch.Status = rcs.statusId

ORDER BY cid.DateAdded DESC, ch.DateAdded DESC

SELECT TOP 1 so.OrgType,
ch.Status,
rcs.DBSstatusDescription,
cid.ApplicationId
FROM tbl_application_crb_initialData cid

INNER JOIN tbl_season_organisationId so
ON cid.OrganisationId = so.OrgId

LEFT JOIN tbl_crbHistory ch
ON cid.ClientReference = ch.ClientReference

LEFT JOIN ref_crbStatus rcs
ON ch.Status = rcs.statusId

ORDER BY cid.DateAdded DESC--, ch.DateAdded DESC


the only difference is that on the second query, there is only one column in the order by.



would it make a difference, as I am using top 1?



I believe all the needed info are on the indexes and table definitions that can be seen on the query plan.



if anything else would help to get rid of that sort just let me know, tomorrow I will post all the possible info.










share|improve this question

























  • Those cost % are just estimates and can actually end up being WAY, WAY off. Is the top query actually noticeably slower?

    – Aaron Bertrand
    3 hours ago











  • @AaronBertrand - CPU time 756, Elapsed Time 222, Reads 2357 vs CPU time 0, Elapsed Time 0, Reads 10 from the stats in the plan - most of the tables are pretty small though. Table cardinalities 11, 19, 67,591, 232,528

    – Martin Smith
    2 hours ago








  • 1





    @MartinSmith Thanks, I didn’t look at the plan (mobile), just try my best to make sure drive-by readers don’t put too much weight into those percentages. Sometimes they’re useful, sometimes they’re extremely misleading.

    – Aaron Bertrand
    1 hour ago
















2















in other words, how can I get rid of the sort operator on the picture below?



enter image description here



the picture above shows the execution plan of the following 2 selects together:



                SELECT   TOP 1 so.OrgType, 
ch.Status,
rcs.DBSstatusDescription,
cid.ApplicationId
FROM tbl_application_crb_initialData cid

INNER JOIN tbl_season_organisationId so
ON cid.OrganisationId = so.OrgId

LEFT JOIN tbl_crbHistory ch
ON cid.ClientReference = ch.ClientReference

LEFT JOIN ref_crbStatus rcs
ON ch.Status = rcs.statusId

ORDER BY cid.DateAdded DESC, ch.DateAdded DESC

SELECT TOP 1 so.OrgType,
ch.Status,
rcs.DBSstatusDescription,
cid.ApplicationId
FROM tbl_application_crb_initialData cid

INNER JOIN tbl_season_organisationId so
ON cid.OrganisationId = so.OrgId

LEFT JOIN tbl_crbHistory ch
ON cid.ClientReference = ch.ClientReference

LEFT JOIN ref_crbStatus rcs
ON ch.Status = rcs.statusId

ORDER BY cid.DateAdded DESC--, ch.DateAdded DESC


the only difference is that on the second query, there is only one column in the order by.



would it make a difference, as I am using top 1?



I believe all the needed info are on the indexes and table definitions that can be seen on the query plan.



if anything else would help to get rid of that sort just let me know, tomorrow I will post all the possible info.










share|improve this question

























  • Those cost % are just estimates and can actually end up being WAY, WAY off. Is the top query actually noticeably slower?

    – Aaron Bertrand
    3 hours ago











  • @AaronBertrand - CPU time 756, Elapsed Time 222, Reads 2357 vs CPU time 0, Elapsed Time 0, Reads 10 from the stats in the plan - most of the tables are pretty small though. Table cardinalities 11, 19, 67,591, 232,528

    – Martin Smith
    2 hours ago








  • 1





    @MartinSmith Thanks, I didn’t look at the plan (mobile), just try my best to make sure drive-by readers don’t put too much weight into those percentages. Sometimes they’re useful, sometimes they’re extremely misleading.

    – Aaron Bertrand
    1 hour ago














2












2








2


1






in other words, how can I get rid of the sort operator on the picture below?



enter image description here



the picture above shows the execution plan of the following 2 selects together:



                SELECT   TOP 1 so.OrgType, 
ch.Status,
rcs.DBSstatusDescription,
cid.ApplicationId
FROM tbl_application_crb_initialData cid

INNER JOIN tbl_season_organisationId so
ON cid.OrganisationId = so.OrgId

LEFT JOIN tbl_crbHistory ch
ON cid.ClientReference = ch.ClientReference

LEFT JOIN ref_crbStatus rcs
ON ch.Status = rcs.statusId

ORDER BY cid.DateAdded DESC, ch.DateAdded DESC

SELECT TOP 1 so.OrgType,
ch.Status,
rcs.DBSstatusDescription,
cid.ApplicationId
FROM tbl_application_crb_initialData cid

INNER JOIN tbl_season_organisationId so
ON cid.OrganisationId = so.OrgId

LEFT JOIN tbl_crbHistory ch
ON cid.ClientReference = ch.ClientReference

LEFT JOIN ref_crbStatus rcs
ON ch.Status = rcs.statusId

ORDER BY cid.DateAdded DESC--, ch.DateAdded DESC


the only difference is that on the second query, there is only one column in the order by.



would it make a difference, as I am using top 1?



I believe all the needed info are on the indexes and table definitions that can be seen on the query plan.



if anything else would help to get rid of that sort just let me know, tomorrow I will post all the possible info.










share|improve this question
















in other words, how can I get rid of the sort operator on the picture below?



enter image description here



the picture above shows the execution plan of the following 2 selects together:



                SELECT   TOP 1 so.OrgType, 
ch.Status,
rcs.DBSstatusDescription,
cid.ApplicationId
FROM tbl_application_crb_initialData cid

INNER JOIN tbl_season_organisationId so
ON cid.OrganisationId = so.OrgId

LEFT JOIN tbl_crbHistory ch
ON cid.ClientReference = ch.ClientReference

LEFT JOIN ref_crbStatus rcs
ON ch.Status = rcs.statusId

ORDER BY cid.DateAdded DESC, ch.DateAdded DESC

SELECT TOP 1 so.OrgType,
ch.Status,
rcs.DBSstatusDescription,
cid.ApplicationId
FROM tbl_application_crb_initialData cid

INNER JOIN tbl_season_organisationId so
ON cid.OrganisationId = so.OrgId

LEFT JOIN tbl_crbHistory ch
ON cid.ClientReference = ch.ClientReference

LEFT JOIN ref_crbStatus rcs
ON ch.Status = rcs.statusId

ORDER BY cid.DateAdded DESC--, ch.DateAdded DESC


the only difference is that on the second query, there is only one column in the order by.



would it make a difference, as I am using top 1?



I believe all the needed info are on the indexes and table definitions that can be seen on the query plan.



if anything else would help to get rid of that sort just let me know, tomorrow I will post all the possible info.







sql-server query-performance sql-server-2016 optimization order-by






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 10 mins ago









Martin Smith

63.6k10171255




63.6k10171255










asked 4 hours ago









marcello miorellimarcello miorelli

5,8971962138




5,8971962138













  • Those cost % are just estimates and can actually end up being WAY, WAY off. Is the top query actually noticeably slower?

    – Aaron Bertrand
    3 hours ago











  • @AaronBertrand - CPU time 756, Elapsed Time 222, Reads 2357 vs CPU time 0, Elapsed Time 0, Reads 10 from the stats in the plan - most of the tables are pretty small though. Table cardinalities 11, 19, 67,591, 232,528

    – Martin Smith
    2 hours ago








  • 1





    @MartinSmith Thanks, I didn’t look at the plan (mobile), just try my best to make sure drive-by readers don’t put too much weight into those percentages. Sometimes they’re useful, sometimes they’re extremely misleading.

    – Aaron Bertrand
    1 hour ago



















  • Those cost % are just estimates and can actually end up being WAY, WAY off. Is the top query actually noticeably slower?

    – Aaron Bertrand
    3 hours ago











  • @AaronBertrand - CPU time 756, Elapsed Time 222, Reads 2357 vs CPU time 0, Elapsed Time 0, Reads 10 from the stats in the plan - most of the tables are pretty small though. Table cardinalities 11, 19, 67,591, 232,528

    – Martin Smith
    2 hours ago








  • 1





    @MartinSmith Thanks, I didn’t look at the plan (mobile), just try my best to make sure drive-by readers don’t put too much weight into those percentages. Sometimes they’re useful, sometimes they’re extremely misleading.

    – Aaron Bertrand
    1 hour ago

















Those cost % are just estimates and can actually end up being WAY, WAY off. Is the top query actually noticeably slower?

– Aaron Bertrand
3 hours ago





Those cost % are just estimates and can actually end up being WAY, WAY off. Is the top query actually noticeably slower?

– Aaron Bertrand
3 hours ago













@AaronBertrand - CPU time 756, Elapsed Time 222, Reads 2357 vs CPU time 0, Elapsed Time 0, Reads 10 from the stats in the plan - most of the tables are pretty small though. Table cardinalities 11, 19, 67,591, 232,528

– Martin Smith
2 hours ago







@AaronBertrand - CPU time 756, Elapsed Time 222, Reads 2357 vs CPU time 0, Elapsed Time 0, Reads 10 from the stats in the plan - most of the tables are pretty small though. Table cardinalities 11, 19, 67,591, 232,528

– Martin Smith
2 hours ago






1




1





@MartinSmith Thanks, I didn’t look at the plan (mobile), just try my best to make sure drive-by readers don’t put too much weight into those percentages. Sometimes they’re useful, sometimes they’re extremely misleading.

– Aaron Bertrand
1 hour ago





@MartinSmith Thanks, I didn’t look at the plan (mobile), just try my best to make sure drive-by readers don’t put too much weight into those percentages. Sometimes they’re useful, sometimes they’re extremely misleading.

– Aaron Bertrand
1 hour ago










1 Answer
1






active

oldest

votes


















3














Your question is missing a lot of detail but I can reproduce something similar.



Setup



CREATE TABLE T1(X INT PRIMARY KEY, Y INT INDEX IX)

CREATE TABLE T2(X INT, Y INT , PRIMARY KEY(X, Y))

INSERT INTO T2
OUTPUT INSERTED.* INTO T1
SELECT TOP 1000000 ROW_NUMBER() OVER (ORDER BY @@SPID), ROW_NUMBER() OVER (ORDER BY @@SPID)
FROM sys.all_objects o1, sys.all_objects o2;


Query 1



SELECT TOP 1 T1.Y AS T1Y, T2.Y AS T2Y
FROM T1 JOIN T2 ON T1.X = T2.X
ORDER BY T1.Y;


enter image description here



Query 2



SELECT TOP 1 T1.Y AS T1Y, T2.Y AS T2Y
FROM T1 JOIN T2 ON T1.X = T2.X
ORDER BY T1.Y, T2.Y


enter image description here



Query 3



WITH T  AS
(
SELECT TOP 1 WITH TIES T1.Y AS T1Y, T2.Y AS T2Y
FROM T1 JOIN T2 ON T1.X = T2.X
ORDER BY T1.Y
)
SELECT TOP 1 *
FROM T
ORDER BY T2Y


enter image description here



Query 1 just picks off the TOP 1 from the index in the desired sort order and does the needed joins on the other table for that row. If the join is successful it stops there otherwise it tries the next one in index order until it finds a row that matches or runs out of rows.



Query 2 When adding the new sort column this plan is no longer valid as there could be multiple matches tied with the TOP 1 value and SQL Server decides to join the whole lot and then get the TOP 1 from that.



Query 3 This encourages SQL Server to stick with the first strategy and then just does a TOP 1 Sort on any rows tied with the same value for the first sort key.



For my example data Query 3 works out better than Query 2 but if you have many duplicates tied for the value of the first sort key your milage may differ.



You can try this rewrite and see how it fares



WITH T
AS (SELECT TOP 1 WITH TIES so.OrgType,
ch.Status,
rcs.DBSstatusDescription,
cid.ApplicationId,
ch.DateAdded AS chDateAdded
FROM tbl_application_crb_initialData cid
INNER JOIN tbl_season_organisationId so
ON cid.OrganisationId = so.OrgId
LEFT JOIN tbl_crbHistory ch
ON cid.ClientReference = ch.ClientReference
LEFT JOIN ref_crbStatus rcs
ON ch.Status = rcs.statusId
ORDER BY cid.DateAdded DESC)
SELECT TOP 1 OrgType,
Status,
DBSstatusDescription,
ApplicationId
FROM T
ORDER BY chDateAdded DESC





share|improve this answer

























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "182"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f231950%2fadding-an-additional-order-by-column-gives-me-a-much-worse-plan%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    3














    Your question is missing a lot of detail but I can reproduce something similar.



    Setup



    CREATE TABLE T1(X INT PRIMARY KEY, Y INT INDEX IX)

    CREATE TABLE T2(X INT, Y INT , PRIMARY KEY(X, Y))

    INSERT INTO T2
    OUTPUT INSERTED.* INTO T1
    SELECT TOP 1000000 ROW_NUMBER() OVER (ORDER BY @@SPID), ROW_NUMBER() OVER (ORDER BY @@SPID)
    FROM sys.all_objects o1, sys.all_objects o2;


    Query 1



    SELECT TOP 1 T1.Y AS T1Y, T2.Y AS T2Y
    FROM T1 JOIN T2 ON T1.X = T2.X
    ORDER BY T1.Y;


    enter image description here



    Query 2



    SELECT TOP 1 T1.Y AS T1Y, T2.Y AS T2Y
    FROM T1 JOIN T2 ON T1.X = T2.X
    ORDER BY T1.Y, T2.Y


    enter image description here



    Query 3



    WITH T  AS
    (
    SELECT TOP 1 WITH TIES T1.Y AS T1Y, T2.Y AS T2Y
    FROM T1 JOIN T2 ON T1.X = T2.X
    ORDER BY T1.Y
    )
    SELECT TOP 1 *
    FROM T
    ORDER BY T2Y


    enter image description here



    Query 1 just picks off the TOP 1 from the index in the desired sort order and does the needed joins on the other table for that row. If the join is successful it stops there otherwise it tries the next one in index order until it finds a row that matches or runs out of rows.



    Query 2 When adding the new sort column this plan is no longer valid as there could be multiple matches tied with the TOP 1 value and SQL Server decides to join the whole lot and then get the TOP 1 from that.



    Query 3 This encourages SQL Server to stick with the first strategy and then just does a TOP 1 Sort on any rows tied with the same value for the first sort key.



    For my example data Query 3 works out better than Query 2 but if you have many duplicates tied for the value of the first sort key your milage may differ.



    You can try this rewrite and see how it fares



    WITH T
    AS (SELECT TOP 1 WITH TIES so.OrgType,
    ch.Status,
    rcs.DBSstatusDescription,
    cid.ApplicationId,
    ch.DateAdded AS chDateAdded
    FROM tbl_application_crb_initialData cid
    INNER JOIN tbl_season_organisationId so
    ON cid.OrganisationId = so.OrgId
    LEFT JOIN tbl_crbHistory ch
    ON cid.ClientReference = ch.ClientReference
    LEFT JOIN ref_crbStatus rcs
    ON ch.Status = rcs.statusId
    ORDER BY cid.DateAdded DESC)
    SELECT TOP 1 OrgType,
    Status,
    DBSstatusDescription,
    ApplicationId
    FROM T
    ORDER BY chDateAdded DESC





    share|improve this answer






























      3














      Your question is missing a lot of detail but I can reproduce something similar.



      Setup



      CREATE TABLE T1(X INT PRIMARY KEY, Y INT INDEX IX)

      CREATE TABLE T2(X INT, Y INT , PRIMARY KEY(X, Y))

      INSERT INTO T2
      OUTPUT INSERTED.* INTO T1
      SELECT TOP 1000000 ROW_NUMBER() OVER (ORDER BY @@SPID), ROW_NUMBER() OVER (ORDER BY @@SPID)
      FROM sys.all_objects o1, sys.all_objects o2;


      Query 1



      SELECT TOP 1 T1.Y AS T1Y, T2.Y AS T2Y
      FROM T1 JOIN T2 ON T1.X = T2.X
      ORDER BY T1.Y;


      enter image description here



      Query 2



      SELECT TOP 1 T1.Y AS T1Y, T2.Y AS T2Y
      FROM T1 JOIN T2 ON T1.X = T2.X
      ORDER BY T1.Y, T2.Y


      enter image description here



      Query 3



      WITH T  AS
      (
      SELECT TOP 1 WITH TIES T1.Y AS T1Y, T2.Y AS T2Y
      FROM T1 JOIN T2 ON T1.X = T2.X
      ORDER BY T1.Y
      )
      SELECT TOP 1 *
      FROM T
      ORDER BY T2Y


      enter image description here



      Query 1 just picks off the TOP 1 from the index in the desired sort order and does the needed joins on the other table for that row. If the join is successful it stops there otherwise it tries the next one in index order until it finds a row that matches or runs out of rows.



      Query 2 When adding the new sort column this plan is no longer valid as there could be multiple matches tied with the TOP 1 value and SQL Server decides to join the whole lot and then get the TOP 1 from that.



      Query 3 This encourages SQL Server to stick with the first strategy and then just does a TOP 1 Sort on any rows tied with the same value for the first sort key.



      For my example data Query 3 works out better than Query 2 but if you have many duplicates tied for the value of the first sort key your milage may differ.



      You can try this rewrite and see how it fares



      WITH T
      AS (SELECT TOP 1 WITH TIES so.OrgType,
      ch.Status,
      rcs.DBSstatusDescription,
      cid.ApplicationId,
      ch.DateAdded AS chDateAdded
      FROM tbl_application_crb_initialData cid
      INNER JOIN tbl_season_organisationId so
      ON cid.OrganisationId = so.OrgId
      LEFT JOIN tbl_crbHistory ch
      ON cid.ClientReference = ch.ClientReference
      LEFT JOIN ref_crbStatus rcs
      ON ch.Status = rcs.statusId
      ORDER BY cid.DateAdded DESC)
      SELECT TOP 1 OrgType,
      Status,
      DBSstatusDescription,
      ApplicationId
      FROM T
      ORDER BY chDateAdded DESC





      share|improve this answer




























        3












        3








        3







        Your question is missing a lot of detail but I can reproduce something similar.



        Setup



        CREATE TABLE T1(X INT PRIMARY KEY, Y INT INDEX IX)

        CREATE TABLE T2(X INT, Y INT , PRIMARY KEY(X, Y))

        INSERT INTO T2
        OUTPUT INSERTED.* INTO T1
        SELECT TOP 1000000 ROW_NUMBER() OVER (ORDER BY @@SPID), ROW_NUMBER() OVER (ORDER BY @@SPID)
        FROM sys.all_objects o1, sys.all_objects o2;


        Query 1



        SELECT TOP 1 T1.Y AS T1Y, T2.Y AS T2Y
        FROM T1 JOIN T2 ON T1.X = T2.X
        ORDER BY T1.Y;


        enter image description here



        Query 2



        SELECT TOP 1 T1.Y AS T1Y, T2.Y AS T2Y
        FROM T1 JOIN T2 ON T1.X = T2.X
        ORDER BY T1.Y, T2.Y


        enter image description here



        Query 3



        WITH T  AS
        (
        SELECT TOP 1 WITH TIES T1.Y AS T1Y, T2.Y AS T2Y
        FROM T1 JOIN T2 ON T1.X = T2.X
        ORDER BY T1.Y
        )
        SELECT TOP 1 *
        FROM T
        ORDER BY T2Y


        enter image description here



        Query 1 just picks off the TOP 1 from the index in the desired sort order and does the needed joins on the other table for that row. If the join is successful it stops there otherwise it tries the next one in index order until it finds a row that matches or runs out of rows.



        Query 2 When adding the new sort column this plan is no longer valid as there could be multiple matches tied with the TOP 1 value and SQL Server decides to join the whole lot and then get the TOP 1 from that.



        Query 3 This encourages SQL Server to stick with the first strategy and then just does a TOP 1 Sort on any rows tied with the same value for the first sort key.



        For my example data Query 3 works out better than Query 2 but if you have many duplicates tied for the value of the first sort key your milage may differ.



        You can try this rewrite and see how it fares



        WITH T
        AS (SELECT TOP 1 WITH TIES so.OrgType,
        ch.Status,
        rcs.DBSstatusDescription,
        cid.ApplicationId,
        ch.DateAdded AS chDateAdded
        FROM tbl_application_crb_initialData cid
        INNER JOIN tbl_season_organisationId so
        ON cid.OrganisationId = so.OrgId
        LEFT JOIN tbl_crbHistory ch
        ON cid.ClientReference = ch.ClientReference
        LEFT JOIN ref_crbStatus rcs
        ON ch.Status = rcs.statusId
        ORDER BY cid.DateAdded DESC)
        SELECT TOP 1 OrgType,
        Status,
        DBSstatusDescription,
        ApplicationId
        FROM T
        ORDER BY chDateAdded DESC





        share|improve this answer















        Your question is missing a lot of detail but I can reproduce something similar.



        Setup



        CREATE TABLE T1(X INT PRIMARY KEY, Y INT INDEX IX)

        CREATE TABLE T2(X INT, Y INT , PRIMARY KEY(X, Y))

        INSERT INTO T2
        OUTPUT INSERTED.* INTO T1
        SELECT TOP 1000000 ROW_NUMBER() OVER (ORDER BY @@SPID), ROW_NUMBER() OVER (ORDER BY @@SPID)
        FROM sys.all_objects o1, sys.all_objects o2;


        Query 1



        SELECT TOP 1 T1.Y AS T1Y, T2.Y AS T2Y
        FROM T1 JOIN T2 ON T1.X = T2.X
        ORDER BY T1.Y;


        enter image description here



        Query 2



        SELECT TOP 1 T1.Y AS T1Y, T2.Y AS T2Y
        FROM T1 JOIN T2 ON T1.X = T2.X
        ORDER BY T1.Y, T2.Y


        enter image description here



        Query 3



        WITH T  AS
        (
        SELECT TOP 1 WITH TIES T1.Y AS T1Y, T2.Y AS T2Y
        FROM T1 JOIN T2 ON T1.X = T2.X
        ORDER BY T1.Y
        )
        SELECT TOP 1 *
        FROM T
        ORDER BY T2Y


        enter image description here



        Query 1 just picks off the TOP 1 from the index in the desired sort order and does the needed joins on the other table for that row. If the join is successful it stops there otherwise it tries the next one in index order until it finds a row that matches or runs out of rows.



        Query 2 When adding the new sort column this plan is no longer valid as there could be multiple matches tied with the TOP 1 value and SQL Server decides to join the whole lot and then get the TOP 1 from that.



        Query 3 This encourages SQL Server to stick with the first strategy and then just does a TOP 1 Sort on any rows tied with the same value for the first sort key.



        For my example data Query 3 works out better than Query 2 but if you have many duplicates tied for the value of the first sort key your milage may differ.



        You can try this rewrite and see how it fares



        WITH T
        AS (SELECT TOP 1 WITH TIES so.OrgType,
        ch.Status,
        rcs.DBSstatusDescription,
        cid.ApplicationId,
        ch.DateAdded AS chDateAdded
        FROM tbl_application_crb_initialData cid
        INNER JOIN tbl_season_organisationId so
        ON cid.OrganisationId = so.OrgId
        LEFT JOIN tbl_crbHistory ch
        ON cid.ClientReference = ch.ClientReference
        LEFT JOIN ref_crbStatus rcs
        ON ch.Status = rcs.statusId
        ORDER BY cid.DateAdded DESC)
        SELECT TOP 1 OrgType,
        Status,
        DBSstatusDescription,
        ApplicationId
        FROM T
        ORDER BY chDateAdded DESC






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 1 hour ago

























        answered 3 hours ago









        Martin SmithMartin Smith

        63.6k10171255




        63.6k10171255






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Database Administrators Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f231950%2fadding-an-additional-order-by-column-gives-me-a-much-worse-plan%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Fairchild Swearingen Metro Inhaltsverzeichnis Geschichte | Innenausstattung | Nutzung | Zwischenfälle...

            Pilgersdorf Inhaltsverzeichnis Geografie | Geschichte | Bevölkerungsentwicklung | Politik | Kultur...

            Marineschifffahrtleitung Inhaltsverzeichnis Geschichte | Heutige Organisation der NATO | Nationale und...