Bản thân bạn là 1 Developer, đã bao giờ bạn sài 1 cái mobile app hoặc một trang web nào đó mà bạn cảm thấy cực kỳ khó chịu khi phải chờ đợi rất lâu mỗi lần nhấn nút hay load trang chưa. Với mình thì….. lộn cái bàn ngay và luôn. Thực sự khá khó chịu khi phải trải nghiệm cảm giác đó, mà càng cay hơn khi nếu app đó là do chính tạo tham gia phát triển.

Vậy thì, ngay bây giờ, cùng mình thử bẩy bẩy bốn chín cách sau để giúp ứng dụng của chúng ta chạy mượt hơn nhé.

À, và tất nhiên vì bạn là 1 Developer nhiều năm kinh nghiệm nên mình mặc định rằng bạn hiểu rõ về cơ sở dữ liệu cũng như các thao tác truy vấn cơ bản như SELECT, INSERT, UPDATE, DELETE.

Khi chúng ta code, với dữ liệu nhỏ, hệ thống của chúng ta lúc nào cũng ngon ngả và ngọt nước, nhưng khi triển khai lên UAT, khách hàng tham gia vào test thì rất nhiều vấn đề liên quan đến trải nghiệm người dùng. Vì dữ liệu liên tục phình to lên, khiến cho hệ thống bắt đầu chậm dần, đôi khi chỉ với 1 thao tác với chức năng thống kê dữ liệu, nhưng phải mất đến 1 tiếng đồng hồ để lấy dữ liệu.

Bài toán đặt ra cho chúng ta là, phải làm thế nào để giảm thời gian thực hiện mà vẫn đáp ứng được dữ liệu mong muốn.

1. Dùng tiền để giải quyết mọi thứ

Nếu lưu trữ database trên ổ cứng thì chuyển từ HDD thành SSD, nâng thêm RAM, hoặc sử dụng thêm vài con Cache Server, sử dụng nhiều database server. Cơ bản là phải có tiền.

2. Sharding/Partitioning dữ liệu

Hiểu đơn giản là Partition chính là chia để trị, giả sử ta có 1 table ghi lại giao dịch của 1 cái máy ATM, sau 1 năm thì số lượng records trogn table này đã đạt đến con số 1 triệu dòng. Nếu chúng ta query tìm kiếm dữ liệu từ tháng 2 đến tháng 3 trong bảng này, chắc chắn sẽ mất kha khá thời gian. Sử dụng kỹ thuật Partition, chúng ta sẽ chia table này thành 12 table, tương ứng theo 12 tháng. Mỗi table chỉ chứa dữ liệu của tháng đó đó àm thôi (giả sử còn 100 ngàn dòng). Vậy giờ nếu chúng query lại câu tìm kiếm từ tháng 2 đến tháng 3 ở trên, sẽ rất nhanh, vì lúc này chỉ cần truy xuất vào table chứa dữ liệu của tháng 2 với 100 ngàn dòng mà thôi.

3. Chỉ lấy đúng và đủ những gì mình cần

Rất nhiều bạn lúc viết câu query thường có thói quen SELECT * FROM xXx; để rồi chỉ lấy đúng 2 cột dữ liệu trong bản này. Đây là một trong những lỗi cơ bản gây chậm cho câu SQL của bạn. Sau đây là chi tiết một số lỗi sai bạn cần khắc phục:

  • Chỉ muốn lấy 2 cột trong bảng: KHÔNG NÊN (Select * From XxX), NÊN (Select user_id, user_name From XxX)
  • Có nhiều rows, nhưng chỉ muốn lấy 1 row duy nhất sau khi sắp xếp giảm dần theo ngày tạo: KHÔNG NÊN (Select user_id, user_name From XxX order by created_date desc), NÊN (Select user_id, user_name From XxX order by created_date desc OFFSET 0 ROWS FETCH NEXT 1 ROWS ONLY)
  • Với những câu tìm kiếm, chúng ta nên giới hạn số dòng dữ liệu cần lấy ra mỗi lần tìm kiếm. Chúng ta sẽ nhận các biến như “tổng số dòng cần lấy”, “lấy từ vị trí bao nhiêu” để query dưới database cho hợp lý.

4. Đánh chỉ mục (Index)

Chỉ mục là bảng tra cứu đặc biệt mà Database Search Engine có thể sử dụng để tăng thời gian và hiệu suất truy vấn dữ liệu. Index làm tăng hiệu năng của lệnh SELECT nhưng lại làm giảm hiệu năng của lệnh INSERT, UPDATE DELETE. Chỉ nên index những trường có kiểu dữ liệu số. Những kiểu dữ liệu khác nếu không phải là đặc biệt, hoặc ko phải tìm kiếm nhiều thì ko nên index.

Một số phép toán phủ định như: “IS NULL”, “!=”, “NOT”, “NOT IN”, “NOT LIKE”,… không nên sử dụng với cột đã được đánh index. Hạn chế sử dụng phép toán so sánh 2 lần như “>=”, “<=” với những trường đánh index (bản chất của phép toán này là phép toán OR (nên dùng OR)).

5. Dùng “LIKE” đúng

Khi sử dụng LIKE, không nên sử dụng ký tự %, * đặt ở phía trước giá trị tìm kiếm mà nên đặt ở sau, ví dụ như LIKE ‘Viet %’. Trong trường hợp bắt buộc thì nên sử dụng FULL TEXT như sau CONTAINS(National, ‘Viet’).

6. Cần biết lúc nào nên sử dụng UNION lúc nào nên dùng UNION ALL

UNION thực chất bằng với SELECT DISTINCT, hệ thống sẽ thực hiện sắp xếp, lọc và loại bỏ các bản ghi trùng. UNION ALL sẽ không thực hiện lọc và loại bỏ các bản ghi trùng lặp. Tùy vào dữ liệu mà chúng ta cần lấy như thế nào, thì chọn sử dụng UNION hoặc UNION ALL cho hợp lý.

7. Hạn chế sử dụng Distinct, Order By khi không cần thiết

8. Sử dụng EXISTS thay vì COUNT hoặc IN khi bạn muốn xác định một bản ghi có tồn tại không

Với Exists, việc kiểm tra và so sánh sẽ trả về kết qua TRUE ngay khi nó tìm thấy kết quả, vì thế giảm thiểu thời gian rất nhiều.

9. Tương tự, giữa IN BETWEEN thì hãy chọn BETWEEN

10. Tránh sử dụng Trigger, tránh sử dụng Having Group by, tránh sử dụng Sub query Có thể thay thế Sub-Query bằng JOIN.

Áp dụng một số mánh nhỏ trên, có thể giúp bạn đạt điểm cao trong mắt crush (Tester) mỗi khi bị than phiền về hệ thống chậm. Hãy thử sử dụng và trải nghiệm sự khác biệt nhé. Chúc các bạn OT ko lương vui vẻ.

Nhớ ghi nguồn https://susudev.com khi đăng tải lại bài viết này