I end up helping developers when they get stuck all the time and it is really amazing to me how many people get to the "senior developer" point in their career with very little understanding of how to use SQL tracing (e.g. MS SQL server) and IDE debugging.
Even the concept of the "print line" debugging into a lot file seems kind of foreign to them sometimes.
They instead rely on running the code, changing something, running it again, etc.
I am a big fan of reading through the code. That is almost always enough for me to find the issue and point it out to them assuming I understand the input and output context well enough. But if that doesn't work, add a debug point and fire it up. Not using a debugger seems like a massive waste of time in a situation like this. So much so that I have started asking "did you debug this" or "have you watched this happen in a debugger" before I will help out much. If they say "no" because they don't know how, I will teach them to do so.
Yes, I think it might be SQL specific but you can normally do this in any transnational db I have worked with (I am old, I don't use GraphQL or NoSQL dbs very often, if at all).
Basically, it is just a journal of all queries (really ANYTHING going on in the db but for developers it is useful to limit to queries) and typically filtered by database and by keyword (e.g. table or stored procedure name).
You can set up a trace to track long-running queries on a production server (DBA might do this) or on a dev server a developer might use it to capture SQL run from their code (e.g. a complex stored procedure with a lot of input params) so you don't have to try to assemble the SQL using a debugger, for example.
A good example might be "I am doing everything right in code, but the data set is coming back empty" so you profile it and realize the SQL is being called with an empty string and not a null, or whatever. When reviewing the code you thought "it will be a null". That kind of thing.
Even the concept of the "print line" debugging into a lot file seems kind of foreign to them sometimes.
They instead rely on running the code, changing something, running it again, etc.
I am a big fan of reading through the code. That is almost always enough for me to find the issue and point it out to them assuming I understand the input and output context well enough. But if that doesn't work, add a debug point and fire it up. Not using a debugger seems like a massive waste of time in a situation like this. So much so that I have started asking "did you debug this" or "have you watched this happen in a debugger" before I will help out much. If they say "no" because they don't know how, I will teach them to do so.