Remembering Uncle Ben's wise advice to his nephew, Peter Parker. I figure if it's good enough for your friendly neighborhood Spider-Man, it's good enough for me.

The Realization

As companies get lean and mean, many are handing over read-only SQL access to a growing class of “power users.”

Done right, this move increases insight velocity and reduces dependency on engineering teams. Done wrong? It takes down prod.

Here’s what Uncle Ben would want these new data slingers to know:

Even Read-Only Queries Can Wreck the Party

A bad join, poor filter, or unbounded result set can put stress on memory, disk, or network bandwidth. In a shared environment, that means real pain for everyone.

Example:

-- Inefficient join on unindexed columns
SELECT *
FROM customers c
JOIN orders o ON c.name = o.customer_name;

Locks Happen — Even When You’re Just Reading

Your query might:

• Get blocked by a writer
• Block another reader (with shared locks)
• Block itself if you issue multiple long-running queries simultaneously

Know How to Kill Your Query (Before It Kills the Server)

If your query stalls, cancel it immediately:

SQL Server:

KILL <session_id>;

PostgreSQL:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE usename = current_user AND state = 'active';

MySQL:

SHOW PROCESSLIST;
KILL <id>;

Oracle:

ALTER SYSTEM KILL SESSION '<sid>,<serial#>';

Learn to Spot and Troubleshoot Blocking

SQL Server:

SELECT blocking_session_id, wait_type, wait_time, text
FROM sys.dm_exec_requests
JOIN sys.dm_exec_sql_text(sql_handle);

PostgreSQL:

SELECT pid, blocked_by, queryFROM pg_stat_activity;

MySQL:

SHOW ENGINE INNODB STATUS;

Oracle:

SELECT * FROM v$session WHERE blocking_session IS NOT NULL;

Execution Plans Are Your Best Friend

Use them to:

• See if your query is scanning vs. seeking
• Understand join order
• Spot where indexes are missing

How to enable them:

• SQL Server: SET SHOWPLAN_ALL ON
• PostgreSQL: EXPLAIN ANALYZE
• MySQL: EXPLAIN
• Oracle: EXPLAIN PLAN FOR … then SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

Always LIMIT Your Curiosity

Exploration without bounds is called a denial-of-service attack.

Here’s how to peek safely:

Don’t Use a Database like it is Excel

Repeatedly slicing with slightly different WHERE clauses and copying into Excel? You can do better. Learn:

• GROUP BY
• CASE
• CROSS APPLY, UNPIVOT, or PIVOT if supported

Bonus Tips

• Schedule long queries during off-peak hours.
• Favor replicas when available.
• *Avoid SELECT *** — it’s lazy and expensive.
• Use query comments to help others debug later:
Copy

SELECT /* monthly_sales_report */ ...

• Document recurring logic in version control, not sticky notes.

Final Word

The ability to query production data is a superpower. It can illuminate. Or incinerate. So pause before you hit Run, and remember: With great SQL power comes great responsibility.