Cymation SQL Monitor & Console

ID	User	Database / Host	Time (s)	Rows & Quality	State	SQL Query Command	Action
Loading queries...

Timestamp (IST)	Query ID	User	Database / Host	Duration (s)	Rows & Quality	State	SQL Query Command	Action
Select a date and click search to load query logs.

Frequently Asked Questions (FAQ)

1. How are "High Priority" vs "Optimized" queries determined?

The system evaluates the efficiency of each query based on flags from MySQL's performance telemetry and the ratio of rows scanned to rows sent:

🔴 High Priority: A full table scan was performed (no index used) on a large dataset (scanned over 50,000 rows, and examined more than 1,000 times the rows it actually returned). These need an index immediately.
Medium Priority: A full table scan occurred but on a smaller table (fewer than 50,000 rows examined).
Needs Review: MySQL couldn't use a good index, or scanned over 200 times the rows it actually returned.
🟢 Optimized: The query utilized indexes and returned data efficiently (low read-to-sent ratio).

2. Why are there background queries always running in the list?

These are MySQL background daemon threads. They are running background operations and do not consume CPU under normal circumstances:

event_scheduler: An internal MySQL daemon that manages and executes scheduled events.
null user (State: Suspending): Background cleanup threads (like InnoDB log flushing, replication syncs, or buffer handlers) waiting for instructions.
SELECT ... FROM information_schema: The SQL Monitor's own polling queries. To report the processlist to you, the monitor must execute a query on the server every few seconds.

3. Is there any risk or overhead of running this monitor tool?

No, the risk is minimal:

Read-Only Checks: The tool only queries database metadata schemas (information_schema and performance_schema), never modifying database tables.
Safe EXPLAIN Logic: Clicking the "Explain" button triggers EXPLAIN <query>. MySQL resolves this using the optimizer and never runs the query, avoiding resource locks or re-execution of slow queries.
Kill PIN Security: Terminating a query requires authorization using a secure 6-digit PIN to prevent accidental terminations of critical database threads.

4. How is the "Rows & Quality" ratio calculated?

It calculates the ratio as Rows Examined / Rows Sent:

Rows Examined: The total number of records MySQL read from storage/memory.
Rows Sent: The number of matching rows actually returned to the client application.
Example: A query examining 1,500,000 rows to send just 10 rows has a ratio of 150,000:1 (flagged as inefficient). An efficient index lookup will examine 10 rows and send 10 rows (ratio of 1:1, labeled Optimized).

5. How does the "Explain" button work, and how do I read the plan?

Clicking Explain calls MySQL's internal query optimizer by prepending EXPLAIN to the selected query:

Safe to Run: It retrieves the query planner metadata without actually executing the statement, making it completely safe to use even for heavy queries on production.
Key indicators to analyze:
- Type: Look for ref, eq_ref, or range (good/indexed). Avoid ALL (full table scan) or index (full index scan).
- Key: The index name MySQL decided to use. If it is NULL, MySQL is not using any index.
- Rows: Estimated number of rows MySQL expects to scan. Lower is always better.
- Extra: Watch out for Using filesort or Using temporary. These indicate slow, resource-heavy sort/group tasks in temporary storage.

Developer Query Optimization Guide

1. Avoid Full Table Scans (Create Indexes)

Always ensure columns in WHERE, JOIN, ORDER BY, or GROUP BY clauses are indexed.

SQL - Creating an Index

-- Add index to speed up product lookups
CREATE INDEX idx_products_category ON products(category_id);

2. Use Composite Indexes Wisely

When querying multiple fields, create a composite index matching the column order in your WHERE clause (Leftmost Prefix Rule).

SQL - Composite Index Example

-- Ideal for: WHERE status = 'active' AND created_at > NOW()
CREATE INDEX idx_orders_status_date ON orders(status, created_at);

3. Avoid Wildcards at the Start of LIKE Filters

Prefix wildcards (%value) prevent MySQL from using indexes. Use suffix wildcards (value%) instead.

❌ Slow (Scans full table)

SELECT * FROM users 
WHERE email LIKE '%gmail.com';

✅ Fast (Uses Index)

SELECT * FROM users 
WHERE email LIKE 'john.doe%';

4. Avoid Functions on Index Columns

Wrapping indexed columns in functions (e.g. DATE(), LOWER()) disables index lookups.

❌ Index Disabled

SELECT * FROM sales 
WHERE DATE(created_at) = '2026-07-15';

✅ Index Enabled

SELECT * FROM sales 
WHERE created_at >= '2026-07-15 00:00:00' 
  AND created_at <= '2026-07-15 23:59:59';

5. Limit Query Results

Never fetch more data than needed. Always append a LIMIT clause, especially in analytical or paginated interfaces.

SQL - Limiting results

SELECT id, name FROM large_table 
ORDER BY id DESC LIMIT 50;

Cymation SQL Monitor

Database CPU Usage

Instance Control

Stuck & Active Database Queries

Stuck Query History Log

Frequently Asked Questions (FAQ)

Developer Query Optimization Guide

1. Avoid Full Table Scans (Create Indexes)

2. Use Composite Indexes Wisely

3. Avoid Wildcards at the Start of LIKE Filters

4. Avoid Functions on Index Columns

5. Limit Query Results

Cymation SQL Monitor

Database CPU Usage

Instance Control

Stuck & Active Database Queries

Stuck Query History Log

Frequently Asked Questions (FAQ)

Developer Query Optimization Guide

1. Avoid Full Table Scans (Create Indexes)

2. Use Composite Indexes Wisely

3. Avoid Wildcards at the Start of LIKE Filters

4. Avoid Functions on Index Columns

5. Limit Query Results

Confirm Action

Query Execution Plan (EXPLAIN)