- vừa được xem lúc

5 Tội Lỗi SQL 'Chết Người' Đang Âm Thầm Giết Chết Ứng Dụng Của Bạn

0 0 2

Người đăng: James Miller

Theo Viblo Asia

SQL có vẻ đơn giản, nhưng những sai lầm của nó thì cực kỳ tai hại. Một câu lệnh chạy tốt trên dữ liệu thử nghiệm có thể dễ dàng làm sập toàn bộ hệ thống của bạn trên production. Bạn có đang mắc phải những tội lỗi SQL phổ biến này không?


1. Sự cám dỗ của SELECT *

Gõ thì nhanh thật, nhưng nó là một quả bom nổ chậm trong code production.

Tội lỗi: Dùng SELECT * kéo về mọi cột, tạo ra lưu lượng mạng không cần thiết, làm trình tối ưu hóa truy vấn bối rối, và làm ứng dụng của bạn sập ngay khi có ai đó thay đổi cấu trúc bảng.

Cách sửa: Hãy viết rõ ràng. Luôn chỉ định chính xác các cột bạn cần.

2. Ngộ nhận "Cứ thêm Index là xong"

Nghĩ rằng mọi truy vấn chậm đều có thể được sửa bằng cách thêm một index mới là một sai lầm kinh điển.

Tội lỗi: Index giúp đọc nhanh hơn nhưng lại làm chậm quá trình ghi (INSERT, UPDATE). Một index được thiết kế tồi có thể không bao giờ được sử dụng, khiến bạn tốn tài nguyên mà chẳng được lợi ích gì.

Cách sửa: Trước khi thêm index, hãy tự hỏi: Cột này có được đọc nhiều hơn ghi không? Index có khớp với các mệnh đề WHEREORDER BY của bạn không?

3. Thảm họa JOIN Đề-các

Đây là sai lầm biến cơ sở dữ liệu thành cát bụi.

Tội lỗi: Quên điều kiện ON trong JOIN sẽ tạo ra một Tích Đề-các (Cartesian Product). Join nhầm hai bảng 10,000 dòng không cho bạn 10,000 dòng — nó cho bạn 100,000,000 dòng, giết chết cơ sở dữ liệu của bạn ngay lập tức.

Cách sửa: Kiểm tra kỹ mọi JOIN. Điều kiện ON là huyết mạch của bạn.

4. Bỏ qua Transaction

Đây không chỉ là sai lầm của người mới; cả những lập trình viên kinh nghiệm cũng hay lười biếng.

Tội lỗi: Thực hiện các hoạt động liên quan đến nhau, như chuyển khoản ngân hàng, mà không bọc chúng trong một transaction. Nếu truy vấn thứ hai thất bại, truy vấn đầu tiên sẽ không được hoàn tác, và tiền bạc cứ thế biến mất.

Cách sửa: Nếu một chuỗi các hoạt động phải thành công hoặc thất bại cùng nhau, chúng bắt buộc phải nằm trong một khối TRANSACTION.

5. Tối ưu hóa "Theo cảm tính"

Viết SQL mà không kiểm tra kế hoạch thực thi (execution plan) cũng giống như lái xe mà nhắm mắt.

Tội lỗi: Bạn viết một truy vấn trông có vẻ hợp lý, nhưng bạn không bao giờ kiểm tra xem cơ sở dữ liệu thực sự chạy nó như thế nào. Bạn có thể nghĩ rằng nó đang sử dụng index, nhưng thực tế, nó đang quét toàn bộ bảng (full table scan).

Cách sửa: Hãy kết bạn với EXPLAIN. Trước khi commit bất kỳ truy vấn phức tạp nào, hãy chạy EXPLAIN để xem kế hoạch thực thi của nó.


Làm sao để kiểm thử và tránh những tội lỗi này?

Cách tốt nhất để phát hiện những sai lầm này là kiểm thử SQL của bạn trong một môi trường an toàn, giống như production. Việc thiết lập thủ công môi trường này rất phiền phức.

Đây là lúc một công cụ như ServBay tỏa sáng.

  • Cơ sở dữ liệu chỉ với một cú nhấp chuột: Khởi tạo nhiều phiên bản PostgreSQL, MariaDB, v.v.
  • Phân tích dễ dàng: Cung cấp các công cụ để xem kế hoạch thực thi và phân tích các truy vấn chậm.
  • Môi trường an toàn: Kiểm thử các truy vấn nguy hiểm trên máy local mà không bao giờ đụng đến cơ sở dữ liệu production.

image.png

Kết luận

Đừng xem thường SQL. Viết SQL tốt là trái tim của một ứng dụng hiệu suất cao. Hãy ngừng phạm phải những tội lỗi này và bắt đầu viết những câu lệnh truy vấn mà bạn có thể tự hào.

Bình luận

Bài viết tương tự

- vừa được xem lúc

RESTful API Design: Best Practices

Hey hey hey hey, cuối năm cũng khá bận bịu công việc này kia nên cũng không có nhiều thời gian viết bài phục vụ anh em được. Nay mình xin chia sẻ một vài những tiêu chí mà mình hay sử dụng khi viết REST API.

0 0 49

- vừa được xem lúc

18. Responsive là gì?

Truy cập http://fullstack.edu.

0 0 54

- vừa được xem lúc

19. Media queries?

Truy cập http://fullstack.edu.

0 0 61

- vừa được xem lúc

20. Tablet responsive

Truy cập http://fullstack.edu.

0 0 45

- vừa được xem lúc

21. Mobile menu responsive

Truy cập http://fullstack.edu.

0 0 42

- vừa được xem lúc

22. Mobile menu fix bug

Truy cập http://fullstack.edu.

0 0 38