When checking for "bad" SQL executions plan and you find those plans with INVENTDIM as a wrong leading table, in your example you use OPTIMIZE FOR UNKNOWN. Would it be better to use FORCE ORDER as a query hint in the Plan guide? Even better, use "forceSelectOrder" together with forceNestedLoop (AX 2012 and above) in the code instead of dealing with the maintenance of Planguides?

If you just use just forceSelectOrder, the SQL Server may use "hash join" type to link tables(that means data will be selected from both tables, then hash for both datasets will be created, and then join performed). That actually means quite bad performance.
To avoid this you may specify something similar to this - @hints = N'OPTION(TABLE HINT (B, INDEX(I_698DIMIDIDX)), TABLE HINT ( a, INDEX(I_174ITEMDIMIDX)), loop join)'
But the general recommendation is to use fewer hints as possible, so OPTIMIZE FOR UNKNOWN should work better in most cases

Denis, have you ever tried to disable parameter sniffing in the database scoped configuration in an on-premises deployment to solve this problem? Having a performance issue that we cannot seem to fix and believe parameter sniffing is the problem based on various tools and metrics.

Hi Joe. For most cases parameter sniffing actually produces a good results, so disabling it is not a good idea. We tried to do this a long time ago, but a lot of queries were affected in negative way

Thanks for the response, Denis. We tried this recently and, as you state, it caused more problems! Lesson learned: do not disable parameter sniffing for Dynamics AX/365 F&O.

Not relevant but related. In our Dynamics CRM implementations, disabling parameter sniffing for a large, customized implementation was a life saver