SQL is tricky — not because of syntax, but because of execution order 👀 Even though we write queries starting with SELECT, the database processes them differently: 👉 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT Understanding this flow helps you: ✔ Write better queries ✔ Debug errors faster ✔ Optimize performance This is a small concept, but it makes a big difference. #SQL #DataAnalytics #Database #Learning #Tech #Programming #DataScience #Query #Optimization #Analytics
One amazing way to vusualize this in action is with the Execution Plan manager , the one in SQL Management Studio is great. And about SQL is great how Modern Data roles are still discovering a 47 years old tech , Invented By IB M and standardized in 1986
Having spent over 30 years with SQL, I think its simplicity is the challenge, not its complexity. I recommend considering performance and scalability when creating your queries to avoid the performance problems I see further down the line.
The database compiler/optimizer optimize performance. If we have a table t (a, b, c, d) and execute this statement SELECT c, d FROM t ORDER BY c, d the compiler will choose to read all rows, order this rows after (c,d) and then return the rows. If we create an index ix1(c, d) the compiler will just read the rows from the index - and not in parallel. If we have the following statement and still the index Ix1 SELECT c, COUNT (*) FROM t WHERE d = 7 GROUP BY c HAVING c > 120 the compiler will choose an index seek with the condition d = 7 AND c > 120. So the condition in HAVING is already used when reading the data. If we still have the index Ix1 and execute the following statement SELECT TOP 10 c, d FROM t ORDER BY c, d the 10 first rows are read from the index. If the index is not created, all rows from the table are read, only column c and d are sorted and the first 10 rows returned. Etc.