> Additionally learn stored procedures.

For sure, but have a solid grounding in set theory to go with it.

I've dealt with so many poorly-performing stored procedures that ended up being written as iteration over a CURSOR when they could have been done with sets. Programmers who don't grok set theory reach for iterative constructs which, while they work fine, are an impedance mismatch with SQL.

At least in that case you can refactor the stored proc to be more performant without pushing application changes.

Agreed, however that applies to SQL in general.

I have seen DBAs make wonders without changing queries, only by adding the right set of indexes.