Tìm yêu cầu tốn kém trước khi thay đổi cơ sở dữ liệu
Bắt đầu từ một hành động người dùng: tải danh mục, tìm kiếm bài viết, thêm vào giỏ hàng hoặc gửi đơn. Ghi lại đường dẫn (route), số truy vấn, thời lượng trên cơ sở dữ liệu, số hàng trả về và thời gian xử lý yêu cầu. Một trang chậm cũng có thể do mã ứng dụng hoặc phụ thuộc khác, nên không chẩn đoán chỉ từ thời gian tải trang.
Plan truy vấn là lộ trình của cơ sở dữ liệu qua các bảng, chỉ mục, các phép nối, sắp xếp và tổng hợp. Trong PostgreSQL, EXPLAIN cho thấy lộ trình đó. EXPLAIN ANALYZE chạy câu lệnh và báo cáo số hàng và thời gian thực tế, vì vậy hãy dùng một truy vấn đại diện an toàn. Khoảng cách lớn giữa ước tính và thực tế về số hàng là lý do để điều tra thống kê hoặc điều kiện, chứ không phải lý do tự động để thêm chỉ mục.
Liên kết một truy vấn ứng viên với hành trình và kết quả, để báo cáo chỉ trên dashboard không át đi một checkout chậm.
Ghi lại thời gian trước khi thay đổi và lưu lượng tương đương mà không lưu các định danh khách hàng, token hoặc dữ liệu liên quan thẻ.
Thiết kế chỉ mục theo đường truy cập bạn thực sự sử dụng
Chỉ mục là cấu trúc được duy trì giúp định vị hàng hoặc trả chúng theo thứ tự; nó không phải là công tắc tăng tốc tổng quát. Bắt đầu từ các bộ lọc, khóa nối và thứ tự sắp xếp (ORDER BY) của truy vấn quan trọng rồi xác nhận chỉ mục đề xuất trên plan. PostgreSQL ghi rằng một chỉ mục B-tree phù hợp có thể thỏa mãn ORDER BY mà không cần sắp xếp riêng, đặc biệt khi có LIMIT nhỏ.
Chỉ mục tăng không gian lưu trữ và công việc ghi vì insert, update, delete phải duy trì chúng. Với truy vấn cần phần lớn bảng, quét tuần tự (sequential scan) và sắp xếp tường minh có thể nhanh hơn. Thử trên dữ liệu giống sản xuất và giữ chỉ mục chỉ khi lợi ích bù đắp chi phí.
Dùng các bộ lọc thực tế của truy vấn và ORDER BY, bao gồm trình phân giải tie-breaker xác định khi giao diện cần thứ tự ổn định.
Xem xét liệu chỉ mục có được dùng và nó tiêu tốn gì cho các thao tác ghi; kiểm tra lại khi dữ liệu và lưu lượng thay đổi.
Làm cho phân trang ổn định và tiết kiệm
Phân trang theo số trang thường dùng LIMIT kèm OFFSET. Luôn quy định một thứ tự xác định. PostgreSQL cảnh báo rằng nếu không có ORDER BY, LIMIT có thể trả một tập con không xác định; các giá trị LIMIT hoặc OFFSET khác nhau có thể cho các tập con không nhất quán vì trình tối ưu có thể chọn các plan khác nhau.
OFFSET lớn cần xem xét vì các hàng bị bỏ qua vẫn phải được tính. Với duyệt sâu danh mục, lịch sử đơn hàng, hoặc kho lưu trữ, cân nhắc phân trang bằng cursor hoặc keyset: yêu cầu các hàng sau giá trị sắp xếp ổn định cuối cùng và tie-breaker duy nhất. Định nghĩa cách các bản ghi mới hoặc bị xóa xuất hiện trước khi thay đổi giao diện.
Trả về trang nhỏ nhất hữu ích thay vì danh sách không giới hạn.
Quyết định giao diện có thực sự cần tổng chính xác ở mỗi yêu cầu hay không.
Cache kết quả đọc mà không phục vụ phản hồi sai
Caching tái sử dụng kết quả trước đó thay vì dựng lại từ cơ sở dữ liệu. Bắt đầu ở lớp HTTP cho các trang công cộng, lặp lại và tài sản có phiên bản, vì cache hit có thể tránh công việc ứng dụng và cơ sở dữ liệu. web.dev khuyến nghị caching lâu cho URL có phiên bản; thay đổi URL là cơ chế vô hiệu hóa thực tế.
Chính sách cache là quyết định về tính đúng đắn. Cache chia sẻ có thể tái sử dụng một phản hồi cho nhiều người dùng, vậy không chia sẻ đầu ra liên quan tài khoản, giỏ hàng, giá hay ủy quyền trừ khi được thiết kế và kiểm thử ở phạm vi đó. Cache-Control: private giới hạn tái sử dụng trong cache trình duyệt, trong khi no-store chỉ dẫn các cache không lưu trữ.
Tách đầu ra danh mục công cộng hoặc bài viết khỏi nội dung theo phiên, theo vị trí và nhạy cảm với quyền.
Định nghĩa ai có thể thấy giá trị lỗi thời, trong bao lâu, và đường dẫn vô hiệu hóa hoặc tái xác thực.
Bảo vệ dung lượng kết nối thay vì chỉ tăng giới hạn
Kết nối là phiên khách hàng đang mở tới cơ sở dữ liệu. Worker, cron job, xem trước hoặc retry có thể cạn kiệt các slot ngay cả khi từng truy vấn đơn lẻ trông chấp nhận được. max_connections của PostgreSQL điều khiển kết nối đồng thời, được đặt khi server khởi động, và giá trị cao hơn cấp phát thêm tài nguyên bao gồm shared memory. Tăng nó mà không có mô hình tải có thể chỉ dời điểm thất bại.
Đặt một ngân sách chung cho web worker, job nền, quản trị và bản sao. Dùng connection pool có giới hạn nơi phù hợp, giữ dư chỗ cho khôi phục, và áp dụng timeout để công việc bị bỏ rơi không chờ vô thời hạn. Số an toàn phụ thuộc vào engine, bộ nhớ, tỉ lệ truy vấn và giới hạn nhà cung cấp; xác nhận với người vận hành.
Bao gồm tiến trình web, hàng đợi, tác vụ theo lịch, migration, công cụ báo cáo và job triển khai.
Giới hạn đồng thời và dùng backoff để một lỗi không nhân lên nhu cầu kết nối.
Quan sát chi phí truy vấn với ngữ cảnh và kiểm soát riêng tư
Xếp hạng công việc cơ sở dữ liệu theo tổng ảnh hưởng, không phải một mẫu chậm đơn lẻ. Một truy vấn hơi chậm được gọi hàng nghìn lần có thể quan trọng hơn một báo cáo hiếm gặp. pg_stat_statements của PostgreSQL tổng hợp dữ liệu lập kế hoạch và thực thi bao gồm số lần gọi, tổng và trung bình thời gian thực thi, số hàng và hoạt động buffer. Nó cần cấu hình server và khởi động lại để bật hoặc tắt; việc theo dõi này có thể thêm chi phí.
Liên kết nhóm truy vấn với route, phiên bản phát hành và khoảng thời gian. OpenTelemetry khuyên chỉ thu thập câu truy vấn thô sau khi đã làm sạch (sanitization) thay thế literal, và dùng tóm tắt truy vấn có cardinality thấp để nhóm. Điều này giúp người phụ trách thấy xu hướng mà không xuất dữ liệu khách hàng hoặc tạo nhãn cho mọi giá trị.
Xem duration, tổng thời gian, số lần gọi, lỗi, kết nối và số hàng; mỗi chỉ báo hé lộ một chế độ lỗi khác nhau.
Dùng truy vấn tham số hóa và xác minh literal đã bị loại trước khi trace hay log rời ứng dụng.
Đưa thay đổi cơ sở dữ liệu ra sản xuất như công việc độ tin cậy có thể hoàn nguyên
Xem một chỉ mục, rewrite, chính sách cache, cấu hình pool hay thay đổi schema như một thay đổi sản xuất có chủ sở hữu, chỉ số thành công và quyết định rollback. Xác thực trong môi trường đại diện, phát hành cho lát cắt giới hạn và theo dõi hành trình bị ảnh hưởng. Nhanh hơn không phải là thành công nếu thay đổi trả về dữ liệu sai, thiếu, trùng hoặc lỗi thời.
Thay đổi schema cần cẩn trọng vì các phiên bản ứng dụng có thể chồng lấp. Hướng dẫn của Google Cloud mô tả trình tự ưu tiên tương thích: phát hành ứng dụng có thể xử lý cả schema cũ và mới, thay đổi schema, rồi phát hành tính năng dùng schema mới. Điều này giữ được đường hồi ứng dụng. Cơ chế khóa và hành vi thay đổi online khác nhau theo engine và dịch vụ quản lý; cần có đánh giá có thẩm quyền cho hệ thống khối lượng lớn hoặc liên quan thanh toán.
Đặt tên route, các tín hiệu hiệu năng và tính đúng đắn, cùng ngưỡng dừng rollout.
Xác minh hiệu năng và tính đúng đắn trong một lát cắt kiểm soát trước khi mở rộng; luyện tập đường hồi về ngoài tình huống sự cố.