SQL Performance Improvements: Finding the Right Queries to Fix

Posted4 months agoActive4 months ago

freekmurze

40 points

6 comments

ohdear.appTechstory

calmpositive

Debate

20/100

SQL Performance OptimizationMysqlDatabase Management

Key topics

SQL Performance Optimization

Mysql

Database Management

The article discusses strategies for identifying and improving slow SQL queries, with commenters sharing their experiences and challenges with query optimization, particularly with MySQL 8.0 InnoDB.

Snapshot generated from the HN discussion

Discussion Activity

Light discussion

First comment

Peak period

12-14h

Avg / period

1.2

Key moments

01Story posted
Sep 16, 2025 at 4:43 PM EDT
4 months ago
Step 01
02First comment
Sep 16, 2025 at 7:56 PM EDT
3h after posting
Step 02
03Peak activity
2 comments in 12-14h
Hottest window of the conversation
Step 03
04Latest activity
Sep 17, 2025 at 1:44 PM EDT
4 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (6 comments)

Showing 6 comments

tt_dev

4 months ago

1 reply

What Ive been really looking for is a way to run SQL queries against MySQL 8.0 Inno DB without them hitting the cache.

Its tricky to validate improvements real time but I guess validating in prod is good too

Mojah

4 months ago

Have you been able to try this with a `SELECT SQL_NO_CACHE * FROM ...` query?

If it's for local testing, you could try to cripple InnoDB as much as possible by just setting some absurdly low values, that would almost certainly mean no InnoDB caching is happening; https://gist.github.com/mattiasgeniar/87cd4a10bfcc788d81b51f...

toshinoriyagi

4 months ago

1 reply

Are SELECT queries most companies' bottleneck? While we find the occasional SELECT without an index or joining something it doesn't need to, my biggest struggle is optimizing UPDATES.

In our busiest times we need to update up to 100,000 rows, ~50 columns, every ~5 seconds. So ideally the update finishes before the next one starts to avoid deadlocks.

MySQL probably isn't the most ideal DB for our use-case, but it's what the startup had been using for years before I joined.

Mojah

4 months ago

2 replies

Totally depends on the use case I suppose, we found that in our environment, we perform _a lot_ more SELECT's than we do UPDATE/DELETE/INSERT's.

And with some badly optimized SELECT's, the time MySQL had to spend on sorting results/reading from disk in an inefficient way made all our _write_ queries suffer.

By optimizing our SELECTs first, we freed up some CPU bandwidth (it seems?) that can be spent doing all the other work.

toshinoriyagi

4 months ago

That's good to hear. We have found some suspect SELECTs used in our client-facing API recently. Might be good to double-check that those are running efficiently and not hamstringing the writes.

sebazzz

4 months ago

If you misuse a database you will have a lot more complex SELECTs than UPDATEs perhaps ;-)

View full discussion on Hacker News

ID: 45267762Type: storyLast synced: 11/20/2025, 5:23:56 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN