Been refactoring some messy SQL queries at work lately. Found a pattern that made everything cleaner. The general usage of sql: ------- SELECT department_id, AVG(salary) FROM ( SELECT * FROM employees WHERE hire_date > '2020-01-01' ) recent_hires GROUP BY department_id HAVING AVG(salary) > ( SELECT AVG(salary) FROM employees ); ------- It works. But reading it is hard sometimes. We can use CTEs instead: -------- WITH recent_hires AS ( SELECT * FROM employees WHERE hire_date > '2020-01-01' ), company_avg AS ( SELECT AVG(salary) AS avg_salary FROM employees ) SELECT department_id, AVG(salary) FROM recent_hires GROUP BY department_id HAVING AVG(salary) > (SELECT avg_salary FROM company_avg); -------- Same result. But now each piece has a name. We can read top to bottom. Why use CTEs: · Break big queries into small named chunks · Can reuse the same CTE multiple times · Makes code reviews easier (people actually understand what you wrote) · Recursive ones are great for org charts or nested categories ----- When to skip CTEs: · Really simple queries (don't over-engineer) · Huge intermediate results (temp table performs better) · Need indexes on the intermediate data ----- Bottom line: If your SQL has nested subqueries more than one level deep, try a CTE. Makes life easier. #SQL #CTE #Database #DataEngineering #PostgreSQL #MySQL
Simplify SQL Queries with CTEs
More Relevant Posts
-
SQL Index : The Complete Developer's Guide---- In this guide, we walk through every major index type, explain how each one works internally, show you exactly how to create and manage them, and — most importantly — teach you how to use EXPLAIN to verify that the database is actually using your indexes. By the end, you will have a complete, practical toolkit for SQL indexing. #SQL #DataEngineering
To view or add a comment, sign in
-
Most SQL developers write queries top to bottom. SQL doesn't run them that way. This one gap causes more bugs, more confusion, and more slow queries than almost anything else. Here's the actual order SQL executes: • FROM — load the table first • JOIN — combine the tables • WHERE — filter the rows • GROUP BY — group what's left • HAVING — filter the groups • SELECT — NOW it picks your columns • ORDER BY — sort the final result SELECT runs sixth. Not first. This is why you can't use a column alias from your SELECT in your WHERE clause — WHERE runs before SELECT even decides what the columns are called. This is why filtering in WHERE is always faster than filtering in HAVING — WHERE cuts rows before grouping, HAVING cuts after. This is why SELECT * on a large table is expensive even if you only need 2 columns — FROM scans everything before SELECT can trim it. Three rules that will save you hours: → Filter as early as possible — always in WHERE, never in HAVING unless you need it → Never reference SELECT aliases in WHERE or GROUP BY → Subqueries in FROM run first — use them to pre-filter large tables before joining Every SQL bug I've ever fixed started with forgetting this. Save this. Share it with every SQL writer on your team. Did you know this already — or did this just explain a bug you've had? 👇 #SQL #DataEngineering #Azure #Databricks #DataEngineer
To view or add a comment, sign in
-
-
Day 86 – SQL JOIN (INNER, LEFT, RIGHT) Today I learned how to combine data from multiple tables using JOIN in SQL. JOIN is one of the most powerful concepts in databases because it helps us fetch related data from different tables. 🔹 What is JOIN? JOIN is used to combine rows from two or more tables based on a related column. 🔹 1️⃣ INNER JOIN INNER JOIN returns only the rows that have matching values in both tables. Example: SELECT E10.name, E10.id, E11.age FROM E10 INNER JOIN E11 ON E10.id = E11.id; ✔️ Returns only common matching records ✔️ Non-matching data will be ignored 🔹 2️⃣ LEFT JOIN LEFT JOIN returns: ✔️ All records from the left table ✔️ Matching records from the right table If no match → shows NULL Example: SELECT E12.name, E12.id, E13.age FROM E12 LEFT JOIN E13 ON E12.id = E13.id ORDER BY E12.id; ✔️ All data from left table (E12) ✔️ Non-matching rows show NULL values 🔹 3️⃣ RIGHT JOIN RIGHT JOIN is the opposite of LEFT JOIN. ✔️ All records from the right table ✔️ Matching records from the left table ✔️ Non-matching left values → NULL Example: SELECT E14.name, E14.id, E15.age FROM E14 RIGHT JOIN E15 ON E14.id = E15.id ORDER BY E15.id; 🔹 Quick Difference JOIN TypeResultINNER JOINOnly matching dataLEFT JOINAll left + matching rightRIGHT JOINAll right + matching left 🎯 Key Takeaways Today I learned: ✔️ How to combine tables using JOIN ✔️ Difference between INNER, LEFT, RIGHT JOIN ✔️ How NULL appears when no match is found ✔️ Importance of common column (id) in joins These concepts are very important when working with real-world relational databases. #SQL #MySQL #Database #BackendDevelopment #DataAnalysis #WebDevelopment
To view or add a comment, sign in
-
📌Why SQL Indexing Matters An SQL index is typically implemented using data structures like B-Trees (default in many databases) that allow the database to locate rows efficiently without scanning the full table. Suppose you frequently run: SELECT * FROM users WHERE email = 'abc@example.com'; Without an index → the database performs a full table scan (O(n)) Create an index: CREATE INDEX idx_users_email ON users(email); With the index, the database can traverse the B-Tree and find matching rows much faster (O(log n)) ✅ Faster filtering on WHERE clauses ✅ Better performance for joins ✅ Can optimize ORDER BY/ GROUP BY ✅ Critical for scaling read-heavy applications There are some tradeoffs as well like extra storage usage and slower writes because indexes must also be updated when we insert , update or delete. Use indexing for high-read and low-write columns, foreign keys or column joins and for frequently filtered or sorted fields. Do not index every column blindly. The best index is not “more indexes” it’s the right indexes for your query patterns. #SQL #DatabaseOptimization #BackendDevelopment #SystemDesign #PostgreSQL #MySQL #SoftwareEngineering
To view or add a comment, sign in
-
-
New blog post: In which I go over three points that are vital in preventing SQL injection when working with dynamic T-SQL. https://lnkd.in/dyfxnYu4 #sqlserver #sqldba #microsoftsqlserver #mssqlserver #mssql #mssqldba #sql
To view or add a comment, sign in
-
SQL Server 2025 upgrade for string splitting! STRING_SPLIT had limitations (single delimiter, messy workarounds). Now 👉 REGEXP_SPLIT_TO_TABLE makes it simple: ✅ Multiple delimiters ✅ Regex support ✅ Cleaner T-SQL 💡 A big step toward modern, developer-friendly SQL. 🔗 https://lnkd.in/g6_UiGpb #SQLServer #SQLServer2025 #TSQL #DataEngineering #SQLTips
To view or add a comment, sign in
-
🚀 Your SQL queries are SLOW — and you might not even know why. I've seen developers write perfect SQL logic… but still kill database performance. 💀 The problem isn't the query. It's the habits behind the query. Here are 6 SQL Query Optimization Techniques every data professional must know 👇 ⚡ Quick Summary: 1️⃣ Use Indexes Effectively → 90% Faster No index on WHERE column = full table scan every time. One line of index creation can change everything. 2️⃣ Avoid SELECT * → 50% Faster You don't need all 40 columns. Ask only what you need. Less I/O = faster results. 3️⃣ Use EXISTS instead of IN → 70% Faster IN evaluates every row. EXISTS stops the moment it finds a match. Smart difference. 🧠 4️⃣ Optimize JOINs with Indexed Columns → 80% Faster Joining on unindexed columns = disaster for large tables. Index your JOIN keys. Always. 5️⃣ Filter Early — WHERE before GROUP BY → 60% Faster Why group 1 million rows when a WHERE clause can reduce it to 10,000 first? 6️⃣ Avoid Functions on Indexed Columns → 85% Faster YEAR(log_date) = 2024 breaks the index. log_date >= '2024-01-01' uses it perfectly. ✅ 💡 The Real Truth: Writing SQL that works is easy. Writing SQL that performs is a skill. And in production environments with millions of rows — the difference between optimized and unoptimized SQL is the difference between 2 seconds and 2 minutes. That's the difference between a junior and a senior data professional. 🔥 🎯 Action Step for today: Open any query you wrote this week. Check — are you using SELECT *? Are you filtering before grouping? Fix one thing. Ship better code. 💪 📌 Save this post — you'll need it every time you write a complex query! ♻️ Repost to help your network write faster, cleaner SQL! 👇 Comment "OPTIMIZE" if you want the full SQL Performance Series! #SQL #SQLOptimization #QueryOptimization #DataEngineering #DatabasePerformance #DataAnalytics #SQLServer #MySQL #PostgreSQL #DataScience #TechSkills #CareerGrowth #DataAnalyst #SoftwareEngineering #BackendDevelopment #LinkedInLearning #ShankarMaheshwari #SQLTips #DataCommunity #LearnSQL
To view or add a comment, sign in
-
-
This is spot on — SQL performance is where real expertise shows. Small changes like indexing or avoiding SELECT * can make massive differences at scale. Definitely a must-know for anyone working seriously with data.
👉 Helping Professionals Learn Data Analytics | Excel • Power BI • SQL | 13+ Years in Finance & ERP | SAP | Automation Expert
🚀 Your SQL queries are SLOW — and you might not even know why. I've seen developers write perfect SQL logic… but still kill database performance. 💀 The problem isn't the query. It's the habits behind the query. Here are 6 SQL Query Optimization Techniques every data professional must know 👇 ⚡ Quick Summary: 1️⃣ Use Indexes Effectively → 90% Faster No index on WHERE column = full table scan every time. One line of index creation can change everything. 2️⃣ Avoid SELECT * → 50% Faster You don't need all 40 columns. Ask only what you need. Less I/O = faster results. 3️⃣ Use EXISTS instead of IN → 70% Faster IN evaluates every row. EXISTS stops the moment it finds a match. Smart difference. 🧠 4️⃣ Optimize JOINs with Indexed Columns → 80% Faster Joining on unindexed columns = disaster for large tables. Index your JOIN keys. Always. 5️⃣ Filter Early — WHERE before GROUP BY → 60% Faster Why group 1 million rows when a WHERE clause can reduce it to 10,000 first? 6️⃣ Avoid Functions on Indexed Columns → 85% Faster YEAR(log_date) = 2024 breaks the index. log_date >= '2024-01-01' uses it perfectly. ✅ 💡 The Real Truth: Writing SQL that works is easy. Writing SQL that performs is a skill. And in production environments with millions of rows — the difference between optimized and unoptimized SQL is the difference between 2 seconds and 2 minutes. That's the difference between a junior and a senior data professional. 🔥 🎯 Action Step for today: Open any query you wrote this week. Check — are you using SELECT *? Are you filtering before grouping? Fix one thing. Ship better code. 💪 📌 Save this post — you'll need it every time you write a complex query! ♻️ Repost to help your network write faster, cleaner SQL! 👇 Comment "OPTIMIZE" if you want the full SQL Performance Series! #SQL #SQLOptimization #QueryOptimization #DataEngineering #DatabasePerformance #DataAnalytics #SQLServer #MySQL #PostgreSQL #DataScience #TechSkills #CareerGrowth #DataAnalyst #SoftwareEngineering #BackendDevelopment #LinkedInLearning #ShankarMaheshwari #SQLTips #DataCommunity #LearnSQL
To view or add a comment, sign in
-
-
🔍 LEN vs LENGTH in SQL — Small Difference, Big Impact! When working with SQL, even seemingly small functions can make a significant difference in your results. One such commonly confused pair is LEN() and LENGTH(). Let’s break it down 👇 📌 LEN() Primarily used in SQL Server Returns the number of characters in a string ⚠️ Excludes trailing spaces 👉 Example: LEN('Data ') → 4 📌 LENGTH() Common in MySQL, PostgreSQL, Oracle Returns the number of characters in a string ✅ Includes trailing spaces 👉 Example: LENGTH('Data ') → 5 💡 Key Takeaway Choosing the wrong function can lead to unexpected results, especially when dealing with data validation, cleaning, or reporting. 🎯 Pro Tip: Always be aware of the SQL dialect you're working with—functions may behave differently across systems! 💬 Have you ever faced issues due to trailing spaces in SQL? Share your experience below! #SQL #DataAnalytics #DatabaseManagement #SQLServer #MySQL #LearningSQL #TechTips #DataEngineering #Coding #LinkedInLearning
To view or add a comment, sign in
-
Mastering SQL pattern matching is key for precise data filtering. The standard `LIKE` operator provides basic string matching with wildcards like `%` and `_`, though it's important to remember its case-insensitive nature in MySQL unless `BINARY` is used. For more sophisticated data interrogation, advanced regular expressions come into play via functions and operators like `REGEXP_LIKE()`, `REGEXP`, and `RLIKE`, offering granular control with special characters such as `^`, `$`, and `.`. These tools are indispensable for developers needing to extract specific data based on complex textual patterns. Explore the full spectrum of SQL pattern matching techniques: https://lnkd.in/gqga6AtF #SQL #Database #PatternMatching #DataEngineering #DeveloperTools
To view or add a comment, sign in
Explore related topics
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development