Hacker News new | past | comments | ask | show | jobs | submit login
SQL Performance Explained, the tuning book for developers, is free today (sql-performance-explained.com)
70 points by MarkusWinand 3 days ago | hide | past | web | favorite | 13 comments





I found Use the Index, Luke interesting, but I don't know much SQL. I wonder how this book compares.

https://use-the-index-luke.com/


Same author of both.

I believe it’s the same content in book form.

If it is the same content, then the advantage is that you don't have to give an email address in order to get it for 'free'.

I can read it off-line whilst I'm travelling on the subway/ underground / tube

I haven't read the book but it has 5 stars with 19 reviews on Amazon. https://www.amazon.com/Performance-Explained-Everything-Deve...

I sort of have a beef with the usage of "SQL performance". I know what people mean, but it still irks me.

SQL is a declarative query language. It describes the meaning of your query.

The execution of the query has performance implications based on the actual RDBMS and the semantics of the query, but you can't improve the performance of your query without altering its meaning, only the performance of its execution.

It's like when people describe the performance of Python when they mean the performance of the CPython runtime.


Pro-DBA here. Not sure why you're being downvoted. I know what you're getting at. Different vendor SQL engines and query optimisers behave differently. There's isn't really a silver bullet for all database engines past the simple and obvious stuff like making sure columns you query most have indexes. Once you've exhausted these tuning options you really need to know your specific database engine's internals.

Disagree. For example, indexes are an optimization mechanism which tune the SQL engine for your data set and queries. Creating and planning indexes are outside the scope of your SELECT query, but can give a dramatic performance difference, with the exact same SQL query.

See also triggers.


> but you can't improve the performance of your query without altering its meaning

Could you explain what you mean by "meaning"? From my naive perspective, if different queries give the same results, in all cases, I would consider the "meaning" the same (silly shenanigans aside).


Thanks

Thanks!

> SQL Performance

No such thing.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: