You can also begin a transaction, query to find out the IDs that would be affected by the update, then perform the update and commit. You must use a transaction isolation-level that is sufficent to assure that there can be no competing interference from other parallel processes – a prospect that can be quite expensive.

If at all possible, use the strategy suggested by the first reply:   “find the records that now have the target-value, whether they were just-updated-by-me or not.”   When you are querying a database, you really want to arrange your workflows such that you only are concerned about “how the data now is,” not “exactly how it got there.”   (Obviously not referring to auditing-considerations when I say that...)   Design clean, low-flying operations that play nicely with others and do not demand high levels of transaction isolation.

If you can do a whole bunch of updates and then query, after all is said and done, “(now that I have finished doing everything that I intended to do, and committed those changes,) show me all the records which now have any of the following values for this field...” then, that is better yet.