mysql

MySQL

Name: Nexoxa Bridge
Author: Nexoxa

Connect with mysql:// — schemas, tables, indexes, and a full query lab for MySQL.

SQLmysql://user:password@host:3306/database

The story

These pages use illustrative scenarios (sample names and timelines) to explain real Nexoxa Bridge features. Connection URLs, sidebar panels, and vault behavior match the product; story details are teaching examples, not customer case studies.

The platform team at a fintech startup runs MySQL on RDS for the core ledger and keeps Postgres for analytics — two engines, one on-call rotation. Dev lead Jordan used to keep MySQL Workbench open on a second monitor just to confirm index names before approving PRs.

Jordan pasted mysql:// into Bridge, saved Ledger RDS and Analytics Replica as separate cards, and deleted the Workbench shortcut. The first connect introspected schemas in seconds; the vault sat beside postgres:// tabs in the same encrypted store. When an incident page fired at 2 a.m., Jordan filtered 200k ledger rows in the grid, ran EXPLAIN in Query lab, and never alt-tabbed to another client.

mysql:// is not a second-class citizen in Bridge — it is the same studio chrome with engine-aware catalog and grid behavior.

Connection URL

Scheme: mysql://

Parameters

MySQLstringvaultrequired

mysql://user:password@host:3306/database

Paste the URL in Nexoxa Bridge → New connection. Save a human-readable name — MCP references that name, not the raw URL with embedded passwords.

Step 1

Schema tree

Jordan opens the catalog after every deploy. Tables, views, and indexes appear under the active database without refreshing a separate tool. A missing index on transactions.created_at shows up in the indexes panel before slow-query alerts fire.
Saved names like Ledger RDS mean MCP configs say connection: Ledger RDS instead of leaking hostnames in git.

mysql:// URLs parse host, port (default 3306), database, user, and password. On save, credentials encrypt with AES-256-GCM in Windows Credential Manager. Schema introspection lists tables, views, columns, and indexes compatible with MySQL and MariaDB wire protocol where applicable.

Step 2

Data grid

During the incident, Jordan filters status = pending on a wide transactions table, sorts by amount descending, and spots duplicate gateway references. Inline edits fix test flags; bulk export goes to CSV for the postmortem doc.
The same grid UX works on Postgres tabs — muscle memory transfers across engines.

Spreadsheet-style filtering, sorting, and inline edits on production-sized tables. Shared Query lab and connection switcher: pick a saved name from Connections to jump engines without restarting Bridge.

Step 3

Query lab

Jordan writes a diagnostic SELECT with a forced index hint, runs EXPLAIN, and pastes the plan into the incident channel. No copy-paste from a terminal buffer with ANSI codes.
When the fix ships, the same tab runs the verification query against staging first.

SQL editor with result grids and execution timing. EXPLAIN support for plan analysis. Schema-aware autocomplete where the engine exposes metadata.

Explore the full feature guide: MySQL guide