Understanding why a cost-based optimizer may pick a poor join order when cardinality estimates go wrong.
A query joins three tables A, B, and C with predicates that the optimizer estimates will return 10 rows from A, but at runtime A actually returns 5 million rows. The optimizer chose a plan with nested-loop joins driving from A into B and C. Which explanation BEST accounts for why this plan is catastrophically slow, and what is the most direct root cause to address?