MySQL Prepared Statement Cache destroyed by unique traceid

[commercebuild-daniel]

When enabling sqlcommenter, unique trace ids are added to the sql query as a comment. For MySQL this makes each prepared statement unique, and so the query plan cache never gets hit. Worse it causes each client side connection to hold the max (default 250 using hikari connection pool) number of prepared statements, and then on the server, the summed total of all prepared statement caches hits max_prepared_stmt_count and causes queries to fail.

How can we associate GCP Query insights with our request and application logs by trace id without destroying the applications query performance? It seems the much touted integration with GCP Cloud Trace is not possible without hitting this issue?

[roji]

Note that this is a problem for other databases as well, not just MySQL (e.g. PostgreSQL prepared statements, SQL Server..); integrating constantly-changing information into the SQL is fundamentally incompatible with most database approaches to SQL caching, prepared statements, etc. In an ideal world, such information can be send outside the SQL via some other database protocol mechanism, but such mechanisms don't necessarily exist.