Thủ thuật điều chỉnh hiệu suất yêu thích [đóng]


126

Khi bạn có một truy vấn hoặc thủ tục lưu trữ cần điều chỉnh hiệu suất, một số điều đầu tiên bạn thử là gì?


Dưới đây là một số thủ thuật Tối ưu hóa truy vấn SQL Server
SQLMenace

Tôi đồng ý rằng điều này không mang tính xây dựng và có thể được tìm kiếm trong Google, nhưng tại sao nó có 118 uv?! :)
FLICKER 17/05/2016

Câu trả lời:


114

Dưới đây là danh sách những thứ tiện dụng mà tôi luôn đưa cho ai đó hỏi tôi về tối ưu hóa.
Chúng tôi chủ yếu sử dụng Sybase, nhưng hầu hết các lời khuyên sẽ được áp dụng trên bảng.

Ví dụ, SQL Server đi kèm với một loạt các bit giám sát / điều chỉnh hiệu suất, nhưng nếu bạn không có bất cứ thứ gì như vậy (và thậm chí nếu bạn làm như vậy) thì tôi sẽ xem xét ...

99% các vấn đề tôi đã thấy là do đặt quá nhiều bảng vào một liên kết . Cách khắc phục cho việc này là thực hiện một nửa phép nối (với một số bảng) và lưu kết quả vào một bảng tạm thời. Sau đó thực hiện phần còn lại của truy vấn tham gia trên bảng tạm thời đó.

Danh sách kiểm tra tối ưu hóa truy vấn

  • Chạy CẬP NHẬT THỐNG KÊ trên các bảng bên dưới
    • Nhiều hệ thống chạy này như một công việc hàng tuần theo lịch trình
  • Xóa các bản ghi từ các bảng bên dưới (có thể lưu trữ các bản ghi đã xóa)
    • Cân nhắc làm điều này tự động một lần một ngày hoặc một lần một tuần.
  • Xây dựng lại chỉ mục
  • Xây dựng lại bảng (dữ liệu bcp ra / vào)
  • Kết xuất / Tải lại cơ sở dữ liệu (quyết liệt, nhưng có thể khắc phục tham nhũng)
  • Xây dựng chỉ mục mới, phù hợp hơn
  • Chạy DBCC để xem có khả năng tham nhũng trong cơ sở dữ liệu không
  • Khóa / Bế tắc
    • Đảm bảo không có quá trình khác đang chạy trong cơ sở dữ liệu
      • Đặc biệt là DBCC
    • Bạn đang sử dụng khóa cấp hàng hoặc trang?
    • Khóa các bảng độc quyền trước khi bắt đầu truy vấn
    • Kiểm tra xem tất cả các quy trình đang truy cập các bảng theo cùng một thứ tự
  • Là chỉ số đang được sử dụng một cách thích hợp?
    • Tham gia sẽ chỉ sử dụng chỉ mục nếu cả hai biểu thức có cùng kiểu dữ liệu
    • Chỉ mục sẽ chỉ được sử dụng nếu (các) trường đầu tiên trên chỉ mục được khớp trong truy vấn
    • Là các chỉ số cụm được sử dụng khi thích hợp?
      • dữ liệu phạm vi
      • Trường WHERE giữa value1 và value2
  • Joins nhỏ là Nice Joins
    • Theo mặc định, trình tối ưu hóa sẽ chỉ xem xét các bảng 4 tại một thời điểm.
    • Điều này có nghĩa là trong các phép nối có hơn 4 bảng, nó có cơ hội tốt để chọn một gói truy vấn không tối ưu
  • Chia tay tham gia
    • Bạn có thể chia tay tham gia?
    • Chọn trước khóa ngoại vào bảng tạm thời
    • Thực hiện một nửa tham gia và đặt kết quả vào một bảng tạm thời
  • Bạn đang sử dụng đúng loại bảng tạm thời?
    • #tempcác bảng có thể thực hiện tốt hơn nhiều so với @tablecác biến có khối lượng lớn (hàng nghìn hàng).
  • Duy trì bảng tóm tắt
    • Xây dựng với các kích hoạt trên các bảng bên dưới
    • Xây dựng hàng ngày / hàng giờ / vv
    • Xây dựng đặc biệt
    • Xây dựng gia tăng hoặc phá vỡ / xây dựng lại
  • Xem kế hoạch truy vấn là gì với SET SHOWPLAN ON
  • Xem những gì thực sự xảy ra với SET STATS IO ON
  • Buộc một chỉ mục bằng cách sử dụng pragma: (index: myindex)
  • Buộc thứ tự bảng bằng cách sử dụng SET FORCEPlan ON
  • Thông số đánh hơi:
    • Phá vỡ thủ tục lưu trữ thành 2
    • gọi Proc2 từ Proc1
    • cho phép trình tối ưu hóa chọn chỉ mục trong Proc2 nếu @parameter bị thay đổi bởi Proc1
  • Bạn có thể cải thiện phần cứng của bạn?
  • Mấy giờ bạn chạy Có một thời gian yên tĩnh hơn?
  • Máy chủ nhân rộng (hoặc quá trình không dừng khác) đang chạy? Bạn có thể đình chỉ nó? Chạy nó, ví dụ. hàng giờ?

2
bạn đang giới thiệu đến bit nào?
AJ.

2
Đây là một số nội dung thú vị, nhưng tôi muốn bạn có một số tài liệu tham khảo cho một số yêu cầu. Ví dụ: Tôi chưa bao giờ nghe thấy việc tối ưu hóa chỉ xem xét 4 bảng một lần trong một lần tham gia. Tôi không hiểu làm thế nào điều này có thể đúng. Bạn có thể cung cấp một số tài liệu tham khảo cho cụ thể? Tôi muốn thấy nơi bạn đang nhận được điều này.
SheldonH

19
  1. Có một ý tưởng khá hay về con đường tối ưu để chạy truy vấn trong đầu bạn.
  2. Kiểm tra kế hoạch truy vấn - luôn luôn.
  3. Bật STATS, để bạn có thể kiểm tra cả hiệu suất IO và CPU. Tập trung vào việc giảm những con số đó xuống, không nhất thiết là thời gian truy vấn (vì điều đó có thể bị ảnh hưởng bởi hoạt động khác, bộ đệm, v.v.).
  4. Tìm kiếm số lượng lớn các hàng sắp vào một toán tử, nhưng số lượng nhỏ xuất hiện. Thông thường, một chỉ mục sẽ giúp bằng cách giới hạn số lượng hàng đến (giúp lưu đĩa đọc).
  5. Tập trung vào cây con chi phí lớn nhất đầu tiên. Thay đổi cây con đó thường có thể thay đổi toàn bộ kế hoạch truy vấn.
  6. Các vấn đề phổ biến tôi từng thấy là:
    • Nếu có nhiều liên kết, đôi khi Sql Server sẽ chọn mở rộng các liên kết, sau đó áp dụng các mệnh đề WHERE. Bạn thường có thể sửa lỗi này bằng cách di chuyển các điều kiện WHERE vào mệnh đề THAM GIA hoặc bảng dẫn xuất với các điều kiện được nội tuyến. Lượt xem có thể gây ra vấn đề tương tự.
    • Tham gia dưới mức tối ưu (LOOP vs HASH vs MERGE). Nguyên tắc nhỏ của tôi là sử dụng phép nối LOOP khi hàng trên cùng có rất ít hàng so với đáy, MERGE khi các bộ gần bằng nhau và được đặt hàng, và HASH cho mọi thứ khác. Thêm một gợi ý tham gia sẽ cho phép bạn kiểm tra lý thuyết của bạn.
    • Thông số đánh hơi. Nếu bạn đã chạy Proc được lưu trữ với các giá trị không thực tế lúc đầu (giả sử để kiểm tra), thì kế hoạch truy vấn được lưu trong bộ nhớ cache có thể là tối ưu cho các giá trị sản xuất của bạn. Chạy lại với RECOMPILE nên xác minh điều này. Đối với một số procs được lưu trữ, đặc biệt là các procs có phạm vi kích thước khác nhau (giả sử, tất cả các ngày từ hôm nay đến hôm qua - sẽ kéo theo INDEX XEMK - hoặc, tất cả các ngày giữa năm ngoái và năm nay - sẽ tốt hơn với INDEX SCAN ) bạn có thể phải chạy nó với RECOMPILE mỗi lần.
    • Sự thụt lề xấu ... Được rồi, vì vậy Sql Server không có vấn đề gì với điều này - nhưng tôi chắc chắn rằng không thể hiểu được một truy vấn cho đến khi tôi sửa lỗi định dạng.

1
+1 để bao gồm thụt đầu dòng xấu. Định dạng là chìa khóa! :)
mwigdahl

18

Hơi lạc đề nhưng nếu bạn có quyền kiểm soát những vấn đề này ...
Mức độ cao và Tác động cao.

  • Đối với môi trường IO cao, đảm bảo các đĩa của bạn dành cho RAID 10 hoặc RAID 0 + 1 hoặc một số triển khai lồng nhau của đột kích 1 và đột kích 0.
  • Đừng sử dụng ổ đĩa dưới 1500K.
  • Hãy chắc chắn rằng đĩa của bạn chỉ được sử dụng cho Cơ sở dữ liệu của bạn. IE không đăng nhập không có hệ điều hành.
  • Tắt tự động phát triển hoặc tính năng tương tự. Hãy để cơ sở dữ liệu sử dụng tất cả lưu trữ được dự đoán. Không nhất thiết là những gì hiện đang được sử dụng.
  • thiết kế lược đồ và chỉ mục của bạn cho các truy vấn loại.
  • nếu đó là bảng loại nhật ký (chỉ chèn) và phải trong DB thì không lập chỉ mục.
  • nếu việc phân bổ báo cáo của bạn (chọn phức tạp với nhiều phép nối) thì bạn nên xem xét việc tạo kho dữ liệu với lược đồ hình ngôi sao hoặc bông tuyết.
  • Đừng sợ sao chép dữ liệu để đổi lấy hiệu suất!

8

CREATE INDEX

Đảm bảo có các chỉ mục có sẵn cho bạn WHEREJOINcác mệnh đề. Điều này sẽ tăng tốc độ truy cập dữ liệu rất nhiều.

Nếu môi trường của bạn là một trung tâm dữ liệu hoặc kho, các chỉ mục sẽ có rất nhiều cho hầu hết mọi truy vấn có thể hiểu được.

Trong môi trường giao dịch , số lượng chỉ mục nên thấp hơn và định nghĩa của chúng mang tính chiến lược hơn để bảo trì chỉ mục không làm giảm tài nguyên. (Bảo trì chỉ mục là khi các lá của chỉ mục phải được thay đổi để phản ánh sự thay đổi trong bảng bên dưới, như với INSERT, UPDATE,DELETEhoạt động.)

Ngoài ra, hãy chú ý đến thứ tự của các trường trong chỉ mục - trường càng chọn lọc (cardinality càng cao), thì càng sớm trong chỉ mục sẽ xuất hiện. Ví dụ: giả sử bạn đang truy vấn ô tô đã sử dụng:

SELECT   i.make, i.model, i.price
FROM     dbo.inventory i
WHERE    i.color = 'red'
  AND    i.price BETWEEN 15000 AND 18000

Giá thường có cardinality cao hơn. Có thể chỉ có vài chục màu có sẵn, nhưng có thể có hàng ngàn mức giá khác nhau.

Trong số các lựa chọn chỉ mục này, idx01cung cấp đường dẫn nhanh hơn để đáp ứng truy vấn:

CREATE INDEX idx01 ON dbo.inventory (price, color)
CREATE INDEX idx02 ON dbo.inventory (color, price)

Điều này là do ít xe hơn sẽ thỏa mãn điểm giá hơn so với lựa chọn màu sắc, giúp công cụ truy vấn ít dữ liệu hơn để phân tích.

Tôi được biết là có hai chỉ mục rất giống nhau chỉ khác nhau theo thứ tự trường để tăng tốc độ truy vấn (tên, họ) trong một và (họ, tên) trong cái kia.


6

Một mẹo tôi mới học được là SQL Server có thể cập nhật các biến cục bộ cũng như các trường, trong một câu lệnh cập nhật.

UPDATE table
SET @variable = column = @variable + otherColumn

Hoặc phiên bản dễ đọc hơn:

UPDATE table
SET
    @variable = @variable + otherColumn,
    column = @variable

Tôi đã sử dụng điều này để thay thế các con trỏ / phép nối phức tạp khi thực hiện các phép tính đệ quy và cũng đạt được rất nhiều hiệu suất.

Dưới đây là chi tiết và mã ví dụ đã tạo ra những cải tiến tuyệt vời về hiệu suất: http://geekswithbloss.net/Rhames/archive/2008/10/28/calculating-ricky-totals-in-sql-server-2005---the-optimal. aspx


5

Giả sử MySQL ở đây, sử dụng GIẢI THÍCH để tìm hiểu những gì đang xảy ra với truy vấn, đảm bảo rằng các chỉ mục đang được sử dụng hiệu quả nhất có thể và cố gắng loại bỏ các loại tệp. MySQL hiệu suất cao: Tối ưu hóa, sao lưu, sao chép và nhiều hơn nữa là một cuốn sách tuyệt vời về chủ đề này cũng như Blog hiệu suất MySQL .


3
Điều đó tốt cho MySQL, nhưng câu hỏi được gắn thẻ "sqlserver". Tuy nhiên, đó là một điều tốt để làm điều đó. Điều tương tự cần làm trong SSMS là sử dụng "Kế hoạch thực hiện ước tính hiển thị" và "Bao gồm kế hoạch thực hiện thực tế". Nếu bạn có thể loại bỏ các lần quét bảng khổng lồ và sử dụng các tìm kiếm chỉ mục theo cụm, thì bạn đang trên đường đến hiệu suất tối ưu.
eksortso

5

@Terrapin có một vài điểm khác biệt giữa isnull và coalesce đáng được đề cập (bên cạnh việc tuân thủ ANSI, đây là một điểm lớn đối với tôi).

Hợp nhất với IsNull


3

Đôi khi trong SQL Server nếu bạn sử dụng OR trong mệnh đề where, nó sẽ thực sự kết hợp với hiệu suất. Thay vì sử dụng HOẶC chỉ cần thực hiện hai lựa chọn và liên kết chúng lại với nhau. Bạn nhận được kết quả tương tự với tốc độ 1000 lần.


Tôi đã thấy hành vi không giải thích được này.
Esen

2

Nhìn vào mệnh đề where - xác minh việc sử dụng chỉ mục / xác minh không có gì ngớ ngẩn đang được thực hiện

where SomeComplicatedFunctionOf(table.Column) = @param --silly

2

Nói chung, tôi sẽ bắt đầu với các liên kết - Tôi sẽ loại từng đối tượng ra khỏi truy vấn một lần và chạy lại truy vấn để có ý tưởng nếu có một tham gia cụ thể nào đó tôi gặp vấn đề.


2

Trên tất cả các bảng tạm thời của tôi, tôi muốn thêm các ràng buộc duy nhất (khi thích hợp) để tạo các chỉ mục và các khóa chính (hầu như luôn luôn).

declare @temp table(
    RowID int not null identity(1,1) primary key,
    SomeUniqueColumn varchar(25) not null,
    SomeNotUniqueColumn varchar(50) null,
    unique(SomeUniqueColumn)
)

2

Tôi đã tạo thói quen luôn sử dụng các biến ràng buộc. Các biến liên kết có thể không giúp được nếu RDBMS không lưu các câu lệnh SQL. Nhưng nếu bạn không sử dụng các biến liên kết, RDBMS không có cơ hội sử dụng lại các kế hoạch thực hiện truy vấn và các câu lệnh SQL được phân tích cú pháp. Khoản tiết kiệm có thể rất lớn: http://www.akadia.com/service/ora_bind_variables.html . Tôi làm việc chủ yếu với Oracle, nhưng Microsoft SQL Server hoạt động khá giống nhau.

Theo kinh nghiệm của tôi, nếu bạn không biết liệu bạn có đang sử dụng biến liên kết hay không, thì có lẽ bạn không biết. Nếu ngôn ngữ ứng dụng của bạn không hỗ trợ chúng, hãy tìm ngôn ngữ đó. Đôi khi bạn có thể sửa truy vấn A bằng cách sử dụng các biến liên kết cho truy vấn B.

Sau đó, tôi nói chuyện với DBA của chúng tôi để tìm hiểu điều gì khiến RDBMS đau đớn nhất. Lưu ý rằng bạn không nên hỏi "Tại sao truy vấn này chậm?" Điều đó giống như yêu cầu bác sĩ của bạn lấy ra phụ lục của bạn. Chắc chắn truy vấn của bạn có thể là vấn đề, nhưng cũng có khả năng là có điều gì đó khác đang xảy ra. Là nhà phát triển, chúng tôi có xu hướng suy nghĩ về các dòng mã. Nếu một dòng chậm, sửa dòng đó. Nhưng RDBMS là một hệ thống thực sự phức tạp và truy vấn chậm của bạn có thể là triệu chứng của một vấn đề lớn hơn nhiều.

Cách quá nhiều mẹo điều chỉnh SQL là thần tượng sùng bái hàng hóa. Hầu hết thời gian vấn đề không liên quan hoặc liên quan tối thiểu đến cú pháp bạn sử dụng, do đó, tốt nhất là sử dụng cú pháp sạch nhất bạn có thể. Sau đó, bạn có thể bắt đầu xem xét các cách để điều chỉnh cơ sở dữ liệu (không phải truy vấn). Chỉ chỉnh cú pháp khi thất bại.

Giống như bất kỳ điều chỉnh hiệu suất, luôn luôn thu thập số liệu thống kê có ý nghĩa. Không sử dụng thời gian wallclock trừ khi đó là trải nghiệm người dùng bạn đang điều chỉnh. Thay vào đó, hãy nhìn vào những thứ như thời gian của CPU, các hàng được tìm nạp và các khối đọc ra khỏi đĩa. Quá thường xuyên mọi người tối ưu hóa cho những điều sai trái.


2

Bước đầu tiên: Nhìn vào Kế hoạch thực hiện truy vấn!
TableScan -> xấu
NestedLoop -> meh cảnh báo
TableScan đằng sau NestedLoop -> DOOM!

THIẾT LẬP THỐNG KÊ IO TRÊN
THỐNG KÊ THỜI GIAN TRÊN


2

Chạy truy vấn bằng cách sử dụng VỚI (NoLock) là hoạt động tiêu chuẩn khá nhiều ở vị trí của tôi. Bất cứ ai cũng bắt gặp các truy vấn đang chạy trên các bảng hàng chục gigabyte mà không được lấy ra và bắn.


2
Điều này nên được sử dụng thận trọng, không theo thói quen. Khóa không phải là xấu, chỉ là hiểu lầm.

2

Chuyển đổi các truy vấn KHÔNG IN thành TRÁI PHIẾU TRÊN NỀN TẢNG nếu có thể. Ví dụ: nếu bạn muốn tìm tất cả các hàng trong Bảng 1 không được sử dụng bởi khóa ngoại trong Bảng 2, bạn có thể thực hiện việc này:

SELECT *
FROM Table1
WHERE Table1.ID NOT IN (
    SELECT Table1ID
    FROM Table2)

Nhưng bạn có được hiệu suất tốt hơn với điều này:

SELECT Table1.*
FROM Table1
LEFT OUTER JOIN Table2 ON Table1.ID = Table2.Table1ID
WHERE Table2.ID is null

1

@ DavidM

Giả sử MySQL ở đây, sử dụng GIẢI THÍCH để tìm hiểu điều gì đang xảy ra với truy vấn, đảm bảo rằng các chỉ mục đang được sử dụng hiệu quả nhất có thể ...

Trong SQL Server, kế hoạch thực hiện giúp bạn có được điều tương tự - nó cho bạn biết các chỉ mục nào đang bị tấn công, v.v.


1

Lập chỉ mục (các) bảng theo clm (s) bạn lọc theo


1

Không nhất thiết là một thủ thuật hiệu năng SQL mỗi se nhưng chắc chắn có liên quan:

Một ý tưởng tốt sẽ là sử dụng memcached nếu có thể vì nó sẽ nhanh hơn nhiều khi chỉ lấy dữ liệu được biên dịch trực tiếp từ bộ nhớ thay vì lấy từ cơ sở dữ liệu. Ngoài ra còn có một hương vị của MySQL được tích hợp sẵn (bên thứ ba).


1

Hãy chắc chắn rằng độ dài chỉ mục của bạn càng nhỏ càng tốt. Điều này cho phép DB đọc nhiều khóa cùng một lúc từ hệ thống tệp, do đó tăng tốc độ tham gia của bạn. Tôi giả sử điều này hoạt động với tất cả các DB, nhưng tôi biết đó là một khuyến nghị cụ thể cho MySQL.


1

Tôi tìm kiếm:

  • Hủy đăng ký bất kỳ vòng lặp HIỆN TẠI và chuyển đổi thành các câu lệnh UPDATE / INSERT dựa trên tập hợp.
  • Xem ra bất kỳ mã ứng dụng nào:
    • Gọi một SP trả về một tập hợp lớn các bản ghi,
    • Sau đó, trong ứng dụng, đi qua từng bản ghi và gọi một SP với các tham số để cập nhật các bản ghi.
    • Chuyển đổi nó thành SP thực hiện tất cả công việc trong một giao dịch.
  • Bất kỳ SP nào thực hiện nhiều thao tác chuỗi. Đó là bằng chứng cho thấy dữ liệu không được cấu trúc chính xác / chuẩn hóa.
  • Bất kỳ SP nào phát minh lại bánh xe.
  • Bất kỳ SP nào tôi không thể hiểu những gì nó đang cố gắng thực hiện trong vòng một phút!

1
SET NOCOUNT ON

Thường là dòng đầu tiên bên trong các thủ tục được lưu trữ của tôi, trừ khi tôi thực sự cần sử dụng @@ROWCOUNT.


2
@@ ROWCOUNT được đặt dù sao đi nữa. NOCOUNT vô hiệu hóa các câu lệnh "xx hàng bị ảnh hưởng".
Sklivvz

Điều này thực sự bao giờ làm cho một sự khác biệt đáng kể trong hiệu suất?
JohnFx

Vâng, sau đó số đếm không tự động được tính mỗi khi câu lệnh SQL được chạy. Thật dễ dàng để chuẩn bị một truy vấn có và không cần phải thấy rằng nó có sự khác biệt.
ngày

Số lượng được theo dõi trong SQL Server nào. Bất kỳ sự khác biệt hiệu suất mà bạn thấy là bởi vì số lượng phải đi qua mạng đến mặt trước của bạn. Nếu bạn đang thực hiện một CHỌN duy nhất, nó sẽ không tạo ra sự khác biệt đáng kể. Nếu bạn có một vòng lặp với 100000 lần chèn thì sẽ có thêm rất nhiều trên mạng.
Tom H

1

Trong SQL Server, sử dụng lệnh nolock. Nó cho phép lệnh select hoàn thành mà không phải chờ đợi - thường là các giao dịch khác kết thúc.

SELECT * FROM Orders (nolock) where UserName = 'momma'

3
NOLOCK chỉ dành cho các truy vấn mà bạn không quan tâm đến kết quả chính xác
Mark Sowul

1

Hủy bỏ con trỏ bất cứ nơi nào không cần thiết.


Vâng, con trỏ là một lời nguyền! ;)
Sklivvz

8
Ừ Đừng ném nó ra không đủ tiêu chuẩn như thế. Con trỏ giống như súng. Bản thân họ không xấu, chỉ là mọi người làm những điều thực sự tồi tệ với họ.
JohnFx

1

Xóa các lệnh gọi hàm trong Sprocs trong đó rất nhiều hàng sẽ gọi hàm.

Đồng nghiệp của tôi đã sử dụng các cuộc gọi chức năng (lấy ví dụ cuối cùng từ userid làm ví dụ) để trả về các bản ghi rất rộng.

Được giao nhiệm vụ tối ưu hóa, tôi đã thay thế các lệnh gọi hàm trong sproc bằng mã của hàm: Tôi nhận được nhiều thời gian chạy của sprocs từ> 20 giây xuống <1.


0
  • Tiền tố tất cả các bảng với dbo. để ngăn chặn tái chế.
  • Xem kế hoạch truy vấn và săn tìm quét bảng / chỉ mục.
  • Trong năm 2005, quét các quan điểm quản lý cho các chỉ mục bị thiếu.


0

Không đặt tiền tố Tên thủ tục được lưu với "sp_" vì tất cả các thủ tục hệ thống bắt đầu bằng "sp_" và SQL Server sẽ phải tìm kiếm nhiều hơn để tìm thủ tục của bạn khi được gọi.


1
Bạn đã thực sự điểm chuẩn này? Nếu SQL Server đang làm những gì hợp lý (sử dụng thuật toán băm để định vị Proc được lưu trữ), thì điều này sẽ không có gì khác biệt. Trong thực tế nếu SQL Server không làm điều đó, có vẻ như hiệu năng hệ thống sẽ bốc mùi (vì có lẽ nó gọi là procs của chính nó).
John Stauffer

1
Tôi nghĩ rằng điều này rơi vào xô tối ưu hóa sớm. Có lẽ đây là một cách tốt để tránh nhầm lẫn cho mọi người, nhưng là một mẹo tối ưu hóa ... D-
JohnFx

0

Đọc bẩn -

set transaction isolation level read uncommitted

Ngăn chặn các khóa chết trong đó tính toàn vẹn giao dịch không thực sự cần thiết (thường là đúng)


1
Có, nhưng điều này có thể dẫn đến các lỗi kỳ lạ RẤT khó tìm.
Grant Johnson

0

Tôi luôn đi đến SQL Profiler (nếu đó là một thủ tục được lưu trữ với nhiều mức lồng nhau) hoặc trình lập kế hoạch thực hiện truy vấn (nếu đó là một vài câu lệnh SQL không có lồng nhau) trước tiên. 90% thời gian bạn có thể tìm thấy sự cố ngay lập tức với một trong hai công cụ này.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.