NestJS Enterprise Backend APIs · Leçon

Stratégies d’optimisation des requêtes

Plongez dans les techniques avancées d’optimisation des requêtes, notamment l’analyse des plans d’exécution, la réécriture des requêtes et l’utilisation des vues matérialisées

Stratégies d’optimisation des requêtes est une leçon NestJS Enterprise Backend APIs gratuite sur CoddyKit. Ceci est la leçon 4 sur 6. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage NestJS Enterprise Backend APIs, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours NestJS Enterprise Backend APIs comprend 6 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

Why Optimize Database Queries?

Database queries are the backbone of most applications. When they run slowly, your users experience delays, and your application consumes more resources.

Query optimization is the process of improving the efficiency of database queries to reduce their execution time and resource usage.

PostgreSQL's Query Optimizer

Before executing a query, PostgreSQL's internal query optimizer analyzes it to determine the most efficient way to retrieve the data. It considers:

Available indexes
Table sizes and statistics
Join types and order
Data distribution

The optimizer then generates an execution plan.

Introducing EXPLAIN

The EXPLAIN command allows you to see the execution plan that PostgreSQL's optimizer generates for a query, without actually running the query.

This is invaluable for understanding how your database intends to fetch data and identifying potential bottlenecks.

Understanding EXPLAIN Output

When you run EXPLAIN, you'll see a tree-like structure. Key metrics to look for include:

cost: An estimated measure of the query's total execution expense. The first number is startup cost, the second is total cost. Lower is better.
rows: The estimated number of rows that will be processed or returned by each operation.
width: The estimated average width (in bytes) of the output rows from each operation.

EXPLAIN ANALYZE: Real Performance

While EXPLAIN shows estimates, EXPLAIN ANALYZE actually runs the query and collects real-world statistics. This is crucial for verifying if the optimizer's estimates match reality.

It adds actual time and actual rows to the output.

CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255),
  price DECIMAL(10, 2)
);
INSERT INTO products (name, price) VALUES
('Laptop', 1200.00), ('Mouse', 25.00), ('Keyboard', 75.00), ('Monitor', 300.00), ('Webcam', 50.00);

-- Now, try explaining the query's actual performance:
-- EXPLAIN ANALYZE SELECT * FROM products WHERE price > 100;

Rewriting Suboptimal Queries: OR vs UNION ALL

Sometimes, how you write a query can drastically affect performance. For example, using OR in a WHERE clause can sometimes prevent index usage, leading to full table scans.

For multiple conditions, UNION ALL can sometimes be more efficient, especially if indexes exist on the individual columns, as it can leverage separate index scans.

-- Consider a 'users' table with indexes on 'country' and 'city'

-- Suboptimal (may not use index efficiently across OR)
-- EXPLAIN ANALYZE SELECT * FROM users WHERE country = 'USA' OR city = 'New York';

-- Potentially better (can use separate indexes for each part)
-- EXPLAIN ANALYZE
-- SELECT * FROM users WHERE country = 'USA'
-- UNION ALL
-- SELECT * FROM users WHERE city = 'New York' AND country <> 'USA'; -- Avoid duplicates if needed

Optimizing Joins for Speed

The order of tables in a join and the presence of indexes on the join columns are critical. PostgreSQL tries to pick the best join order, but sometimes hints or rewriting can help.

Ensure indexes are present on columns used in ON clauses.
Filter early: Apply WHERE clauses to individual tables before joining whenever possible.
Consider the impact of LEFT JOIN vs. INNER JOIN on the result set size.

-- Assume 'users' and 'orders' tables, with an index on orders.user_id

-- EXPLAIN ANALYZE
-- SELECT u.name, o.order_date
-- FROM users u
-- JOIN orders o ON u.id = o.user_id
-- WHERE u.country = 'Germany' AND o.total_amount > 100;

-- Filtering 'users' first can reduce the number of rows joined.

Introducing Materialized Views

Materialized Views are pre-computed sets of data that are stored on disk. Unlike regular views, which are just stored queries, materialized views store the actual results of a query.

They are ideal for complex, aggregate queries or reports that don't need real-time data and are queried frequently. Reading from a materialized view is much faster than re-running the original complex query.

Creating a Materialized View

To create a materialized view, you use the CREATE MATERIALIZED VIEW statement, followed by the query whose results you want to store.

Remember, the data in a materialized view is a snapshot at the time of creation.

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INT,
  order_date DATE,
  total_amount DECIMAL(10, 2)
);
INSERT INTO orders (user_id, order_date, total_amount) VALUES
(1, '2023-01-15', 150.00), (2, '2023-01-20', 200.50),
(1, '2023-02-10', 300.00), (3, '2023-02-25', 50.00);

CREATE MATERIALIZED VIEW monthly_sales_summary AS
SELECT
    DATE_TRUNC('month', order_date) AS sales_month,
    SUM(total_amount) AS total_sales,
    COUNT(id) AS total_orders
FROM orders
GROUP BY 1
ORDER BY 1;

Refreshing Materialized Views

Since materialized views store a snapshot, their data doesn't automatically update when the underlying tables change. You must manually refresh them using the REFRESH MATERIALIZED VIEW command.

REFRESH MATERIALIZED VIEW view_name;: Locks the view during refresh.
REFRESH MATERIALIZED VIEW CONCURRENTLY view_name;: Allows concurrent reads during refresh (requires unique index on view).

REFRESH MATERIALIZED VIEW monthly_sales_summary;

-- For large views, consider concurrent refresh (if a unique index exists on the MV)
-- CREATE UNIQUE INDEX ON monthly_sales_summary (sales_month);
-- REFRESH MATERIALIZED VIEW CONCURRENTLY monthly_sales_summary;

Query Performance Check

Let's check your understanding of PostgreSQL query optimization tools.

Recap: Optimize for Speed

In this lesson, we explored how to optimize your database queries for better performance and scalability.

You learned to use EXPLAIN and EXPLAIN ANALYZE to understand and profile query execution plans.
We discussed strategies for rewriting suboptimal queries, like using UNION ALL over OR.
You discovered Materialized Views as a powerful tool for pre-computing and storing complex query results, and how to refresh them.

Keep practicing with these tools to make your applications faster and more efficient!

Questions Fréquemment Posées

La leçon « Stratégies d’optimisation des requêtes » est-elle gratuite ?

Oui — le texte complet de « Stratégies d’optimisation des requêtes » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours NestJS Enterprise Backend APIs, passe à CoddyKit PRO. Le cours NestJS Enterprise Backend APIs comprend 6 leçons au total.

Qu'est-ce que j'apprendrai dans « Stratégies d’optimisation des requêtes » ?

Plongez dans les techniques avancées d’optimisation des requêtes, notamment l’analyse des plans d’exécution, la réécriture des requêtes et l’utilisation des vues matérialisées Tu pratiques NestJS Enterprise Backend APIs avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer NestJS Enterprise Backend APIs ?

Aucune expérience préalable n'est requise. NestJS Enterprise Backend APIs sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 6.

Combien de temps prend la leçon « Stratégies d’optimisation des requêtes » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon NestJS Enterprise Backend APIs ?

Oui. Chaque leçon NestJS Enterprise Backend APIs inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Stratégies de mise en cache (Redis)
Surveiller les performances de la base de données
Équilibrage de charge et mandataires
Stratégies d’optimisation des requêtes
Déploiement sans serveur
Mettre votre projet Supabase à l’échelle

← Retour à NestJS Enterprise Backend APIs