Something like: /* dbxperience:request=9a7cd2a6 */ SELECT ....
I have not tested it, but this is something google cloud sql recently promoted: https://cloud.google.com/blog/products/databases/get-ahead-o...
I use this in prod; it’s great. Expensive though.
https://www.datadoghq.com/blog/mysql-monitoring-with-datadog...
Datadog is tracing the request from the application akin to something like
openTrace("Query Name", queryStr)
db.Query(queryStr)
closeTrace()
I would love for a better mechanism than SQL comments for distributed tracing all the way to the database.
What are you getting from the DB logs that you can't get elsewhere?
- Explain plans for slow queries, via auto_explain in Postgres. You could get really fancy here and convert the pieces of an explain plan (Aggregate, ModifyTable, FullTableScan) into proper distributed traces. Hard to tell, but it looks like GCP might offer that.
- Various errors logs associated with queries that require more detail than a SQL state code. For example, lock timeouts.
- Debugging, especially root cause analysis when you're trying to figure out why something broke. The trace IDs help build up context.
https://marketplace.visualstudio.com/items?itemName=apollogr...
sure, inserts are slightly more inconvenient. but the clarity and performance control on reads unparalleled.
But most programmers are using frameworks and ORMs and things that hide away what is actually happening with the database. A normal developer can look at a chunk of code on their side and have no real idea of what is happening on the database behind them.
What webdevelopers need is backend profiling information e.g. actual SQL queries and timings, shown beside all the frontend profiling information (e.g. in webdeveloper tools in the browser).
This profiling introspection can come from tooling in front of the database(s).
I recall seeing a blog about how the Stackoverflow team have nice tooling that does this for them. (Impossible to google for words like "stackoverflow profiling" and things!)