Lập chỉ mục cho bảng quản trị: Tối ưu các bộ lọc hàng đầu trước

Tại sao các bộ lọc trong bảng quản trị lại chậm

Bảng quản trị thường bắt đầu nhanh. Bạn mở danh sách, cuộn, nhấp một bản ghi, rồi tiếp tục. Sự chậm xuất hiện khi mọi người lọc theo cách họ thực sự làm việc: "Chỉ các ticket mở", "Được giao cho Maya", "Tạo trong tuần trước", "Order ID chứa 1047". Mỗi cú nhấp gây chờ, và danh sách bắt đầu cảm thấy ì ạch.

Cùng một bảng có thể nhanh với một bộ lọc và chậm đau đớn với bộ lọc khác. Bộ lọc trạng thái có thể chạm một lát nhỏ hàng và trả về nhanh. Bộ lọc "tạo giữa hai ngày" có thể buộc cơ sở dữ liệu đọc một phạm vi rất lớn. Bộ lọc người được giao có thể ổn khi đứng riêng, rồi chậm đi khi bạn kết hợp với trạng thái và sắp xếp.

Chỉ mục là đường tắt mà cơ sở dữ liệu dùng để tìm hàng phù hợp mà không đọc toàn bộ bảng. Nhưng chỉ mục không miễn phí. Chúng chiếm không gian và làm cho insert/update hơi chậm hơn. Thêm quá nhiều chỉ mục có thể làm ghi chậm và vẫn không sửa được nút cổ chai thực sự.

Thay vì lập chỉ mục mọi thứ, hãy ưu tiên các bộ lọc mà:

• được dùng liên tục
• chạm tới nhiều hàng
• tạo ra thời gian chờ đáng chú ý
• có thể cải thiện an toàn bằng các chỉ mục nhỏ, phù hợp

Phạm vi ở đây giữ cố ý hẹp. Những phàn nàn hiệu năng đầu tiên trên danh sách admin hầu như luôn tới từ bốn loại bộ lọc giống nhau: trạng thái, người được giao, khoảng ngày và trường văn bản. Khi hiểu tại sao những bộ lọc này hành xử khác nhau, bước tiếp theo rõ ràng: xem mẫu truy vấn thực tế, thêm chỉ mục nhỏ nhất phù hợp, và kiểm tra bạn đã cải thiện đường chậm mà không tạo ra vấn đề mới.

Mẫu truy vấn phía sau công việc quản trị thực tế

Bảng quản trị hiếm khi chậm vì một báo cáo khổng lồ. Chúng chậm vì vài màn hình được dùng cả ngày, và những màn hình đó chạy nhiều truy vấn nhỏ lặp đi lặp lại.

Đội vận hành thường sống trong vài hàng đợi làm việc: tickets, orders, users, approvals, yêu cầu nội bộ. Trên các trang này, các bộ lọc lặp lại:

• Trạng thái, vì nó phản ánh luồng công việc (New, Open, Pending, Done)
• Người được giao, vì các đội cần "mục của tôi" và "chưa được giao"
• Khoảng ngày, vì luôn có người hỏi "chuyện gì xảy ra tuần trước?"
• Tìm kiếm, để nhảy đến mục đã biết (số đơn, email) hoặc quét văn bản (ghi chú, preview)

Công việc cơ sở dữ liệu phụ thuộc vào ý định:

• Browse newest là mẫu quét. Nó thường như "hiện các mục mới nhất, có thể thu hẹp theo trạng thái, sắp xếp theo created time" và được phân trang.
• Find a specific item là mẫu tra cứu. Admin đã có ID, email, số ticket hoặc tham chiếu, và mong cơ sở dữ liệu nhảy thẳng tới một tập hàng nhỏ.

Bảng quản trị cũng kết hợp các bộ lọc theo những cách có thể đoán: "Open + Unassigned", "Pending + Assigned to me", hoặc "Completed in the last 30 days". Chỉ mục làm việc tốt nhất khi chúng khớp những hình dạng truy vấn thực tế đó, không phải khi chúng khớp danh sách tên cột.

Nếu bạn xây công cụ admin trong AppMaster, những mẫu này thường hiển thị chỉ bằng cách xem các màn hình danh sách được dùng nhiều nhất và bộ lọc mặc định của chúng. Điều đó giúp bạn dễ lập chỉ mục những gì thực sự điều khiển công việc hàng ngày, không phải những gì trông hay trên giấy.

Cách chọn thứ tự lập chỉ mục

Hãy coi lập chỉ mục như sơ cứu ưu tiên. Đừng bắt đầu bằng việc lập chỉ mục mọi cột xuất hiện trong dropdown bộ lọc. Bắt đầu với vài truy vấn chạy liên tục và làm phiền người dùng nhất.

Tìm những bộ lọc người dùng thực sự dùng

Tối ưu một bộ lọc không ai dùng là lãng phí. Để tìm đường nóng thực sự, kết hợp các tín hiệu:

• Phân tích UI: màn hình nào được xem nhiều nhất, bộ lọc nào được nhấp nhiều
• Log cơ sở dữ liệu hoặc API: truy vấn phổ biến nhất và vài phần trăm chậm nhất
• Phản hồi nội bộ: "tìm kiếm chậm" thường chỉ tới một màn hình cụ thể
• Danh sách đích mặc định: những gì chạy ngay khi admin mở bảng

Trên nhiều đội, chế độ xem mặc định là "Open tickets" hoặc "New orders". Nó chạy mỗi khi ai đó refresh, chuyển tab, hoặc quay lại sau khi trả lời.

Nhóm truy vấn theo hình dạng, không theo tên trường

Trước khi thêm chỉ mục, nhóm các truy vấn thường gặp theo cách chúng hành xử. Hầu hết truy vấn danh sách admin rơi vào vài nhóm:

• Bộ lọc bằng: status = 'open', assignee_id = 42
• Bộ lọc khoảng: created_at giữa hai ngày
• Sắp xếp và phân trang: ORDER BY created_at DESC và lấy trang 2
• Tra cứu văn bản: match chính xác (order number), prefix match (email bắt đầu bằng), hoặc contains search

Ghi hình dạng cho mỗi màn hình hàng đầu, bao gồm WHERE, ORDER BY, và phân trang. Hai truy vấn trông giống nhau ở UI có thể hành xử rất khác ở cơ sở dữ liệu.

Chọn một nhóm nhỏ đầu tiên

Bắt đầu với một mục tiêu ưu tiên: truy vấn danh sách mặc định tải đầu tiên. Rồi chọn 2 hoặc 3 truy vấn tần suất cao nữa. Thường vậy là đủ để cắt các độ trễ lớn nhất mà không biến cơ sở dữ liệu thành bảo tàng chỉ mục.

Ví dụ: đội hỗ trợ mở danh sách Tickets lọc status = 'open', sắp xếp theo mới nhất, với tùy chọn assignee và khoảng ngày. Tối ưu chính xác tổ hợp đó trước. Khi nó nhanh, chuyển sang màn hình kế tiếp dựa trên mức sử dụng.

Lập chỉ mục cho bộ lọc trạng thái mà không lạm dụng

Trạng thái là một trong những bộ lọc đầu tiên người thêm, và cũng dễ lập chỉ mục theo cách không có hiệu quả.

Hầu hết trường trạng thái có độ phân loại thấp: chỉ vài giá trị (open, pending, closed). Chỉ mục giúp nhất khi nó có thể thu hẹp kết quả xuống lát nhỏ. Nếu 80%–95% hàng chia sẻ cùng trạng thái, chỉ mục trên status riêng lẻ thường không thay đổi nhiều. Cơ sở dữ liệu vẫn phải đọc một phần lớn hàng, và chỉ mục thêm chi phí.

Bạn thường cảm nhận được lợi ích khi:

• một trạng thái hiếm (ví dụ, escalated)
• trạng thái kết hợp với điều kiện khác làm tập kết quả nhỏ
• trạng thái + sắp xếp khớp chế độ xem phổ biến

Một mẫu phổ biến là "hiển thị mục mở, mới nhất trước." Trong trường hợp đó, lập chỉ mục cho cả bộ lọc và sắp xếp thường tốt hơn chỉ mục status một mình.

Những kết hợp hay trả giá đầu tiên:

• status + updated_at (lọc theo trạng thái, sắp xếp theo thay đổi gần đây)
• status + assignee_id (các chế độ xem hàng đợi công việc)
• status + updated_at + assignee_id (chỉ khi chế độ xem chính xác đó dùng nhiều)

Partial index là lựa chọn trung gian tốt khi một trạng thái chiếm áp đảo. Nếu "open" là chế độ xem chính, hãy chỉ lập chỉ mục cho các hàng open. Chỉ mục nhỏ hơn và chi phí ghi thấp hơn.

-- PostgreSQL example: index only open rows, optimized for newest-first lists
CREATE INDEX CONCURRENTLY tickets_open_updated_idx
ON tickets (updated_at DESC)
WHERE status = 'open';

Một kiểm tra thực tế: chạy truy vấn admin chậm với và không có bộ lọc trạng thái. Nếu nó chậm cả hai cách, chỉ mục chỉ trạng thái sẽ không cứu được. Tập trung vào sắp xếp và bộ lọc thứ hai thực sự thu nhỏ danh sách.

Lọc theo người được giao: chỉ mục bằng và các kết hợp phổ biến

Trong hầu hết bảng quản trị, người được giao là một user ID lưu trên bản ghi: khóa ngoại như assignee_id. Đó là bộ lọc bằng (=) tiêu chuẩn, và thường là chiến thắng nhanh với một chỉ mục đơn giản.

Assignee cũng xuất hiện cùng các bộ lọc khác vì nó phản ánh cách người làm việc. Một lãnh đạo hỗ trợ có thể lọc "Được giao cho Alex" rồi thu hẹp thành "Open" để xem còn gì cần xử lý. Nếu chế độ xem này chậm, bạn thường cần hơn một chỉ mục một cột.

Điểm bắt đầu tốt là chỉ mục tổng hợp khớp combo bộ lọc phổ biến:

• (assignee_id, status) cho "việc mở của tôi"
• (assignee_id, status, updated_at) nếu danh sách còn sắp xếp theo hoạt động gần đây

Thứ tự quan trọng trong chỉ mục tổng hợp. Đặt bộ lọc bằng trước (thường là assignee_id, rồi status), và đặt cột sắp xếp hoặc khoảng sau cùng (updated_at). Điều đó khớp với cách cơ sở dữ liệu có thể dùng hiệu quả.

Các mục chưa được giao là một cạm bẫy phổ biến. Nhiều hệ thống biểu diễn "chưa được giao" là NULL ở assignee_id, và quản lý lọc nó rất nhiều. Tùy database và hình dạng truy vấn, giá trị NULL có thể thay đổi kế hoạch đến mức một chỉ mục tốt cho mục đã giao trở nên vô dụng với mục chưa được giao.

Nếu chưa được giao là luồng công việc quan trọng, hãy chọn cách tiếp cận rõ ràng và kiểm tra nó:

• Giữ assignee_id có thể null, nhưng đảm bảo WHERE assignee_id IS NULL được kiểm thử và lập chỉ mục khi cần.
• Dùng một giá trị chuyên biệt (ví dụ một user "Unassigned") chỉ khi nó phù hợp mô hình dữ liệu.
• Thêm partial index cho các hàng chưa được giao nếu cơ sở dữ liệu hỗ trợ.

Nếu bạn xây bảng quản trị trong AppMaster, việc ghi lại các bộ lọc và thứ tự sắp xếp chính mà đội dùng rồi phản chiếu chúng bằng một số chỉ mục được chọn tốt sẽ hữu ích hơn là lập chỉ mục mọi trường có thể có.

Khoảng ngày: lập chỉ mục theo cách người dùng lọc

Bộ lọc ngày thường xuất hiện như các cài sẵn nhanh kiểu "7 ngày gần nhất" hoặc "30 ngày" cùng với bộ chọn ngày tùy chỉnh. Chúng trông đơn giản nhưng có thể gây công việc rất khác nhau trên bảng lớn.

Trước hết, rõ ràng cột timestamp nào người dùng thực sự có ý: dùng:

• created_at cho chế độ "mục mới"
• updated_at cho chế độ "thay đổi gần đây"

Đặt chỉ mục btree bình thường trên cột đó. Không có nó, mỗi nhấp "30 ngày" có thể là một full table scan.

Các khoảng cài sẵn thường trông như created_at >= now() - interval '30 days'. Đó là điều kiện khoảng, và chỉ mục trên created_at có thể dùng hiệu quả. Nếu UI cũng sắp xếp theo mới nhất, khớp chiều sắp xếp (ví dụ created_at DESC trên PostgreSQL) có thể giúp trên các danh sách dùng nhiều.

Khi khoảng ngày kết hợp với bộ lọc khác (status, assignee), hãy chọn lọc. Chỉ mục tổng hợp tuyệt vời khi combo đó phổ biến. Nếu không, chúng thêm chi phí ghi mà không mang lại lợi ích.

Một số quy tắc thực tế:

• Nếu hầu hết chế độ xem lọc theo status rồi mới theo ngày, (status, created_at) có thể hữu ích.
• Nếu status là tuỳ chọn nhưng ngày luôn có, giữ chỉ mục created_at đơn giản và tránh nhiều chỉ mục tổng hợp.
• Đừng tạo mọi kết hợp. Mỗi chỉ mục mới tăng lưu trữ và làm chậm ghi.

Múi giờ và biên gây ra nhiều lỗi "thiếu bản ghi". Nếu người dùng chọn ngày (không phải thời gian), hãy quyết định cách hiểu ngày kết thúc. Mẫu an toàn là bắt đầu bao gồm và kết thúc loại trừ: created_at >= start và created_at < end_next_day. Lưu timestamp bằng UTC và chuyển đầu vào người dùng về UTC trước khi truy vấn.

Ví dụ: một admin chọn 10 Jan đến 12 Jan và mong thấy mục từ cả ngày 12 Jan. Nếu truy vấn của bạn dùng <= '2026-01-12 00:00', bạn sẽ bỏ gần như mọi thứ của ngày 12 Jan. Chỉ mục vẫn ổn, nhưng logic biên sai.

Trường văn bản: tra cứu chính xác vs tra cứu chứa

Tìm kiếm văn bản là nơi nhiều bảng quản trị chậm, vì người dùng mong một hộp cho mọi thứ. Khắc phục đầu tiên là tách hai nhu cầu khác nhau: match chính xác (nhanh và dự đoán) vs contains search (linh hoạt nhưng nặng hơn).

Match chính xác gồm order ID, ticket number, email, phone, hoặc tham chiếu ngoài. Những trường này hoàn hảo cho chỉ mục cơ bản. Nếu admin thường paste ID hoặc email, chỉ mục đơn giản cộng truy vấn bằng có thể làm trải nghiệm gần như tức thì.

Contains search là khi ai đó gõ "refund" hoặc "john" và mong khớp trong tên, ghi chú, mô tả. Thường hiện thực bằng LIKE %term%. Dấu đại diện đầu tiên ngăn chỉ mục btree bình thường thu hẹp tìm kiếm, nên cơ sở dữ liệu phải quét nhiều hàng.

Cách thực tế để xây tìm kiếm mà không làm quá tải cơ sở dữ liệu:

• Biến lookup chính xác thành hành lang chính (ID, email, username) và gắn nhãn rõ.
• Với tìm kiếm "bắt đầu bằng" (term%), chỉ mục chuẩn có thể giúp và thường đủ cho tên.
• Thêm tìm kiếm contains chỉ khi log hoặc phản hồi cho thấy cần.
• Khi thêm, dùng công cụ phù hợp (PostgreSQL full-text hoặc trigram) thay vì hy vọng chỉ mục bình thường vá được LIKE %term%.

Quy tắc đầu vào quan trọng hơn nhiều đội nghĩ. Chúng giảm tải và làm kết quả nhất quán:

• Giới hạn độ dài tối thiểu cho contains search (ví dụ 3+ ký tự).
• Chuẩn hoá kiểu chữ hoặc dùng so sánh không phân biệt chữ in hoa/thường nhất quán.
• Cắt khoảng trắng đầu/cuối và hợp nhất khoảng trắng lặp.
• Xử lý email và ID như lookup chính xác mặc định, ngay cả khi nhập vào ô tìm chung.
• Nếu một từ quá rộng, yêu cầu người dùng cụ thể hơn thay vì chạy truy vấn khổng lồ.

Một ví dụ nhỏ: manager tìm "ann" để tìm khách hàng. Nếu hệ thống bạn chạy LIKE %ann% trên ghi chú, tên và địa chỉ, nó có thể quét hàng ngàn bản ghi. Nếu bạn kiểm tra trước các trường chính xác (email hoặc customer ID), rồi chỉ dùng chỉ mục văn bản thông minh khi cần, tìm kiếm vẫn nhanh mà không biến mọi truy vấn thành bài tập nặng cho DB.

Quy trình từng bước để thêm chỉ mục an toàn

Chỉ mục dễ thêm và dễ hối tiếc. Quy trình an toàn giúp bạn tập trung vào các bộ lọc admin dựa vào, và tránh các chỉ mục "có thể hữu ích" làm chậm ghi sau này.

Bắt đầu với sử dụng thực tế. Lấy các truy vấn hàng đầu theo hai cách:

• truy vấn phổ biến nhất
• truy vấn chậm nhất

Với bảng quản trị, thường là các trang danh sách có bộ lọc và sắp xếp.

Tiếp theo, nắm chính xác hình dạng truy vấn như cơ sở dữ liệu nhìn thấy. Ghi lại WHERE và ORDER BY chính xác, bao gồm chiều sắp xếp và các kết hợp phổ biến (ví dụ: status = 'open' AND assignee_id = 42 ORDER BY created_at DESC). Những khác biệt nhỏ có thể thay đổi chỉ mục hữu dụng.

Dùng vòng lặp đơn giản:

• Chọn một truy vấn chậm và một thay đổi chỉ mục để thử.
• Thêm hoặc chỉnh một chỉ mục đơn.
• Đo lại với cùng bộ lọc và cùng thứ tự sắp xếp.
• Kiểm tra inserts và updates có chậm rõ rệt không.
• Giữ thay đổi chỉ khi nó cải thiện rõ ràng truy vấn mục tiêu.

Phân trang cần kiểm tra riêng. Phân trang theo offset (OFFSET 20000) thường chậm hơn khi đi sâu, ngay cả với chỉ mục. Nếu người dùng thường xuyên tới trang sâu, cân nhắc phân trang kiểu cursor ("hiện các mục trước timestamp/id này") để chỉ mục làm công việc ổn định trên bảng lớn.

Cuối cùng, giữ một ghi nhỏ để danh sách chỉ mục dễ hiểu sau vài tháng: tên chỉ mục, bảng, cột (và thứ tự), và truy vấn nó hỗ trợ.

Sai lầm phổ biến khi lập chỉ mục trong bảng quản trị

Cách nhanh nhất làm bảng quản trị cảm thấy chậm là thêm chỉ mục mà không kiểm tra cách người ta thực sự lọc, sắp xếp và phân trang. Chỉ mục tiêu tốn không gian và thêm công việc cho mỗi insert và update.

Những sai lầm hay gặp

Các mẫu này gây hầu hết vấn đề:

• Lập chỉ mục mọi cột "phòng trường hợp".
• Tạo chỉ mục tổng hợp với thứ tự cột sai.
• Bỏ qua sắp xếp và phân trang.
• Mong một chỉ mục bình thường sửa được LIKE '%term%'.
• Để lại chỉ mục cũ sau khi UI thay đổi.

Một tình huống phổ biến: đội hỗ trợ lọc ticket bằng Status = Open, sắp xếp theo updated time, và phân trang qua kết quả. Nếu bạn chỉ thêm chỉ mục trên status, cơ sở dữ liệu có thể vẫn phải gom tất cả ticket mở và sắp xếp chúng. Một chỉ mục khớp filter và sort cùng nhau có thể trả trang 1 nhanh.

Cách nhanh để phát hiện các vấn đề này

Trước và sau khi thay đổi UI admin, làm một rà soát ngắn:

• Liệt kê các bộ lọc hàng đầu và thứ tự mặc định, rồi xác nhận có chỉ mục khớp pattern WHERE + ORDER BY.
• Kiểm tra wildcard dẫn (LIKE '%term%') và quyết định thật sự cần contains search không.
• Tìm chỉ mục trùng lặp hoặc chồng chéo.
• Theo dõi chỉ mục không dùng trong một thời gian rồi xóa khi chắc chắn không cần.

Nếu bạn xây bảng admin trong AppMaster dùng PostgreSQL, hãy làm rà soát này thành một phần của việc ra mắt màn hình mới. Những chỉ mục đúng thường theo trực tiếp từ các bộ lọc và thứ tự sắp xếp UI thực sự dùng.

Kiểm tra nhanh và bước tiếp theo

Trước khi thêm nhiều chỉ mục hơn, xác nhận những chỉ mục bạn đã có đang giúp cho các bộ lọc chính mọi người dùng mỗi ngày. Một bảng quản trị tốt phải tức thì trên các đường dẫn phổ biến, không phải trên những tìm kiếm hiếm.

Một vài kiểm tra bắt được hầu hết vấn đề:

• Mở các kết hợp bộ lọc phổ biến (status, assignee, khoảng ngày, cộng thứ tự mặc định) và xác nhận chúng vẫn nhanh khi bảng lớn lên.
• Với mỗi chế độ xem chậm, xác nhận truy vấn dùng chỉ mục khớp cả WHERE và ORDER BY, không chỉ một phần.
• Giữ danh sách chỉ mục đủ nhỏ để bạn giải thích mục đích từng chỉ mục trong một câu.
• Quan sát các hành động nhiều ghi (create, update, change status). Nếu chúng chậm sau khi thêm chỉ mục, có thể bạn có quá nhiều hoặc chỉ mục chồng chéo.
• Quyết định "tìm kiếm" nghĩa là gì trong UI của bạn: match chính xác, prefix hay contains. Kế hoạch chỉ mục của bạn phải khớp lựa chọn đó.

Bước thực tế tiếp theo là viết ra các đường dẫn vàng của bạn bằng câu đơn giản, ví dụ: "Support agents lọc ticket mở, giao cho tôi, 7 ngày gần nhất, sắp xếp theo mới nhất." Dùng những câu đó để thiết kế một tập nhỏ chỉ mục rõ ràng hỗ trợ chúng.

Nếu bạn vẫn ở giai đoạn đầu xây, sẽ hữu ích nếu mô hình hóa dữ liệu và bộ lọc mặc định trước khi tạo quá nhiều màn hình. Với AppMaster (appmaster.io), bạn có thể lặp nhanh trên các view admin, rồi thêm vài chỉ mục khớp những đường nóng khi sử dụng thực tế làm rõ chúng.