NestJS Enterprise Backend APIs · บทเรียน

แนวทางการปรับปรุงประสิทธิภาพคำค้น

เจาะลึกเทคนิคขั้นสูงในการปรับปรุงคำค้น ซึ่งรวมถึงการวิเคราะห์แผนการทำงาน การเขียนคำค้นใหม่ และการใช้มุมมองที่จัดเก็บผลลัพธ์ไว้

บทเรียน 4 จาก 612 ขั้นตอน

แนวทางการปรับปรุงประสิทธิภาพคำค้น เป็นบทเรียน NestJS Enterprise Backend APIs ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 6 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน NestJS Enterprise Backend APIs และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส NestJS Enterprise Backend APIs มีบทเรียนทั้งหมด 6 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

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!

เริ่มต้นได้ฟรี

เรียนรู้ TypeScript ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส: 20
บทเรียน: 76

เริ่มเรียนฟรี ดูหลักสูตรเต็ม

คำถามที่พบบ่อย

บทเรียน “แนวทางการปรับปรุงประสิทธิภาพคำค้น” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “แนวทางการปรับปรุงประสิทธิภาพคำค้น” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส NestJS Enterprise Backend APIs ให้อัปเกรดเป็น CoddyKit PRO คอร์ส NestJS Enterprise Backend APIs มีบทเรียนทั้งหมด 6 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “แนวทางการปรับปรุงประสิทธิภาพคำค้น”

เจาะลึกเทคนิคขั้นสูงในการปรับปรุงคำค้น ซึ่งรวมถึงการวิเคราะห์แผนการทำงาน การเขียนคำค้นใหม่ และการใช้มุมมองที่จัดเก็บผลลัพธ์ไว้ คุณปฏิบัติ NestJS Enterprise Backend APIs ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน NestJS Enterprise Backend APIs หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน NestJS Enterprise Backend APIs บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 6 บทเรียน

บทเรียน “แนวทางการปรับปรุงประสิทธิภาพคำค้น” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน NestJS Enterprise Backend APIs นี้ได้ไหม

ได้ บทเรียน NestJS Enterprise Backend APIs ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ NestJS Enterprise Backend APIs