How to connect MySQL to ChatGPT without inheriting hidden session settings

The connection can succeed and the answer can still depend on whichever MySQL session the pool handed to ChatGPT.

One connection uses UTC and strict SQL mode. Another inherited a local time zone, permissive grouping rules, or a different collation. The SQL is valid in both sessions, but dates, comparisons, grouping, and errors no longer mean the same thing.

When you connect MySQL to ChatGPT, define the session as part of the tool contract—not as an accidental property of the driver.

Why MySQL session state changes an AI answer

MySQL behavior is influenced by server defaults, user defaults, connection parameters, initialization statements, and state left on a reused connection. Important settings include:

• time_zone for timestamp conversion and date boundaries;
• sql_mode for grouping, invalid dates, truncation, and strictness;
• character_set_connection and collation_connection for text interpretation and comparison;
• transaction isolation and read-only state;
• the selected database and effective database identity.

A prompt cannot reliably compensate for an unknown execution environment. The connector must establish and verify that environment before SQL runs.

Write the session contract first

For each approved workflow, record a versioned baseline:

• database host, environment, and approved database;
• database role and expected grants;
• session time zone, normally UTC unless the metric requires another zone;
• required SQL modes, including a deliberate decision about ONLY_FULL_GROUP_BY and strict modes;
• connection character set and collation;
• transaction isolation, statement timeout strategy, row limit, and read-only enforcement;
• tool, schema, and semantic-definition versions.

The contract should live in trusted connector configuration. Do not let model output choose a weaker SQL mode or switch the session to a different database.

For the wider access boundary, use read-only MCP database access.

Initialize every checked-out connection

Run a trusted initialization sequence when a physical connection is created and again when a pooled connection is checked out if the pool cannot prove a complete reset. Set only the values the workflow owns, and reject the connection if initialization fails.

A baseline may establish UTC, the reviewed SQL mode, utf8mb4, the required collation, transaction settings, and the approved database. Use driver-supported parameters and server-side controls where practical. The exact statements depend on the MySQL version and deployment.

This is not query generation. It is runtime preparation performed outside model control.

Verify instead of assuming

Before enabling the connection, read the effective session values and compare them with the expected contract. Create a compact fingerprint from the normalized values and attach the contract version or digest to the operation trace.

If a required value differs, fail closed with a structured configuration error. Do not continue and ask the model to add compensating SQL to every query.

Verification should include the authenticated database identity, selected database, time zone, SQL mode, connection character set, collation, isolation, and read-only state where observable.

Make time boundaries explicit

Questions such as “orders today,” “revenue last month,” and “tickets opened this week” require a business time zone and a cutoff. Store timestamps consistently, pass explicit start and end instants, and return the zone and observed time with the result.

Do not rely on CURDATE(), implicit conversion, or the session's local zone without recording what those values mean. Daylight-saving transitions and mixed TIMESTAMP/DATETIME usage deserve fixture tests.

See the ChatGPT database timezone and cutoff contract.

Treat SQL mode as semantics, not compatibility

A permissive session may accept a grouped query that a strict session rejects, truncate a value instead of failing, or normalize an invalid date. That can turn a clear error into a plausible but unstable answer.

Choose the production SQL mode deliberately, use it in development and replay tests, and return structured failures when generated SQL violates it. Do not weaken the mode merely to make model-generated SQL pass.

Control character set and collation

Text filters, ordering, uniqueness, case sensitivity, and accent handling can change with collation. A question asking for a customer, SKU, or region may match a different set of rows under another connection.

Parameterize values with the correct driver types, use utf8mb4 where appropriate, and qualify comparison behavior in approved views or operations. Include international text, emoji, case, accents, and trailing-space behavior in the test set.

Reset pooled connections completely

A prior request may change the database, time zone, SQL mode, temporary objects, transaction state, or user variables. Returning that session to the pool without a verified reset lets one workflow influence the next.

Rollback open transactions, discard or recreate unsafe sessions, clear workflow-owned state, reapply the baseline, and verify it before reuse. Bound connection lifetime and make reset failures observable.

The same principle appears in PostgreSQL MCP connection-pool session resets, although the concrete controls differ.

Use qualified, approved objects

Do not let an unqualified table name resolve against an accidental database. Expose approved views or narrow tools, qualify objects in reviewed query shapes, and prevent the model from issuing USE against arbitrary databases.

The schema-discovery surface should describe only approved objects and should carry its own version and freshness evidence.

Test the contract with pairs that should agree

1. Run the same question on a new connection and a reused connection.
2. Change the server default time zone and verify the connector still produces the approved boundary.
3. Remove a required SQL mode and require connection rejection.
4. Compare case, accent, emoji, and non-ASCII filters.
5. Leave a transaction open, change a session value, and return the connection to the pool.
6. Attempt to switch databases or weaken read-only behavior.
7. Repeat after driver, server, pool, or configuration changes.

Compare the normalized result and the session fingerprint. A test that checks only whether the SQL executed will miss the actual boundary.

Return the execution context with the answer

A reviewable result should include source, database, authenticated role, schema or view, time zone, cutoff, SQL-mode contract version, collation where relevant, row count, truncation, freshness, and trace ID. Avoid returning secrets or raw connection strings.

This evidence turns “ChatGPT said” into a statement the team can reproduce.

Where Conexor fits

Conexor provides MCP infrastructure for connecting ChatGPT and other AI clients to databases and APIs through governed tools. A verified MySQL session contract keeps execution settings, identity, scope, and evidence explicit when a workflow moves from a demo to pooled production traffic.

Explore the ChatGPT database connector

For MySQL-specific setup, continue with the MySQL MCP connection guide.