Lý thuyết cơ sở dữ liệu của Jeffrey Ullman đằng sau truy vấn nhanh và có thể mở rộng

Tại sao Ullman quan trọng đối với dữ liệu hiện đại

Hầu hết những người viết SQL, xây dashboard, hoặc tinh chỉnh một truy vấn chậm đều hưởng lợi từ công trình của Jeffrey Ullman—dù họ chưa từng nghe tên ông. Ullman là một nhà khoa học máy tính và giảng viên, những nghiên cứu và giáo trình của ông giúp định nghĩa cách cơ sở dữ liệu mô tả dữ liệu, suy luận về truy vấn, và thực thi chúng một cách hiệu quả.

Ảnh hưởng thầm lặng đằng sau các công cụ hàng ngày

Khi một engine cơ sở dữ liệu biến SQL của bạn thành thứ nó có thể chạy nhanh, nó dựa vào những ý tưởng vừa chính xác vừa linh hoạt. Ullman giúp chính thức hóa ý nghĩa của truy vấn (để hệ thống có thể viết lại an toàn), và ông kết nối suy nghĩ về cơ sở dữ liệu với suy nghĩ về compiler (để truy vấn có thể được phân tích cú pháp, tối ưu và dịch thành các bước thực thi).

Ảnh hưởng đó thầm lặng vì nó không hiện ra thành một nút bấm trong công cụ BI của bạn hay một tính năng hiển thị trong console cloud. Nó thể hiện qua:

• Truy vấn chạy nhanh hơn sau khi bạn thêm index hoặc viết lại một JOIN
• Bộ tối ưu chọn các kế hoạch khác nhau khi dữ liệu tăng lên
• Hệ thống có thể scale mà không thay đổi kết quả truy vấn của bạn

Bạn sẽ học gì trong bài này (không quá nhiều toán)

Bài viết này dùng các ý tưởng cốt lõi của Ullman làm chuyến tham quan có hướng về nội bộ cơ sở dữ liệu quan trọng nhất trong thực tế: cách đại số quan hệ nằm dưới SQL, cách viết lại truy vấn bảo toàn ý nghĩa, tại sao bộ tối ưu dựa trên chi phí đưa ra lựa chọn như vậy, và cách các thuật toán join thường quyết định một công việc kết thúc trong vài giây hay vài giờ.

Chúng ta cũng sẽ lồng một vài khái niệm giống compiler—phân tích cú pháp, viết lại, và lập kế hoạch—bởi vì engine cơ sở dữ liệu hành xử giống những compiler tinh vi hơn nhiều người tưởng.

Lời hứa nhanh: chúng ta sẽ giữ thảo luận chính xác, nhưng tránh các chứng minh nặng toán. Mục tiêu là cung cấp mô hình tư duy bạn có thể áp dụng ở nơi làm việc lần tới khi vấn đề hiệu năng, scale, hoặc hành vi truy vấn khó hiểu xuất hiện.

Những nền tảng cơ sở dữ liệu Ullman đã giúp củng cố

Nếu bạn từng viết một truy vấn SQL và mong nó “chỉ có một nghĩa duy nhất,” bạn đang dựa vào những ý tưởng mà Jeffrey Ullman đã giúp phổ biến và chính thức hóa: một mô hình rõ ràng cho dữ liệu, cộng với các cách chính xác để mô tả thứ một truy vấn yêu cầu.

Mô hình quan hệ nói đơn giản

Ở lõi, mô hình quan hệ xử lý dữ liệu như bảng (relation). Mỗi bảng có hàng (tuple) và cột (attribute). Nghe có vẻ hiển nhiên bây giờ, nhưng phần quan trọng là kỷ luật nó tạo ra:

• Khóa xác định các hàng. Một primary key là “thẻ tên” cho mỗi bản ghi.
• Quan hệ nối các bảng qua foreign key, nên bạn có thể giữ các sự kiện ở một nơi và tham chiếu chúng ở nơi khác.

Cách nhìn này giúp suy nghĩ về tính đúng đắn và hiệu năng mà không phải nói chung chung. Khi bạn biết một bảng đại diện cho gì và hàng được xác định thế nào, bạn có thể dự đoán join sẽ làm gì, bản sao có ý nghĩa ra sao, và tại sao một vài bộ lọc thay đổi kết quả.

Đại số quan hệ: máy tính cho truy vấn

Trong các bài giảng của mình, Ullman thường dùng đại số quan hệ như một kiểu máy tính truy vấn: một tập nhỏ các toán tử (select, project, join, union, difference) mà bạn có thể kết hợp để diễn đạt điều mình muốn.

Tại sao điều này quan trọng khi làm việc với SQL: các cơ sở dữ liệu dịch SQL thành dạng đại số rồi viết lại nó thành một dạng tương đương khác. Hai truy vấn trông khác nhau có thể đại số là giống nhau—đó là cách các bộ tối ưu có thể thay đổi thứ tự join, đẩy filter xuống, hoặc loại bỏ công việc thừa trong khi vẫn giữ nguyên ý nghĩa.

Đại số so với giải tích (cao cấp)

• Đại số quan hệ là kiểu “làm như thế nào”: một chuỗi phép toán để tính kết quả.
• Giải tích quan hệ là kiểu “muốn gì”: mô tả kết quả bạn cần.

SQL phần lớn là “muốn gì,” nhưng engine thường tối ưu bằng cách dùng đại số “làm như thế nào.”

Nền tảng đánh bại việc thuộc một dialiect

Các dialect SQL khác nhau (Postgres vs. Snowflake vs. MySQL), nhưng nền tảng thì không đổi. Hiểu khóa, quan hệ, và tương đương đại số giúp bạn nhận ra khi truy vấn về mặt logic sai, khi nó chỉ chậm, và thay đổi nào giữ nguyên ý nghĩa qua nền tảng.

Đại số quan hệ: ngôn ngữ ẩn dưới SQL

Đại số quan hệ là “toán học phía dưới” SQL: một tập nhỏ các toán tử mô tả kết quả bạn muốn. Công trình của Jeffrey Ullman giúp làm rõ cách nhìn này—và nó vẫn là mô hình tư duy mà hầu hết bộ tối ưu sử dụng.

Các toán tử cốt lõi (và ý nghĩa của chúng)

Một truy vấn cơ sở dữ liệu có thể biểu diễn như một pipeline từ vài khối xây dựng:

• Select (σ): lọc hàng (ý tưởng WHERE trong SQL)
• Project (π): giữ các cột cụ thể (ý tưởng SELECT col1, col2)
• Join (⋈): kết hợp bảng theo điều kiện (JOIN ... ON ...)
• Union (∪): xếp chồng kết quả cùng cấu trúc (UNION)
• Difference (−): các hàng ở A nhưng không có ở B (như EXCEPT trong nhiều dialect)

Vì tập này nhỏ, việc suy luận về tính đúng đắn trở nên dễ hơn: nếu hai biểu thức đại số tương đương, chúng trả cùng một bảng cho mọi trạng thái cơ sở dữ liệu hợp lệ.

SQL ánh xạ vào đại số như thế nào (khái quát)

Lấy một truy vấn quen thuộc:

SELECT c.name
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.total > 100;

Về mặt khái niệm, đây là:

1. bắt đầu với một join giữa customers và orders: customers ⋈ orders

2. select chỉ các orders trên 100: σ(o.total > 100)(...)

3. project cột bạn muốn: π(c.name)(...)

Đó không phải ký hiệu nội bộ chính xác của mọi engine, nhưng là ý tưởng đúng: SQL trở thành một cây toán tử.

Tương đương: cánh cửa tới tối ưu hóa

Nhiều cây khác nhau có thể cho cùng kết quả. Ví dụ, các filter thường có thể được đẩy sớm hơn (áp dụng σ trước một join lớn), và các projection có thể loại bỏ cột không dùng sớm hơn (áp dụng π sớm hơn).

Những quy tắc tương đương đó cho phép cơ sở dữ liệu viết lại truy vấn thành một kế hoạch rẻ hơn mà không đổi ý nghĩa. Khi bạn nhìn truy vấn như đại số, “tối ưu hóa” không còn là phép màu mà trở thành biến dạng có quy tắc và an toàn.

Từ SQL tới kế hoạch truy vấn: những rewrite bảo toàn ý nghĩa

Khi bạn viết SQL, cơ sở dữ liệu không chạy nó “như viết.” Nó dịch câu lệnh của bạn thành một kế hoạch truy vấn: biểu diễn có cấu trúc về công việc cần làm.

Mô hình tư duy tốt là cây các toán tử. Lá đọc bảng hoặc index; các node trong cây biến đổi và kết hợp hàng. Các toán tử phổ biến gồm scan, filter (selection), project, join, group/aggregate, và sort.

Kế hoạch logic vs. kế hoạch vật lý (cái gì vs. cách nào)

Các cơ sở dữ liệu thường tách lập kế hoạch thành hai lớp:

• Kế hoạch logic: cái gì cần tính, biểu diễn bằng các toán tử trừu tượng (filter, join, aggregate) và quan hệ giữa chúng.
• Kế hoạch vật lý: cách thực hiện trên lưu trữ và phần cứng thực tế (index scan vs full scan, hash join vs nested-loop join, song song vs đơn luồng).

Ảnh hưởng của Ullman xuất hiện ở việc nhấn mạnh những biến đổi bảo toàn ý nghĩa: tái sắp xếp kế hoạch logic theo nhiều cách mà không đổi câu trả lời, rồi chọn chiến lược vật lý hiệu quả.

Các rewrite theo quy tắc giảm công việc

Trước khi chọn cách thực thi cuối cùng, bộ tối ưu áp dụng các quy tắc “dọn dẹp” đại số. Những rewrite này không đổi kết quả; chúng giảm công việc không cần thiết.

Ví dụ phổ biến:

• Đẩy selection xuống: áp dụng filter càng sớm càng tốt để ít hàng chảy vào các bước sau.
• Cắt projection: giữ đúng các cột cần thiết, giảm I/O và bộ nhớ.
• Sắp xếp lại join: nối các kết quả nhỏ/ít trước (khi an toàn), thay vì theo thứ tự xuất hiện trong SQL.

Một ví dụ rewrite đơn giản

Giả sử bạn muốn các orders của người dùng ở một quốc gia:

SELECT o.order_id, o.total
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE u.country = 'CA';

Một cách diễn giải ngây thơ có thể join tất cả users với tất cả orders rồi mới lọc Canada. Một rewrite bảo toàn ý nghĩa sẽ đẩy filter xuống để join chạm ít hàng hơn:

• Lọc users với country = 'CA'
• Rồi join những users đó với orders
• Rồi project chỉ order_id và total

Về mặt kế hoạch, bộ tối ưu cố gắng biến:

Join(Users, Orders) → Filter(country='CA') → Project(order_id,total)

thành gần giống:

Filter(country='CA') on Users → Join(with Orders) → Project(order_id,total)

Kết quả giống nhau. Công việc ít hơn.

Những rewrite này dễ bị bỏ qua vì bạn không gõ chúng—nhưng chúng là lý do lớn khiến cùng một SQL có thể chạy nhanh ở cơ sở dữ liệu này nhưng chậm ở cơ sở dữ liệu khác.

Tối ưu hóa dựa trên chi phí mà không dùng biệt ngữ

Khi bạn chạy một truy vấn SQL, cơ sở dữ liệu xem xét nhiều cách hợp lệ để lấy cùng một kết quả, rồi chọn cách mà nó ước tính là rẻ nhất. Quá trình quyết định này gọi là tối ưu hóa dựa trên chi phí—và đây là nơi lý thuyết kiểu Ullman xuất hiện rất thực tế trong hiệu năng hàng ngày.

"Mô hình chi phí" thực ra là gì

Mô hình chi phí là hệ thống chấm điểm mà bộ tối ưu dùng để so sánh các kế hoạch thay thế. Hầu hết engine ước tính chi phí dựa trên vài nguồn lực chính:

• Số hàng xử lý (công việc tỷ lệ với lượng dữ liệu chảy qua mỗi bước)
• I/O (đọc page từ đĩa hoặc SSD, cùng hiệu ứng cache)
• CPU (lọc, hashing, sắp xếp, tổng hợp)
• Bộ nhớ (phép toán có vừa trong RAM hay phải spill ra đĩa)

Mô hình không cần hoàn hảo; nó cần đúng theo hướng đủ thường xuyên để chọn kế hoạch tốt.

Cardinality estimation, nói dễ hiểu

Trước khi chấm điểm kế hoạch, bộ tối ưu hỏi ở mỗi bước: bước này sẽ cho ra bao nhiêu hàng? Đó là cardinality estimation.

Nếu bạn lọc WHERE country = 'CA', engine ước tính tỉ lệ hàng khớp. Nếu bạn join customers với orders, nó ước tính bao nhiêu cặp sẽ khớp trên khoá join. Những dự đoán số hàng này quyết định engine thích index scan hay full scan, hash join hay nested loop, hay sort sẽ nhỏ hay rất lớn.

Tại sao thống kê quan trọng (và điều gì xảy ra khi thiếu)

Những ước tính của bộ tối ưu dựa trên thống kê: đếm, phân bố giá trị, tỉ lệ null, và đôi khi tương quan giữa các cột.

Khi stats lỗi thời hoặc thiếu, engine có thể đoán sai số hàng rất nhiều lần. Một kế hoạch trông rẻ trên giấy có thể trở nên đắt đỏ trong thực tế—triệu chứng kinh điển bao gồm chậm đột ngột sau khi dữ liệu tăng, thay đổi kế hoạch “ngẫu nhiên”, hoặc join bất ngờ phải spill ra đĩa.

Một đánh đổi không tránh khỏi: độ chính xác vs thời gian lập kế hoạch

Ước lượng tốt hơn thường đòi hỏi nhiều công sức hơn: thống kê chi tiết hơn, lấy mẫu, hoặc khám phá nhiều kế hoạch ứng viên. Nhưng việc lập kế hoạch cũng tốn thời gian, nhất là với truy vấn phức tạp.

Vì vậy bộ tối ưu cân bằng hai mục tiêu:

• Lập kế hoạch đủ nhanh cho workloads tương tác
• Lập kế hoạch đủ thông minh để tránh lựa chọn thảm họa

Hiểu đánh đổi này giúp bạn đọc EXPLAIN: bộ tối ưu không cố gắng “tỏ ra thông minh”—nó cố gắng đúng theo cách dự đoán được với thông tin hạn chế.

Thuật toán join và trọng tâm hiệu năng truy vấn

Công trình của Ullman giúp phổ biến một ý tưởng đơn giản nhưng mạnh: SQL không thật sự "chạy" mà được dịch thành một kế hoạch thực thi. Không đâu rõ điều đó hơn là ở join. Hai truy vấn trả cùng hàng có thể khác nhau rất nhiều về thời gian chạy tùy vào thuật toán join engine chọn—và thứ tự join.

Nested loop, hash join, merge join—khi nào dùng từng loại

Nested loop join đơn giản: với mỗi hàng bên trái, tìm hàng tương ứng bên phải. Nó nhanh khi bên trái nhỏ và bên phải có index hữu ích.

Hash join xây một bảng băm từ một input (thường là input nhỏ hơn) và dò bằng input kia. Nó mạnh cho các input lớn, không có thứ tự, với điều kiện đẳng thức (ví dụ A.id = B.id), nhưng cần bộ nhớ; spill-to-disk có thể xóa mất lợi thế.

Merge join duyệt hai input theo thứ tự đã sắp xếp. Nó phù hợp khi cả hai phía đã được sắp thứ tự (hoặc dễ sắp), như khi index trả hàng theo thứ tự khóa join.

Tại sao thứ tự join có thể chi phối hiệu năng

Với ba bảng trở lên, số thứ tự join có thể nở ra rất nhiều. Nối hai bảng lớn trước có thể tạo ra một kết quả trung gian khổng lồ làm chậm mọi thứ. Thứ tự tốt thường bắt đầu với filter có tính chọn lọc cao (ít hàng nhất) và nối ra ngoài, giữ intermediates nhỏ.

Index thay đổi các kế hoạch khả dĩ

Index không chỉ tăng tốc lookup—chúng làm cho một số chiến lược join khả thi. Một index trên khóa join có thể biến nested loop tốn kém thành pattern “seek cho mỗi hàng” nhanh. Ngược lại, thiếu hoặc index không dùng được có thể đẩy engine về hash joins hoặc sort lớn cho merge joins.

Danh sách kiểm tra thực tế: triệu chứng của kế hoạch join tệ

• Thời gian chạy tăng mạnh khi thêm chút dữ liệu (thứ tự join làm intermediates phồng lên).
• Kế hoạch hiển thị chênh lệch lớn “rows estimated vs. rows actual” (ước lượng cardinality sai dẫn tới chọn join sai).
• Bạn thấy sort lớn hoặc hash spill ra đĩa (áp lực bộ nhớ hoặc thiếu index hỗ trợ).
• Bảng nhỏ đã được lọc sớm lại được join muộn (filter chưa được áp dụng kịp).
• Predicate join không phải là đẳng thức trên các kiểu tương thích (ngăn cản hash/merge hiệu quả).

Ý tưởng compiler bên trong engine cơ sở dữ liệu

Cơ sở dữ liệu không chỉ “chạy SQL.” Chúng biên dịch nó. Ảnh hưởng của Ullman trải dài cả lý thuyết cơ sở dữ liệu và suy nghĩ về compiler, và kết nối đó giải thích tại sao engine truy vấn giống chuỗi công cụ ngôn ngữ lập trình: chúng dịch, viết lại, và tối ưu trước khi thực hiện bất kỳ công việc nào.

Phân tích cú pháp và cây cú pháp: SQL được đọc ra sao

Khi bạn gửi một truy vấn, bước đầu giống front end của compiler. Engine tách token từ từ khóa và định danh, kiểm tra ngữ pháp, và xây một parse tree (thường được đơn giản thành abstract syntax tree). Đây là nơi lỗi cơ bản bị bắt: thiếu dấu phẩy, tên cột mơ hồ, quy tắc grouping không hợp lệ.

Một mô hình tư duy hữu ích: SQL là một ngôn ngữ lập trình mà “chương trình” mô tả quan hệ dữ liệu thay vì vòng lặp.

Từ parse tree tới các toán tử logic

Compiler chuyển cú pháp thành một IR; cơ sở dữ liệu làm tương tự: dịch cú pháp SQL thành toán tử logic như:

• Selection (lọc hàng)
• Projection (chọn cột)
• Join (kết hợp bảng)
• Aggregation (GROUP BY)

Dạng logic này gần với đại số quan hệ hơn là văn bản SQL, nên dễ suy nghĩ về ý nghĩa và tương đương.

Tại sao bộ tối ưu giống các tối ưu compiler

Các tối ưu compiler giữ kết quả chương trình giống mà làm cho thực thi rẻ hơn. Bộ tối ưu cơ sở dữ liệu làm điều tương tự, dùng các hệ quy tắc như:

• Đẩy filter sớm (giảm công việc sớm)
• Sắp xếp lại join (kết quả như cũ, chi phí khác)
• Loại bỏ tính toán thừa

Đây là phiên bản cơ sở dữ liệu của “loại bỏ mã chết”: không phải kỹ thuật giống hệt, nhưng cùng triết lý—bảo toàn ngữ nghĩa, giảm chi phí.

Debugging: đọc kế hoạch như mã đã biên dịch

Nếu truy vấn của bạn chậm, đừng chỉ nhìn SQL. Hãy xem kế hoạch truy vấn như bạn sẽ kiểm tra mã máy biên dịch. Kế hoạch cho bạn biết engine đã chọn gì: thứ tự join, dùng index, và nơi thời gian được tiêu tốn.

Bài học thực tế: học đọc EXPLAIN như một bản liệt kê assembly cho hiệu năng. Nó biến tinh chỉnh từ phỏng đoán thành debug dựa trên bằng chứng. For more on turning that into a habit, see /blog/practical-query-optimization-habits.

Lý thuyết thiết kế schema ảnh hưởng đến hiệu năng thật

Hiệu năng truy vấn tốt thường bắt đầu trước khi bạn viết SQL. Lý thuyết thiết kế schema của Ullman (đặc biệt là chuẩn hóa) giúp cấu trúc dữ liệu để cơ sở dữ liệu giữ tính đúng đắn, dự đoán được, và hiệu quả khi nó lớn lên.

Mục tiêu của chuẩn hóa (tại sao nó tồn tại)

Chuẩn hóa nhằm:

• Giảm bất thường (ví dụ, cập nhật địa chỉ khách hàng ở năm chỗ và bỏ sót một chỗ)
• Cải thiện nhất quán bằng cách cho mỗi sự thật một “nhà” duy nhất
• Khiến ràng buộc có thể biểu diễn được (khóa, foreign key) để engine có thể thực thi quy tắc thay vì phụ thuộc vào code ứng dụng

Những lợi ích về đúng đắn đó dịch thành lợi ích hiệu năng sau này: ít trường trùng lặp, index nhỏ hơn, và ít cập nhật tốn kém.

Các dạng chuẩn hóa nói đơn giản

Bạn không cần ghi nhớ các chứng minh để dùng ý tưởng:

• 1NF: lưu giá trị trong cột nguyên tử (không danh sách phân tách bởi dấu phẩy). Điều này giúp lọc và index đơn giản.
• 2NF: với bảng có khóa ghép, mọi cột không phải khóa nên phụ thuộc vào toàn bộ khóa (không chỉ phần nào). Tránh lặp thuộc tính trên nhiều hàng.
• 3NF: các cột không phải khóa nên chỉ phụ thuộc vào khóa, không phụ thuộc vào cột không khóa khác. Ngăn trùng lặp ẩn.
• BCNF: phiên bản nghiêm ngặt hơn của 3NF, mọi determinant là candidate key—hữu ích khi các cột gần như độc nhất tạo ra trùng lặp tinh vi.

Khi denormalize là hợp lý

Denormalize có thể là lựa chọn thông minh khi:

• Bạn xây bảng chủ yếu cho analytics (bảng fact rộng, báo cáo)
• Join trở thành nút thắt và bạn chấp nhận trùng lặp có kiểm soát
• Bạn tối ưu cho tốc độ đọc với các quy tắc refresh rõ ràng (ví dụ: rebuild hàng đêm)

Chìa khóa là denormalize có chủ đích, với quy trình để giữ trùng lặp đồng bộ.

Quyết định schema tác động thế nào tới bộ tối ưu và scale

Thiết kế schema hình thành những gì bộ tối ưu có thể làm. Khóa và foreign key rõ ràng cho phép chiến lược join tốt hơn, rewrite an toàn hơn, và ước lượng số hàng chính xác hơn. Trong khi đó, trùng lặp quá mức có thể phình index và làm chậm ghi, và cột nhiều giá trị chặn các predicate hiệu quả. Khi dữ lượng tăng, quyết định mô hình hóa ban đầu thường quan trọng hơn việc tối ưu từng truy vấn nhỏ lẻ.

Lý thuyết hiện ra khi hệ thống scale

Khi một hệ thống “scale,” hiếm khi chỉ là thêm máy to hơn. Thường khó là cùng một ý nghĩa truy vấn phải được giữ nguyên trong khi engine chọn một chiến lược vật lý rất khác để giữ thời gian chạy dự đoán được. Sự nhấn mạnh của Ullman về các tương đương chính thức chính là điều cho phép những thay đổi chiến lược đó mà không đổi kết quả.

Scale thường là bố cục vật lý + lựa chọn kế hoạch

Ở kích thước nhỏ, nhiều kế hoạch “ổn.” Ở quy mô lớn, khác biệt giữa quét một bảng, dùng index, hoặc dùng kết quả đã tính trước có thể là khác biệt giữa vài giây và vài giờ. Phần lý thuyết quan trọng vì bộ tối ưu cần một tập quy tắc rewrite an toàn (ví dụ: đẩy filter sớm, sắp xếp lại join) mà không thay đổi đáp án—dù chúng thay đổi lớn công việc thực hiện.

Partitioning thay đổi truy vấn bạn chạy, dù SQL trông không đổi

Partitioning (theo ngày, khách hàng, vùng, v.v.) biến một bảng logic thành nhiều mảnh vật lý. Điều đó ảnh hưởng đến lập kế hoạch:

• Mảnh nào có thể bỏ qua (partition pruning)
• Join có diễn ra trong từng partition hay cần shuffle dữ liệu giữa node
• Có thể group cục bộ trước khi ghép kết quả hay không

Văn bản SQL có thể không đổi, nhưng kế hoạch tốt nhất phụ thuộc vào nơi hàng nằm.

Materialized views: tiền tính toán như những đường tắt đại số

Materialized views về cơ bản là “biểu thức con đã lưu.” Nếu engine có thể chứng minh truy vấn của bạn khớp (hoặc viết lại để khớp) với một kết quả đã lưu, nó có thể thay thế công việc tốn kém—như join và aggregation lặp—bằng một lookup nhanh. Đây là tư duy đại số quan hệ trong thực tế: nhận diện tương đương rồi tái sử dụng.

Caching: hữu ích nhưng không sửa được cấu trúc công việc sai

Caching có thể tăng tốc đọc lặp, nhưng nó không cứu được truy vấn phải quét quá nhiều dữ liệu, shuffle intermediates khổng lồ, hoặc tính một join quá lớn. Khi vấn đề scale xuất hiện, lời giải thường là: giảm lượng dữ liệu cần chạm tới (bố cục/partitioning), giảm tính toán lặp (materialized views), hoặc thay đổi kế hoạch—chứ không chỉ “thêm cache.”

Thói quen tối ưu thực tế lấy cảm hứng từ Ullman

Ảnh hưởng của Ullman thể hiện qua một tâm thế đơn giản: coi một truy vấn chậm như một phát biểu ý định mà cơ sở dữ liệu có thể viết lại, rồi xác minh xem nó thực sự đã quyết định gì. Bạn không cần trở thành nhà lý thuyết để hưởng lợi—bạn chỉ cần một quy trình lặp lại.

1) Đọc EXPLAIN: nhìn đâu trước tiên

Bắt đầu với những phần thường chiếm đa số thời gian chạy:

• Phương thức truy cập: engine có quét cả bảng khi bạn kỳ vọng lookup bằng index không?
• Ước lượng hàng vs thực tế (nếu DB hiển thị cả): khoảng cách lớn thường giải thích chậm bất ngờ.
• Thứ tự join: bảng nào dẫn join, và nó có bắt đầu từ filter chọn lọc nhất không?
• Toán tử tốn kém: sort, build hash, nested loop lớn—những thứ này thường cho biết nơi thật sự tốn thời gian.

Nếu bạn chỉ làm một việc, xác định toán tử đầu tiên nơi số hàng bùng nổ. Đó thường là nguyên nhân gốc.

2) Những anti-pattern phổ biến làm bộ tối ưu thất bại

Những lỗi này dễ viết nhưng rất tốn kém:

• Hàm trên cột có index: WHERE LOWER(email) = ... có thể ngăn index dùng (dùng cột chuẩn hóa hoặc functional index nếu DB hỗ trợ).
• Thiếu predicate: quên filter theo ngày hoặc tenant biến truy vấn mục tiêu thành quét rộng.
• Cross join vô ý: thiếu điều kiện join nhân số hàng và tạo intermediates khổng lồ.

3) Hình thành giả thuyết theo tư duy đại số

Đại số quan hệ khuyến khích hai bước thực tế:

• Đẩy filter sớm: áp dụng WHERE trước join khi có thể để thu nhỏ input.
• Giảm cột sớm: chỉ chọn cột cần thiết (đặc biệt trước join) để cắt bộ nhớ và I/O.

Một giả thuyết tốt có thể là: “Join này đắt vì chúng tôi đang join quá nhiều hàng; nếu filter orders xuống 30 ngày gần nhất trước, input join giảm.”

4) Thêm index, viết lại truy vấn, hay thay schema?

Dùng quy tắc quyết định đơn giản:

• Thêm index khi truy vấn đúng, có tính chọn lọc, và chạy lặp lại.
• Viết lại truy vấn khi EXPLAIN cho thấy công việc có thể tránh được (join thừa, lọc muộn, predicate không sargable).
• Đổi schema khi workload ổn định và bạn liên tục chiến đấu cùng nút thắt (ví dụ: aggregates tiền tính, trường lookup denormalized, hoặc partition theo thời gian/tenant).

Mục tiêu không phải “SQL khôn ngoan.” Mà là kết quả trung gian dự đoán được nhỏ hơn—chính xác là dạng cải thiện bảo toàn tương đương mà ý tưởng Ullman giúp bạn nhận ra.

Áp dụng những ý tưởng này khi bạn xây sản phẩm thật

Những khái niệm này không chỉ dành cho DBA. Nếu bạn giao hàng một ứng dụng, bạn đang thực hiện quyết định về cơ sở dữ liệu và lập kế hoạch truy vấn dù không nhận ra: hình dạng schema, lựa chọn khóa, pattern truy vấn, và lớp truy cập dữ liệu đều ảnh hưởng tới những gì bộ tối ưu có thể làm.

Nếu bạn dùng workflow tạo nhanh (ví dụ sinh một app React + Go + PostgreSQL từ giao diện chat trong Koder.ai), các mô hình tư duy kiểu Ullman là mạng an toàn thực tế: bạn có thể xem lại schema được sinh để đảm bảo khóa và quan hệ rõ, kiểm tra các truy vấn app dựa vào, và kiểm chứng hiệu năng với EXPLAIN trước khi vấn đề xuất hiện ở production. Càng nhanh bạn lặp qua “ý định truy vấn → kế hoạch → sửa”, bạn càng thu được nhiều giá trị từ phát triển tăng tốc.

Học thêm ở đâu và áp dụng ở công việc

Bạn không cần "học lý thuyết" như một thú vui riêng. Cách nhanh nhất để hưởng lợi từ nền tảng kiểu Ullman là học vừa đủ để đọc kế hoạch truy vấn tự tin—rồi luyện tập trên chính cơ sở dữ liệu của bạn.

Tài nguyên thân thiện cho người mới

Tìm các sách và bài giảng này (không có liên kết—chỉ là điểm bắt đầu được trích dẫn rộng rãi):

• “A First Course in Database Systems” (Ullman & Widom) — nền tảng cơ sở dữ liệu dễ tiếp cận với cách trình bày thực tế.
• “Principles of Database and Knowledge-Base Systems” (Ullman) — lý thuyết sâu hơn nếu bạn muốn.
• “Compilers: Principles, Techniques, and Tools” (Aho, Lam, Sethi, Ullman) — để hiểu vì sao bộ tối ưu giống compiler.
• Các chủ đề/giáo trình: đại số quan hệ, viết lại truy vấn, thứ tự join, tối ưu theo chi phí, index và selectivity, phân tích cú pháp và ngôn ngữ truy vấn.

Lộ trình học nhẹ nhàng

Bắt đầu nhỏ và liên kết mỗi bước với thứ bạn quan sát được:

1. Đại số quan hệ: học selection, projection, join, và quy tắc tương đương.
2. Kế hoạch: học đọc node kế hoạch (loại scan, filter, join, sort, aggregate).
3. Join: hiểu nested loop vs hash join vs merge join và khi nào mỗi loại thường thắng.
4. Mô hình chi phí: học vài đầu vào quyết định (số hàng, selectivity, I/O vs CPU).

Bài tập nhỏ sinh lợi nhanh

Chọn 2–3 truy vấn thực và lặp:

• Viết lại: đổi IN sang EXISTS, đẩy predicate trước, loại cột không cần, so sánh kết quả.
• So sánh kế hoạch: lưu kế hoạch “trước/sau” và ghi chú thay đổi (thứ tự join, loại join, kiểu scan).
• Thay đổi index: thử thêm/bỏ một index từng cái và quan sát ước tính vs thực tế.

Truyền đạt phát hiện với đồng đội

Dùng ngôn ngữ rõ ràng, dựa trên kế hoạch:

• “Kế hoạch chuyển từ sequential scan sang index scan vì filter trở nên chọn lọc.”
• “Ước tính số hàng sai 100×, nên optimizer chọn thứ tự join sai.”
• “Viết lại này tương đương (cùng kết quả), nhưng cho phép predicate pushdown và ít hàng vào join.”

Đó là lợi ích thực tế của nền tảng Ullman: bạn có một từ vựng chung để giải thích hiệu năng—không cần phỏng đoán.