A developer submits an ORM query for review. In testing it returns exactly the right rows for a customer summary page, but the logged SQL is a SELECT * against a table with about 80 columns, while the page displays only three of them. Which review conclusion is correct?
Select an answer to reveal the explanation.
Short Explanation
Getting the right answer the expensive way is still a problem you'll pay for at scale. Pulling 80 columns to show three is like hauling the whole filing cabinet to read one folder. The trap is treating passing results as proof the generated SQL is acceptable.
Full Explanation
Reviewing ORM output has two parts: confirming that the generated SQL is valid and correct, and confirming that it is efficient for the workload. A SELECT that returns all 80 columns of a wide table moves far more data across the network, uses more memory and buffer cache, and prevents a narrow index from covering the query, even though the visible result is right. The fix is usually a projection or a narrower mapped type so the generated statement names only the needed columns. Declaring the query valid because the rows are correct stops the review halfway; functional correctness says nothing about cost at production volume. Claiming SELECT is invalid standard SQL is false: the asterisk is legal and the statement runs, which is precisely why the inefficiency slips through testing. Building a covering index over all 80 columns would duplicate the table, inflate storage and slow every write, rather than fixing the over-fetching at its source. Exam caveat: the stem's evidence is about wasted columns, not wrong rows, so the answer targets efficiency. Operational check: compare logical reads and bytes returned for the original and the narrowed query on a realistic data set.