SQL Server Cardinality Estimation Warning [duplicate]

Question

This question already has an answer here:

Inserting with implicit type conversion causes warning for cardinality estimates (1 answer)

Closed 2 months ago.

How can I fix the following cardinality estimation warning?

while exists(select 1 from @images)
begin
   declare @imageid     int
   declare @filename    varchar(max)
   select TOP (1)
      @imageid = [imageid],
      @filename = concat([imageid], '.', [extension])
   from
      @images
   order by
      [imageid]
   ...
   delete @images where [imageid] = @imageid
end

SQL Server Compatibility Level: SQL Server 2019 (150)

Answer 1

Sometimes the warning is nothing more than that, just a warning, and not something actually affecting performance.

The two things that are most likely affecting your performance are the Table Variable, and the fact you're looping instead of using a more relational solution. So I'd first run a SELECT * INTO #images FROM @images to put it inside of a Temp Table before your WHILE loop, and then use that Temp Table inside the loop instead, to potentially improve performance.

To answer your question though, I believe the fact that your imageid is an INT but you're using it in a string function like CONCAT() is where the Implicit Conversion is coming from that is inducing that Cardinality Estimate warning. If you stored a copy of it in your @images table variable already casted as a string data type that was the same type as the extension field and used it in the CONCAT() function instead then the warning should go away.

Also, Table Variables typically result in poor Cardinality Estimates themselves because of their lack of statistics, which may be why the "Estimated Number of Rows Per Execution" is showing 1. (Note there's been improvements in SQL Server 2019.)

Answer 2

Let me just emphasize that those types of warnings are essentially useless, unless you actually dig into the query and see where the conversion is taking place.

Below will produce such warning, which is total nonsense. The CAST does in no way affect cardinality estimation:

SELECT CAST(p.ProductID AS varchar(20))
FROM Production.Product AS p

The warning for below is totally valid, however:

SELECT *
FROM Production.Product AS p
WHERE CAST(p.ProductID AS varchar(20)) = 23

Note that I'm using an explicit CAST in above examples, for clarity. The same principle applies for implicit conversions as well.