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?