Sử dụng stored procedures thay vì dùng các câu truy vấn (query) dạng ANSI
Có thể giảm lượng băng thông bởi vì máy khách (client) chỉ gửi đến máy chủ (server) tên của stored procedure (có thể có một vài tham số) thay vì gửi một câu truy vấn (query) dài và nặng nề. Stored procedures có thể thường được sử dụng để tăng tính bảo mật và cũng có thể che dấu những đối tượng dữ liệu bên dưới. Ví dụ, bạn có thể cấp quyền cho người sử dụng thực thi stored procedure để làm việc trong một tập các cột hoặc dữ liệu được hạn chế nào đó.
Thiết kế ứng dụng chạy các câu truy vấn (query) bất đồng bộ
Có thể gia tăng việc thực thi cho ứng dụng của bạn bởi vì một câu truy vấn (query) sẽ không phải chờ trước khi chạy.
Xem xét việc sử dụng Microsoft Transaction Server (MTS) cho việc sử dụng đối tượng
Có thể tăng hiệu suất cho ứng dụng của bạn bởi vì MTS cho phép sử dụng các đối tượng COM.
Nếu hầu hết người sử dụng đều có các máy tính hiện đại (‘fat’ clients), xem xét việc thiết kế ứng dụng để dự trữ (cache) dữ liệu ở máy của người sử dụng.
Bằng cách này, bạn có thể làm giảm việc nạp (load) SQL Server của bạn khi người sử dụng cần truy xuất dữ liệu mà sẽ sử dụng nguồn tài nguyên trên máy khách mà không cần nguồn tài nguyên của SQL Server.
Xem xét ích lợi của việc thiết kế ứng dụng với mô hình nhiều tầng (n-tier)
Việc sử dụng mô hình ứng dụng nhiều tầng (n-tier), có thể làm tăng việc thực thi và sự linh hoạt cho ứng dụng.
Thử giới hạn các tập kết quả (result sets) bằng việc sử dụng mệnh đề WHERE trong các câu SELECT.
Điều này có thể cho các kết quả với lợi ích thực thi tốt bởi vì SQL Server sẽ chỉ trả về cho máy khách (client) những dòng thoả điều kiện, mà không phải là tất cả các dòng trong bảng (table). Điều này làm giảm băng thông mạng và làm tăng hiệu suất tổng thể của câu truy vấn (query).
Thử giới hạn các tập kết quả (result sets) chỉ với các cột (columns) cần thiết từ bảng (table), mà không nên là tất cả các cột (columns) của bảng (table)
Điều này có thể cho các kết quả với lợi ích thực thi tốt bởi vì SQL Server sẽ chỉ trả về cho máy khách (client) những cột (columns) cần thiết, mà không phải là tất cả các cột (columns) của bảng (table). Điều này làm giảm băng thông mạng và làm tăng hiệu suất tổng thể của câu truy vấn (query).
Thử giới hạn các tập kết quả (result sets) bằng cách sử dụng các câu SELECT với TOP
Điều này có thể làm tăng hiệu suất của ứng dụng bởi vì tập kết quả (result set) được trả về sẽ nhỏ hơn. Điều này cũng có thể giảm băng thông giữa máy chủ (server) và các máy khách (clients).
Sử dụng các con trỏ (cursors) SQL Server để cho phép ứng dụng của bạn lấy một tập dữ liệu nhỏ của các dòng (rows) thay vì lấy tất cả các dòng của bảng (table)
Các con trỏ (cursors) SQL Server cho phép ứng dụng lấy một nhóm bất kỳ các dòng từ tập kết quả (result set), bao gồm n các dòng (n rows) kế tiếp, n các dòng (n rows) phía trước, hoặc n các dòng (n rows) bắt đầu từ một dòng nhất định trong tập kết quả (result set). Việc sử dụng các con trỏ (cursors) SQL Server có thể làm giảm băng thông mạng bởi vì tập dữ liệu được trả về sẽ nhỏ hơn.
Sử dụng ADO hoặc OLE DB cho việc truy xuất dữ liệu từ các ứng dụng cần hiệu suất cao.
Điều này có thể gia tăng hiệu suất của ứng dụng so với việc sử dụng DAO hoặc ODBC. OLE DB là một COM API cấp thấp (low-level) cho việc truy xuất dữ liệu và ADO là một giao diện cấp ứng dụng (application-level) mà sử dụng OLE DB. Microsoft đề nghị sử dụng OLE DB cho các công cụ phát triển, ứng dụng, hoặc các thành phần (components) mà cần hiệu suất cao và sử dụng ADO cho các chương trình với mục đích thông thường trong các ứng dụng thương mại (Kế toán, Quản lý nguồn nhân lực, và Quản lý khách hàng).
Khi bạn kết nối đến SQL Server, nên sử dụng “Microsoft OLE DB Provider for SQL Server” thay vì “Microsoft ODBC Driver for SQL Server”.
Bởi vì OLE DB nhanh hơn ODBC, bạn nên sử dụng OLE DB nếu có thể.
Thiết lập thời hạn khóa (lock time-out) để các câu truy vấn (queries) được sử dụng trong ứng dụng của bạn sẽ không rơi vào trạng thái mập mờ.
Bạn có thể sử dụng lệnh SET LOCK_TIMEOUT để cho phép một ứng dụng thiết lập một khoảng thời gian lớn nhất mà một câu lệnh thực hiện với một nguồn tài nguyên được cấp. Khi thiết lập LOCK_TIMEOUT bị vượt quá, câu lệnh đang thực hiện sẽ tự động bị hủy, và xuất hiện thông báo lỗi số 1222 “Lock request time-out period exceeded”. Ứng dụng của bạn nên có khả năng bắt được thông báo lỗi 1222.
Tránh việc sử dụng cả hai giao dịch OLTP và OLAP trong cùng một cơ sở dữ liệu (database).
Bởi vì các giao dịch OLTP là tối ưu cho việc quản lý dữ liệu thường bị thay đổi và các giao dịch OLAP là tối ưu cho các câu truy vấn (queries) dữ liệu mà không thay đổi dữ liệu. Cố gắng loại bỏ việc sử dụng các giao dịch OLTP và OLAP trong cơ sở dữ liệu (database).
Cố gắng tránh sử dụng phương thức Refresh khi bạn gọi stored procedures từ đối tượng ADO Command.
Điều này làm tăng hiệu suất cho ứng dụng của bạn bởi vì khi sử dụng phương thức Refresh sẽ làm tăng thêm băng thông mạng. Bạn nên nghĩ đến việc tạo stored procedure với các tham số khi sử dụng mã lệnh ADO, thay vì sử dụng phương thức Refresh để nhận biết các tham số của một stored procedure.
Tránh việc tạo các giao dịch khi sử dụng các phương thức của ADO.
Nên tạo các giao dịch bên trong một stored procedure với SQL Server. Bằng cách này, bạn có thể giảm được băng thông mạng và làm tăng hiệu suất toàn diện cho ứng dụng.
