Bug description

After upgrading from Prisma 7.4.2 to 7.5.0, our production MariaDB instance started hitting max_prepared_stmt_count limits, causing query failures under load.

Root cause

PR #29285 switched adapter-mariadb to use the binary MySQL protocol to fix lossy number conversions. This change appears to bypass the statement_cache_size=0 connection string parameter that previously prevented prepared statement accumulation.

With statement_cache_size=0 in our connection URL, we expect prepared statements to not be cached. After the 7.5.0 upgrade, prepared statements accumulate on the server until the global max_prepared_stmt_count limit is reached.

How to reproduce

1. Use @prisma/adapter-mariadb with Prisma 7.5.0
2. Set statement_cache_size=0 in the MySQL connection URL
3. Run the application under production-level traffic
4. Monitor SHOW GLOBAL STATUS LIKE 'Prepared_stmt_count'
5. Observe prepared statements accumulating beyond what statement_cache_size=0 should allow

Note: This does not reproduce under low traffic (e.g., staging) because the global max_prepared_stmt_count limit (default 16382) is never reached.

Expected behavior

statement_cache_size=0 should disable prepared statement caching, matching the behavior in 7.4.2.

Actual behavior

Prepared statements accumulate unboundedly, eventually hitting max_prepared_stmt_count and causing errors.

Environment

• Prisma: 7.5.0 (works correctly on 7.4.2)
• Database: MariaDB (via @prisma/adapter-mariadb)
• statement_cache_size=0 in connection URL
• Issue introduced by PR fix: use mysql binary protocol to avoid a lossy conversion #29285 (binary protocol change)