I've had situations when very complicated execution plans showed billions of percents for single operations within a query plan. Unfortunately I did not capture these extreme situations and have only pretty modest percentage example. Just up to several million percents:
That is documented bug and very well described by Aaron Bertrand on StackExchange:
In the theory, SUM of all tasks in Execution plan must not exceed 100%, but as you see it is not always the truth.
In this post I try to reproduce that bug in test environment, learn it's dependencies and workaround.
At first will create a test table and fill it wit 4K dummy records.
Then copy-paste following code in SSMS, highlight it, but do not execute. Just click "Display Estimated Execution Plan" or press "Ctrl+L"
You will get thousands of percents in the bottom line.
Will look why did it happened.
First look at Estimated Cost:
Estimated Subtree Cost for the whole query is 0.0063008.
Estimated Cost for "Clustered Index Delete" is 0.108937, which is exactly 1728.939% from the cost of whole query.
That means that percentage was calculated correctly, but Estimated Subtree Cost for the whole query was not.
It is obvious why that was happened. As you can see, the query contains two sub queries, but total Subtree Cost is calculated only for the first sub-query, without including costs for the second sub-query.
Now, when we know WHY and HOW the problem happens, will take a look at what is contributing to the additional percentage.
First, will double amount of records by using second part of the first query:
Look at estimated execution plan again:
That is easy to explain. In order to delete, SQL Server has to deal with higher volume of data, that results in higher Estimated Costs.
Now will try to add bunch of indexes to our table:
I'd expect percentages also to rise:
As the conclusion I'd say:
In case you see crazy percentage values in your Execution query plan:
Everything is OK, that is just SSMS does not show you correct percentages.