Docs / Connections: MySQL

Ask MySQL

Attach a server and ask. Verbiqo reads performance_schema, sys and the server’s status, never your rows.

Attach

/mysql orders-primary

Verbiqo shows the product, version and role: source, replica or group member.

What to ask

Every check and the words that bring it in: MySQL checks.

Plans need one more grant. MySQL plans a statement only for an account that may read its tables, which the monitoring account cannot by default. Without SELECT on them (Level 5), the digest figures stand in, and a finding says when a plan would settle a question.

Questions no check covers

Available from Verbiqo 0.1.26. This is in the next release; 0.1.25 does not have it yet.

Why it helps: Ask anything reasonable about the server in MySQL’s terms, not only what Verbiqo’s checks cover, and get the answer read from the server rather than told how to read it yourself.

Ask What columns does shop.orders have? Which stored procedures are in shop? What is the definition of view shop.v_totals?

1. What exists

   Verbiqo first reads what is there: the schemas with how many tables each has, the tables and views with their sizes (every name up to about 200; above that, the counts and the largest), and anything the question names. Names and sizes only, never rows.

2. The model reads

   The model writes its reads with the real names, and Verbiqo checks and runs each one, as for every question. If the model explains how to do it instead (USE, for example), Verbiqo sends it back once to read.

3. Which one?

   When the answer depends on which one you mean, such as two tables called orders in different schemas, the model may ask you, offering only names that exist.

4. Long lists

   A read returns at most 500 rows, and the answer says when a list was cut. Say show the next 500 to continue: Verbiqo reads the next part itself.

Limits:

• One answer does not list thousands of names. A large list comes in parts: by schema, by a name pattern, or 500 at a time.
• Only what the monitoring account can see. MySQL shows only the tables the account holds a privilege on. With the recommended REFERENCES grant (level 3 in set-up), table definitions are readable through information_schema and SHOW CREATE TABLE and rows are not; DESCRIBE and SHOW COLUMNS still need SELECT. Without it, tables are seen by name only, from activity statistics, and Verbiqo gives the grant. Where it cannot see something, the answer says so rather than treating it as absent.
• A limited number of reads per question. A broad question may be answered in part, and the answer says what was not read.
• Checks keep their questions. A question one of Verbiqo’s checks covers (settings, slow queries, replication, sizes, whether a change helped, a pasted error or statement) takes that check, as before. The wording decides: For example, list tables takes the schema check, a question about indexes takes the performance check, and one about accounts takes the security check.
• A connection with no schema. A MySQL connection is to the server, and its schema is optional. Name the schema in the question (shop.orders). If a read leans on a default schema anyway (a plain SHOW TABLES), Verbiqo tells the model to name one and lists the schemas this account can see.
• Organization limits. Where your organization limits how much Verbiqo reads per question, the list of what exists is not read first; the rest still applies.

Explain a slow statement

Paste it into the question:

Why is this slow? DELETE FROM orders WHERE created < '2026-01-01'

1. Plan

   Verbiqo asks MySQL for the plan. The statement never runs. An UPDATE or DELETE is planned as the SELECT that finds the same rows.

2. Read it

   Full scans, indexes hidden by a function around the column, joins without an index, sorts. For a write: the rows it locks while it runs, the tables a delete cascades into, the indexes it maintains.

Plans need SELECT on the statement’s tables (Level 5), only if your policy allows. Verbiqo still reads no rows: every statement other than a plan stays limited to the monitoring schemas. EXPLAIN ANALYZE, which runs the statement, is refused.

Check that a change helped

Why it helps: it tells you, from the server’s own counters, whether a setting you changed did what it was meant to, so you keep what works and undo what does not.

1. Review

   Ask What should I tune? Verbiqo saves a reading of the server on this computer: the settings, what it recommended, its counters and its busiest statements.

2. Apply

   Run the statements you choose (SET PERSIST takes effect at once, and survives a restart).

3. Wait

   Give it at least a day of normal work; a week if the workload has a weekly cycle.

4. Ask

   Ask Did the changes help?

Under the answer, Verbiqo shows which recommendations you applied, applied differently, did not apply, or persisted for the next restart (SET PERSIST_ONLY); when each took effect, from MySQL’s own record of when a setting was set and by whom; a before-and-after table per query and per transaction; and a verdict per change: improved, measure improved, speed unchanged, no measurable change, worse, mixed or not enough data.

The readings stay on this computer, never sent anywhere; the last 20 per connection are kept. A restart between readings is noticed, even when the server has since been up longer than it was at the review, and the window after it is counted from the start. A value MySQL sets itself because of another setting (innodb_buffer_pool_instances after a buffer pool change) is listed, but not judged on its own. A window with fewer than 1,000 queries (asked again soon after, or a quiet weekend) gives not enough data: a few queries can show any change.

Permission errors

Why it helps: it turns MySQL’s error into the one grant that should fix it, for the right account, so you do not grant more than the application needs.

Paste the error as you got it, from any client, tool or log:

Our app gets this, can you check?
ERROR 1142 (42000): SELECT command denied to user 'app'@'10.0.0.5' for table 'orders'

1. Read the error

   Verbiqo reads what was refused, and to whom, from MySQL’s own message: a table, column, routine or database privilege, a refused login, an administrative privilege, or a view or routine whose definer no longer exists. Nothing is guessed from the wording around it.

2. Find the table

   The message gives a table without its schema. Verbiqo looks it up in information_schema: if one schema has it, the grant names it; if several do, it says which and leaves you to pick.

3. Name the account

   For a table, column or routine, MySQL names the address the client came from, not the account as created ('app'@'%', say). Verbiqo uses the account as created when another error in the question gives it; otherwise the grant leaves the host for you to fill in, with the statement that shows it.

4. Answer

   A finding per error, with the GRANT, what it allows, and what to check first. A refused login is a password, host or account problem, not a privilege, and is said so. An administrative privilege (SUPER, SYSTEM_VARIABLES_ADMIN) is named, never handed out in a statement.

Verbiqo does not read the account’s grants: they are in the mysql schema, outside what the monitoring account may read. Each finding gives the SHOW GRANTS an administrator runs to see them. Nothing is granted by Verbiqo.

How far to trust an answer

Why it helps: it tells you which parts of an answer Verbiqo read and checked, and which are the model’s own, so you know what to verify before you run anything.

• Every finding has a recommended action, with its risk and how to tell it worked, so the model never has to invent one.
• A replica or a group secondary answers for itself. Its query statistics, locks and index use cover only what runs on it, and Verbiqo says so under the answer. An answer may not call queries or indexes fine for the whole topology from there. For the writes, attach the primary.
• On a group secondary, a stopped replication channel is expected: it runs on the primary only. Verbiqo names the primary to check, and an answer may not tell you to start the channel there.
• A change the model suggests that no finding calls for (KILL, START REPLICA, SET GLOBAL, ALTER TABLE and the like) is named under the answer as the model’s own suggestion. Check it before running it.
• Figures come from what Verbiqo read. A number in the answer that no reading backs (a rate, a size, a ratio) goes back to the model to correct; if it still has nothing behind it, the answer says it could not be validated. A value the answer proposes for a setting is a suggestion, not a reading, and is allowed.
• Pasted output with no server attached (SHOW REPLICA STATUS, an error) gets an answer from the model alone, and Verbiqo says so. Attach the server with /mysql <connection> and Verbiqo reads the same status itself.

Ask How many queries per second is this server doing, and how much of the buffer pool is used?

Every figure in the answer should match a finding or a reading under it. That is the quickest way to see where a number came from before you act on it.

What happened earlier

/splunk prod
/mysql orders-primary
/prom prod

Splunk adds the error and slow logs (Log findings); Prometheus adds the machine’s history and reboots, and mysqld_exporter connection history for forecasts.

From a terminal

In verbiqo chat, attach with /mysql as in the app. To run one report, or one statement of your own:

verbiqo mysql run orders-primary lock-waits
verbiqo mysql query orders-primary "SELECT * FROM performance_schema.replication_connection_status"

Reports for run: sessions, long-transactions, lock-waits, metadata-locks, replication, group-replication, top-statements, full-scans, temp-tables, unused-indexes, errors, connections, settings-of-note. query runs under the same read-only rules as a question; --json works on every verb.