That'll get poor plans, not inaccurate row estimations.

https://www.simple-talk.com/sql/backup-and-recovery/backup-verification-tips-for-database-backup-testing/

A large number of things.

Lack of statistics

Conversions or functions on columns

Table variables (including multi-statement UDFs)

Variables in predicates

Plans being reused for executions with different parameters

Generalising queries (eg the Column = @Parameter...

Pretty much, yes.

What are the exact errors you're getting?

Please don't post multiple threads for the same question.

No replies here. Replies to http://www.sqlservercentral.com/Forums/Topic1807856-3077-1.aspx

By 'composite', I assume you mean a multi-column index.

If so, there's no calculations and the values are stored just as they would be with a single column index.

Jeff Moden (8/7/2016)

---

For example (and I'll admit I've not looked it up in the last 2 months or so), I'm pretty sure that the use of NOLOCK hasn't actually been...

The times for the individual statements within the procedure, not time to read tables.

That's the total time for the procedure.

mikes84 (8/6/2016)

---

Regarding cost threshold, I've read many articles that suggest 50 is a good starting point. However, some of the queries and views I'm working with have a cost of...

Increase your cost threshold. Far too low.

Tune your code, tune your indexes. If the views are nested, fix that first.

Consider some form of reporting server to offload the reports to.

No, you should in most cases go for a properly designed normalised data structure.

Otherwise, whether you use json or xml depends...

The answer to your question is 'maybe', because there's no where near enough information to answer any other way.

Talking about interviews, I did one last week. The question that tipped the interview from 'maybe' to 'no' was when I asked about the cause of deadlocks and he replied...