A. Yes and no. Say you include a userID in the large table that stores all the stack overflow questions, where the user ID is for the person who posted the question. The type of query that would be affected by this is if you look up all stack overflow questions for a particular userID.
The reasoning goes something like "if there are a billion questions randomly ordered, how do you know you've found all the questions for the user Giorgi?". Intuition tells us you'd have to check all billion questions.
The important pieces here are that
1. there are a huge number of records
2. you have to check each of them to know you've found all matching questions.
However it will only affect searches that use this new field.
So then to answer your second question:
B. If we sort the questions by userID, then we don't have to look at all of the records to know we've found them all! In SQL this is known as "indexing a table". You do it by specifying the table (in this case questions) and then what fields you want to index or sort by (userID).
This is a common practice in SQL optimization, especially in foreign keys that are on large tables. In my opinion anything over 10,000 records could be a candidate for indexing this way, but the real benchmark is whether or not your searches are performing slowly. If they aren't causing any issues then there's no reason to index since there is a small overhead associated with it.
Hope this answers your questions!