3 vấn đề hiệu suất hàng đầu mà bạn gặp phải với Máy chủ SQL của mình là gì?

Tôi là sinh viên của Đại học Fontys ở Eindhoven và hiện tôi đang thực hiện một loạt các cuộc phỏng vấn để giúp phát triển công cụ SQL Server và tôi muốn nhận phản hồi từ các chuyên gia trong lĩnh vực này.

Một trong những câu hỏi của tôi là:

3 vấn đề hiệu suất hàng đầu mà bạn gặp phải với Trường hợp Máy chủ SQL của bạn là gì và làm thế nào để bạn xác định những vấn đề đó?

Đặc biệt tôi quan tâm đến các kịch bản và các công cụ được sử dụng để đo lường điều này.

Tắt đầu tôi - 3 vấn đề truy vấn hàng đầu:

• Chuyển đổi ngầm định
• Chiến lược lập chỉ mục xấu (quá nhiều hoặc không đủ hoặc loại sai)
• Sử dụng CHỌN * thay vì chỉ đặt tên các trường bạn cần

Có nhiều hơn nữa xung quanh các vấn đề cấu hình cấp máy chủ, vấn đề lược đồ cơ sở dữ liệu, sự cố phần cứng, v.v. Tôi đã viết một tập lệnh để nhanh chóng phân tích các máy chủ đang tìm kiếm các loại vấn đề này:

http://www.brentozar.com/blitz/

• Thiết kế / truy vấn / lập chỉ mục kém
• Không được phép mua phần cứng chính xác
• Các ORM Braindead (còn gọi là "SQL đã chết")

Không phải top 3, nhưng nghĩ rằng tôi sẽ đề cập đến những điều chưa được đề cập:

1. SQL đưa vào các máy ảo không có chi tiết / minh bạch được cung cấp cho DBA. Máy chủ lưu trữ sẽ tự động thay đổi cài đặt máy khách gây giảm hiệu suất và khiến DBA không có đầu mối. Các tính năng như siêu đọc, kết nối mạng và tạo bóng bộ nhớ làm cho bộ đếm hiệu suất trở thành mục tiêu di động để theo dõi.Tools: sysmon/perfmon, DMVs, maintaining a history of performance counters in tables.
2. Tương tự, không có tính minh bạch / kiểm chứng trên các cài đặt SAN được cung cấp cho DBA. Tôi đã có các LUN với các tùy chọn bộ đệm đọc / ghi khác nhau được thiết lập nhưng nói rằng tất cả chúng đều giống nhau.Tools: IO DMVs, SQLIO.
3. Kiến trúc DB xấu: như định cỡ và vị trí của tệp dữ liệu và nhật ký và tempdb. Sử dụng song song không đúng cách. Tạo nhiều filegroup trên cùng một đĩa vật lý.Tools: experience.

Một công cụ khác mà tôi đang kiểm tra bây giờ là Project Lucy . Có vẻ gọn gàng.

• thiếu chỉ số thích hợp
• sử dụng với nolock trong mã sản xuất bởi ai đó để cố gắng giải quyết các vấn đề về hiệu suất. Đặc biệt xấu nếu mã sửa đổi dữ liệu trong bảng
• ứng dụng chọn nhiều dữ liệu hơn mức cần thiết nhiều lần hơn là phân. Ex có một nhị phân được trả về mọi lúc ngay cả khi bạn chỉ muốn văn bản của cùng một bảng.

Các truy vấn có quy mô xấu (nhận tất cả các đơn đặt hàng trong X năm cho tất cả khách hàng, v.v. bao gồm tất cả các đơn hàng bao gồm dữ liệu tổng hợp và dữ liệu trung bình khác được tính toán kém)

Chỉ cần truy vấn mọi thứ cùng một lúc.

Các bảng có chứa các trường varchar / văn bản 'mô tả' phải được tìm kiếm thông qua mọi truy vấn.

• Bảo trì không đúng cách, nghĩa là không có chỉ số, chỉ số, không sao lưu nhật ký
• Thiếu chỉ số
• Truy vấn bằng văn bản kém

• Cơ sở dữ liệu và thiết kế ứng dụng kém
• sử dụng kém các lợi thế nền tảng (các nhà phát triển muốn có mã truy cập cơ sở dữ liệu dựa trên nền tảng. Không có SP, không có chức năng, v.v.)
• lập chỉ mục xấu, tất nhiên.

• truy vấn đặc biệt trên dữ liệu prod - vâng, các nhà phát triển tin rằng nó cần thiết và một số thậm chí có thể có quyền truy cập :-)
• thiết kế xấu của ứng dụng sử dụng cơ sở dữ liệu - ví dụ: quá nhiều dữ liệu được thêm vào và không bao giờ bị xóa ngay cả khi không còn cần thiết nữa (điều này dẫn đến các vấn đề về hiệu suất vì sao lưu lớn, công việc bảo trì mất nhiều thời gian hơn..vv)
• tất cả các tệp cơ sở dữ liệu trên cùng một cuộc đột kích hoặc tệ hơn, trên cùng một ổ đĩa (ví dụ: dbs hệ thống, tempdb, dbs người dùng cùng nhau trên cùng một ổ đĩa / đột kích)

• Thiết kế cơ sở dữ liệu kém
• Chiến lược lập chỉ mục kém (bao gồm quá nhiều chỉ mục, thiếu chỉ mục và thiếu bảo trì chỉ mục)
• Quyết định kiến ​​trúc phần cứng kém

Lập chỉ mục rất quan trọng đối với hiệu suất, nhưng tôi đã tìm thấy hầu hết các DBA biết điều đó, và do đó, nó có xu hướng là một trong những điều đầu tiên được khắc phục thông qua tối ưu hóa truy vấn. Các lĩnh vực thường không được giải quyết tốt:

1. Quá nhiều chuyến đi khứ hồi DB. Hayiness là một trong những vấn đề hiệu suất chính mà tôi thấy.
2. Bắt đúng ranh giới giao dịch. Giao dịch mọi CHERTN / CẬP NHẬT / XÓA có thể là một kẻ giết người hiệu suất lớn.
3. Không tối ưu hóa phần cứng; đặc biệt, đặt nhật ký DB trên một ổ đĩa khác với dữ liệu DB.

Nếu tôi có thể thêm một mục thứ tư vào danh sách, đó sẽ là việc sử dụng quá trình kích hoạt và / hoặc con trỏ quá mức và không phù hợp. Dường như không xảy ra quá nhiều trong những ngày này, nhưng khi nó xảy ra, nó đau đớn từ góc độ hiệu suất.