Brent Ozar digs into some of the nuance:
SQL Server brought back 1856 of an estimated 1856 rows. So far, so good. But what happens when we start running functions on the parameter we’re searching for, like if it’s a parameter that we need to clean up. How will this affect our estimated number of rows:
Your knee-jerk reaction is probably to say, “FUNCTIONS BAD!” especially given that this is a case-insensitive database. But let’s test that hypothesis across time, across different database compatibility levels:
Brent give some of the nuance behind this. Which, in fairness, aligns with what some of the best performance tuning practitioners have frequently stated. But in contra-fairness, Brent shows how that advice should also change depending on the version of SQL Server, and how the first few versions of SQL Server after the no-longer-new cardinality estimator behaved radically differently from pre-2014 or post-2019.