Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Quản lý chỉ mục tự động trong cơ sở dữ liệu Azure SQL

Vào tháng 2, tôi đã viết một bài đăng trên blog về Sửa kế hoạch tự động trong SQL Server và trong bài đăng này, tôi muốn nói về Quản lý chỉ mục tự động, thành phần thứ hai của tính năng Điều chỉnh tự động. Quản lý chỉ mục tự động chỉ khả dụng trong Cơ sở dữ liệu Azure SQL và nó hiện không có trong lộ trình sẵn có trong phiên bản tiếp theo của SQL Server tại chỗ. Tùy chọn này được bật độc lập với Sửa kế hoạch tự động và như tên của nó, nó sẽ quản lý các chỉ mục trong cơ sở dữ liệu của bạn. Cụ thể, nó có thể tạo các chỉ mục bị thiếu và có thể loại bỏ các chỉ mục không được sử dụng và những chỉ mục trùng lặp. Hãy xem điều này xảy ra như thế nào.

Dưới lớp phủ Quản lý chỉ mục tự động
dựa vào dữ liệu để đưa ra quyết định. Để tạo chỉ mục tiềm năng, nó sử dụng thông tin DMV chỉ mục bị thiếu và theo dõi nó theo thời gian và kết hợp dữ liệu đó với một mô hình nội bộ để xác định lợi ích của chỉ mục. Nó cũng sử dụng Cửa hàng truy vấn để xác định xem chỉ mục có mang lại lợi ích hay không, vì vậy nó phải được kích hoạt cho cơ sở dữ liệu, giống như với Chỉnh sửa kế hoạch tự động. Liên quan đến việc giảm chỉ mục, dữ liệu từ việc sử dụng chỉ mục DMV (sys.dm_db_index_usage_stats) cũng như siêu dữ liệu chỉ mục (ví dụ:số cột, kiểu dữ liệu cột) được sử dụng.

Bật quản lý chỉ mục tự động
Như đã đề cập, Query Store phải được kích hoạt cho cơ sở dữ liệu. Điều này có thể được thực hiện trong SSMS, với T-SQL và với API REST cho Cơ sở dữ liệu Azure SQL. Lưu ý rằng Cửa hàng truy vấn được bật theo mặc định cho cơ sở dữ liệu trong Azure và đã có từ Q4 năm 2016.

USE [master];
GO
ALTER DATABASE [WideWorldImporters] 
	SET QUERY_STORE = ON;
GO
ALTER DATABASE [WideWorldImporters] 
	SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

Sau khi Query Store được bật, bạn có thể sử dụng Azure Portal, T-SQL hoặc EST API để bật Quản lý chỉ mục tự động trong Cơ sở dữ liệu Azure SQL (C # và PowerShell đang hoạt động).

ALTER DATABASE [WWI_PS] SET AUTOMATIC_TUNING (CREATE_INDEX = ON, DROP_INDEX = ON);
GO

Quản lý chỉ mục tự động sẽ được bật theo mặc định cho cơ sở dữ liệu mới trong Azure (https://azure.microsoft.com/en-us/blog/automatic-tuning-will-be-a-new-default/) trong tương lai gần. Bắt đầu từ tháng 1 năm 2018, Microsoft đã bắt đầu triển khai tính năng Điều chỉnh Tự động cho Cơ sở dữ liệu Azure SQL chưa được bật, với thông báo được gửi đến quản trị viên để tùy chọn này có thể bị tắt nếu muốn. Quá trình này mất vài tháng, vì vậy nếu bạn vẫn chưa nhận được thông báo, đừng lo lắng!

Cách hoạt động
Để tạo chỉ mục, hiện tại, có thời hạn luân phiên là bảy (7) ngày * mà dữ liệu được theo dõi và tối thiểu mô hình cần chín (9) giờ * dữ liệu để đề xuất một chỉ mục, cùng với 12 giờ * dữ liệu trong Cửa hàng truy vấn sẽ được sử dụng làm đường cơ sở. Nếu xác định rằng một chỉ mục sẽ mang lại lợi ích đáng kể thì SQL Server sẽ tạo chỉ mục.

* Những giá trị này có thể thay đổi trong tương lai, khi mô hình phát triển.

Lưu ý:hiện tại, mô hình thực hiện các khuyến nghị hợp nhất. Có nghĩa là, nếu nhiều chỉ mục được đề xuất cho một bảng, nhưng một chỉ mục có thể được tạo để bao gồm tất cả các tùy chọn, thì nó có thể tạo một chỉ mục đó hiện tại. Tuy nhiên, mô hình hiện không đủ thông minh để hợp nhất một chỉ mục được đề xuất với một chỉ mục đã tồn tại.

Sau khi một chỉ mục được tạo, SQL Server xác minh rằng nó cung cấp lợi ích bằng cách sử dụng Query Store (do đó phải được kích hoạt cho cơ sở dữ liệu). Nó giám sát hiệu suất của bất kỳ truy vấn nào sử dụng chỉ mục mới và so sánh CPU của truy vấn trước khi chỉ mục được thêm vào và khi sử dụng chỉ mục. Nếu có một hồi quy trong hiệu suất truy vấn do kết quả của chỉ mục, thì nó sẽ hoàn nguyên (giảm) chỉ mục. SQL Server giám sát hiệu suất truy vấn trong tối đa ba (3) ngày hoặc cho đến khi 100% khối lượng công việc liên quan đã được phân tích. Sau khoảng thời gian đó, nếu chỉ số không có bất kỳ dấu hiệu hồi quy nào, thì nó sẽ không xem xét lại hiệu suất cho nó nữa.

Hiểu rằng nếu Quản lý chỉ mục tự động tạo chỉ mục và sau đó hai tháng khối lượng công việc của bạn thay đổi và nó sẽ được hưởng lợi từ chính chỉ mục đó được tạo tự động trước đó nhưng có thêm một cột, thì hiện tại, SQL Server sẽ tạo chỉ mục mới. Hiện tại, không có logic nào để thay đổi chỉ mục được tạo tự động hiện có, nhưng chức năng đó nằm trong lộ trình của tính năng.

Liên quan đến việc giảm chỉ mục, nếu một chỉ mục không tìm kiếm hoặc quét trong 90 ngày, nhưng có chi phí bảo trì (nghĩa là có chèn, cập nhật hoặc xóa) thì nó sẽ bị loại bỏ. Các chỉ mục trùng lặp cũng sẽ bị xóa, giả sử chúng là một bản sao chính xác (và lược đồ được sử dụng để xác định xem các chỉ mục có hoàn toàn giống nhau hay không). Nếu có các chỉ mục trùng lặp về các cột chính và các cột được bao gồm (nếu có liên quan) nhưng một hoặc nhiều trong số chúng có bộ lọc, thì chúng không thực sự trùng lặp và không có chỉ mục nào bị loại bỏ.

Để tham khảo, có số đề xuất DROP INDEX trong Cơ sở dữ liệu Azure SQL nhiều gấp hai lần số đề xuất CREATE INDEX.

Khi bạn bật tùy chọn DROP INDEX, SQL Server sẽ loại bỏ các chỉ mục do người dùng tạo. Khi bạn bật tùy chọn CREATE INDEX, SQL Server có khả năng tạo chỉ mục tự động và cũng có thể loại bỏ các chỉ mục đó (nhưng sẽ không loại bỏ các chỉ mục do người dùng tạo). Cuối cùng, các chỉ mục được tạo và loại bỏ trong thời gian khối lượng công việc không cao điểm, do DTU xác định. Nếu khối lượng công việc trên 80% DTU, thì SQL Server sẽ đợi để tạo hoặc giảm chỉ mục cho đến khi tải hệ thống giảm.

Tôi có thực sự để cho SQL Server có quyền kiểm soát không?
Có thể. Đề xuất của tôi về tính năng này, ban đầu, yêu cầu cách tiếp cận "tin tưởng nhưng xác minh".

Cũng như với Sửa kế hoạch tự động, Quản lý chỉ mục tự động đã được phát triển với lượng dữ liệu đáng kể được thu thập từ gần hai triệu Cơ sở dữ liệu Azure SQL. Tính năng Quản lý Chỉ mục Tự động đã có sẵn trong Cơ sở dữ liệu Azure SQL kể từ Quý 1 năm 2016, như một phần của Trình tư vấn Chỉ mục.

Các thuật toán được sử dụng bởi tính năng này đã phát triển và tiếp tục phát triển theo thời gian, khi nhiều cơ sở dữ liệu sử dụng nó hơn và nhiều dữ liệu được thu thập và phân tích hơn. Tuy nhiên, có một số hạn chế hiện tại.

  1. Các đề xuất chỉ số không được đánh giá dựa trên các chỉ mục hiện có, do đó, việc hợp nhất chỉ mục giữa các chỉ mục mới và hiện tại không khả dụng.
  2. Nếu một chỉ mục mang lại lợi ích cho một CHỌN, thì chi phí sửa đổi do CHÈN, CẬP NHẬT và XÓA không được biết trước khi tạo. SQL Server giám sát chi phí này trong quá trình xác minh, sau khi chỉ mục được triển khai.

Có những lợi ích đối với Quản lý chỉ mục tự động đáng được nêu rõ:

  1. Đối với bất kỳ ai phải quản lý cơ sở dữ liệu SQL Server, nhưng không phải là DBA, các đề xuất chỉ mục có thể cực kỳ hữu ích.
  2. Đề xuất chỉ mục được ghi lại trong DMV sys.dm_db_tuning_recommendations ngay cả khi các tùy chọn chỉ mục CREATE và DROP không được bật. Do đó, nếu bạn không chắc chắn về những thay đổi mà SQL Server có thể thực hiện, bạn có thể xem lại những gì được ghi lại trong DMV và sau đó đưa ra quyết định triển khai đề xuất theo cách thủ công.

    Lưu ý:Nếu bạn triển khai đề xuất theo cách thủ công, SQL Server sẽ không thực hiện bất kỳ xác thực nào. Nếu bạn triển khai đề xuất thông qua Cổng thông tin (sử dụng nút Áp dụng) hoặc API REST, thì đề xuất đó sẽ được thực thi như thể đó là một hành động tự động và xác thực sẽ được thực hiện (và chỉ mục có thể được hoàn nguyên tự động nếu có hồi quy).

  3. Tính năng này tiếp tục được cải thiện. Như tôi đã nói trước đây, Microsoft không cố gắng mã hóa các DBA hoặc các nhà phát triển không có việc làm, họ đang cố gắng giải quyết hiệu quả thấp để bạn có nhiều thời gian hơn cho các nhiệm vụ và dự án không thể tự động hóa một cách thông minh.

Tóm tắt
Nếu bạn chưa sẵn sàng giao quyền quản lý chỉ mục, tôi hiểu. Nhưng nếu bạn có Cơ sở dữ liệu Azure SQL ở mức tối thiểu, bạn nên kiểm tra sys.dm_db_tuning_recommendations DMV thường xuyên để xem SQL Server đang đề xuất những gì và so sánh dữ liệu đó với dữ liệu mà bạn hoặc công cụ giám sát bên thứ ba của bạn có thể đang nắm bắt về việc sử dụng chỉ mục. Rốt cuộc, lần cuối cùng bạn đánh giá đầy đủ và kỹ lưỡng các chỉ mục của mình để hiểu những gì còn thiếu, những gì thực sự đang được sử dụng và những gì chỉ đơn giản là tạo ra chi phí trong cơ sở dữ liệu?


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Bắt đầu Điều chỉnh Hiệu suất trong Cơ sở dữ liệu Azure SQL

  2. Mặt nạ dữ liệu trong các ứng dụng DB

  3. Nhận dạng mẫu hàng trong SQL

  4. SQL, tạo bảng

  5. Cách thêm cột trong SQL