I don't think so.
First of all, conceptually, it doesn't make sense. There is no way for the query engine to know that a candidate foreign key column doesn't potentially contain values from another table or unrelated values entirely. It can't trust that what appears to be an FK based on current data actually is and always will be with the way the system currently exists.
Additionally, even if it could know that, it would be difficult for it to make a recommendation about it. Because foreign keys means foreign key constraints. And FK constraints have side effects -- either blocking or setting a null/fixed value or cascading changes -- the query engine isn't going to have any idea which of those is correct for a given relationship between two entities. If I delete an order as invalid, then I definitely want to delete the order items that were on the order. But, if I delete a product from the catalog or the customer from the person table, I don't want to let that happen if someone has already placed an order using that relationship. I need to keep that order items or order around if the customer has paid already. I need to know how the business operates, which means I need to know what the entities in the database actually represent and what they actually mean. That information isn't represented in the RDBMS at all... so there is no way for Query Store to know it.
Finally, even if it could figure out both of those, the utility is still quite low. One of the issues with foreign key constraints is that the blocking/setting/cascading side effects means the applications interacting with the data in the system need to execute queries in the proper order. Before you insert here, you must insert here. If you delete here, you need to update here first. The whole application needs to be written with the knowledge that those foreign key constraints exist and function in a given way.
I think the best Query Store could do is recommend an index on a column that you happen
(Réponse tronquée)
