I've watched that last part unfold on many occasions. Usually I'd be brought in because the developers have done everything down to "copying the data to denormalized tables[0]" to try to sort out slowness. Most of the time, just "blindly investigating the schema" will turn up something frightening that the ORM did, or a mess of inappropriate indexes. Two indexes on a table used by nearly every query in the database caused 30 second requests to yield sub-second results in one case[1]. I'm never willing to walk in and promise that, but I can't think of a time it hasn't happened when similar circumstances were presented to me.
So if you're dragging your feet about learning SQL, take this as my encouragement: it's one of those things where the rewards come quick and the effort is far less than you probably expect.
[0] ... with a broken sync process that has to be run carefully b/c it hammers the already over-sized database every time it fires.
[1] If memory serves, it was an account table ... used a GUID between the app and the database, but primary key was an integer auto-incrementing field which was used as the FK to other tables. All I remember was adding a unique index to the GUID field and including the e-mail address/name columns which were included in every query. Ran the fix in production and it felt like "the dam broke".