Both of the examples provided do different things although they may look similar. Use the construct designed to do what you want. Worrying about "optimization" here is silly and premature: a good model and good design should come first.
The first case is one query -- it returns one result set (of presumably up to 3 items, assuming that ID is a PK). The order of records in the set is not defined as there is no ORDER BY.
The second case has three queries -- and thus three result sets (the order of the result sets in relationship to each-other is defined) -- each result set (assuming again that ID is a PK) will result in 0 or 1 records.
Now, if only it were that simple... depending on whether the second was executed inside a transaction or not (and what isolation level of transaction and what guarantees the backend makes) determines if the same items are guaranteed to be returned in both cases. That is, imagine the record with ID=2 is deleted after the SELECT ID=1 but before SELECT ID=2 -- what should the results be?
All that being said, the "correct" choice is likely the single select, although it is possible to imagine pathological cases where the second is desired. As a bonus, it is also generally easier to deal with a single result set.
I suspect the first case will also be [slightly] better performing just because of the small overheads for query execution and, in any case, it should be no slower than the second. The difference in performance may or may not be negligible depending upon other factors including connection latency. However, the only way to know "for certain" is to run performance tests on actual data/usage and inspect query plans (see EXPLAIN
).
Happy coding.