Explorer

studioexplorerschemanavigation

The tree holds one root per open connection. Ctrl+B puts it away and brings it back, from anywhere in the window, since the panel being hidden is exactly when the focus is somewhere else.

What the tree holds

Every connection opens into the same six branches, each carrying its count: tables, views, indexes, triggers, sequences and routines. Selecting anything fills the inspector on the right, and that is where a table's columns, their types and its keys are read.

Routines are taken from INFORMATION_SCHEMA, so what you see is what the engine has rather than what a script file claims.

Row counts

The number comes from the catalogue's own counter rather than from a scan, which is why a table of a hundred and eighty thousand rows reports as quickly as one of eight. See functions.

Counts are still fetched in the background against a deadline, so a database that cannot answer that cheaply does not hold the tree while it works. A count that has not arrived says as much rather than showing a stale number.

The keys the tree owns

Key Does
F2 Rename
F4 Structure
Delete Drop, through the same question the context menu asks
Letters Walk the selection to the first open node starting with them

Type-ahead has a pause of about a second, which is what turns two words into two searches rather than one long prefix that matches nothing.

Pointer Does
Double click Open the table's data
Middle click Open its data in a tab that does not come to the front
Right click The object's menu

Middle click is worth knowing if you are collecting several tables to look at: they open behind what you are doing rather than interrupting it.

Filtering across every database

The filter searches every open database at once and shows the path to each match, so you do not have to remember which connection a table lives in. Branches above a match are kept, so a result reads in context.

The object inspector

Selecting an object fills the panel on the right: what it is, what it costs to read, which indexes it has, what references it and what it references, and its CREATE statement. It follows the selection rather than opening as a dialog, because comparing two objects one after the other is something people do constantly and a modal window makes it slow.

Each load cancels the one before it, so arrow-keying down a long tree does not queue a schema read per row.

The definition can be copied, or opened in a query editor.

Three things there matter more than they look.

References go both ways. Most clients show what a table points at. This one also shows what points at it, which is the direction you need before dropping anything.

The definition is rendered from the catalogue. Schema has been stored as a parsed tree since engine 9.0.0 and is rendered on demand, so what you read is what the database will act on. Where a definition cannot be rendered faithfully, it is withheld rather than approximated. See INFORMATION_SCHEMA.

It says which columns can be reached through an index, and that includes the case the engine makes easy to miss: a primary key with no index on it. This engine does not create one for a PRIMARY KEY, so a table can have a key that no index covers, and an insert with an explicit key then degrades as the table grows. The catalogue knows; the inspector says so before anybody notices the slowdown.

The command palette

Ctrl+K, from anywhere including the welcome screen. It finds commands and objects in one list, across every open connection. The right-hand half of each line says which: a connection name for an object, a keyboard shortcut for a command.

The list is built when the palette opens, from the tree that is already loaded, so opening it costs nothing and asks the database nothing. Twelve lines at a time, since this is for finding something you can name rather than for browsing.

Before you type anything it shows what you chose recently. The ranking after that is deliberately dull: an exact name first, then what starts with what you typed, then what contains it. A cleverer score is the kind of thing that feels good the day it is written and then puts the wrong table first for a year.

Arrows move and wrap around, Enter accepts, Escape closes. An empty list does nothing on Enter, since a palette that quietly ran the first thing it could find would be worse.

Which connection an action goes to

The connection the node came from, always. Studio can have three databases open, and a command on a node in the second one runs there whatever the tree selection or the front tab happen to be.

This is worth stating because the alternative is common and quietly destructive: tools that act on "the active connection" will happily run your DROP against the wrong database when the selection moved and you did not notice.

Where to go next