Có tốt hơn khi sử dụng thủ tục lưu sẵn hoặc thực hiện theo cách cũ với chuỗi kết nối và tất cả những thứ tốt đó? Hệ thống của chúng tôi đã chạy chậm gần đây và người quản lý của chúng tôi muốn chúng tôi thử xem chúng tôi có thể tăng tốc độ một chút và chúng tôi đang nghĩ đến việc thay đổi một số lệnh gọi cơ sở dữ liệu cũ sang các thủ tục được lưu trữ. Nó có đáng không?Có hiệu suất chính đạt được bằng cách sử dụng các thủ tục được lưu trữ không?
Việc đầu tiên cần làm là kiểm tra cơ sở dữ liệu có tất cả các chỉ mục cần thiết được thiết lập. Phân tích mã của bạn ở đâu chậm và kiểm tra các câu lệnh SQL liên quan và các chỉ mục liên quan đến chúng. Xem bạn có thể viết lại câu lệnh SQL để có hiệu quả hơn không. Kiểm tra xem bạn không biên dịch lại câu lệnh SQL (đã chuẩn bị) cho mỗi lần lặp trong một vòng lặp thay vì ngoài vòng lặp một lần.
Di chuyển một câu lệnh SQL vào một thủ tục được lưu trữ sẽ không giúp ích gì nếu nó không hiệu quả về triển khai thực hiện. Tuy nhiên, cơ sở dữ liệu sẽ biết cách tối ưu hóa tốt nhất SQL và nó sẽ không cần phải lặp đi lặp lại nó nhiều lần. Nó cũng có thể làm cho mã phía máy khách sạch hơn bằng cách chuyển một câu lệnh SQL phức tạp thành một lời gọi thủ tục đơn giản.
Miễn là cuộc gọi của bạn nhất quán, cơ sở dữ liệu sẽ lưu trữ gói thực thi (MS SQL anyway). Lý do mạnh nhất còn lại để sử dụng các thủ tục lưu sẵn là để quản lý bảo mật dễ dàng và chắc chắn.
Nếu tôi là bạn, trước tiên tôi sẽ tìm kiếm thêm chỉ số nếu cần. Ngoài ra, hãy chạy công cụ lược tả hồ sơ để kiểm tra những gì đang mất nhiều thời gian và nếu cần thay đổi sql đó, ví dụ: thêm nhiều hơn ở đâu Điều khoản hoặc giới hạn tập kết quả.
Bạn nên xem xét lưu vào bộ nhớ cache nơi bạn có thể.
Đã bỏ phiếu cho việc bolding các từ khóa quan trọng. Nice liên lạc. :) –
Bạn không bao giờ có thể nói trước. Bạn phải làm điều đó và đo lường sự khác biệt bởi vì trong 9 trong 10 trường hợp, nút cổ chai không phải là nơi bạn nghĩ.
Nếu bạn sử dụng quy trình được lưu trữ, bạn không phải truyền dữ liệu. DB thường chậm khi thực hiện [EDIT] [EDIT] phức tạp [EDIT] phức tạp với các vòng lặp, toán cao hơn, vv [/ EDIT]. Vì vậy, nó thực sự phụ thuộc vào bao nhiêu công việc bạn sẽ cần phải làm, làm thế nào làm chậm mạng của bạn, làm thế nào nhanh chóng DB thực thi mã đặc biệt này, vv
Tôi sẽ xem nhanh Stored Procedures are EVIL.
Tôi ước tôi có thể thêm 10 điểm vào liên kết này. Mô tả chính xác suy nghĩ của tôi về lưu trữ logic trong lớp cơ sở dữ liệu. –
Tôi ước bạn cũng có thể! =) – mattruma
Tuy nhiên, tôi phải ngoại trừ một trong những điểm của tác giả. Nó không ảnh hưởng đến kết luận cuối cùng, nhưng tuyên bố của ông rằng "không có gì bạn có thể làm trong SQL bạn cũng không thể làm trong mã ứng dụng" cho thấy một sự thiếu hiểu biết chung về logic dựa trên thiết lập và hiệu quả của nó. – GalacticCowboy
Quy trình đã lưu sẽ không làm mọi thứ nhanh hơn.
Tuy nhiên, sắp xếp lại logic của bạn sẽ có tác động rất lớn. Các giao dịch gọn gàng, tập trung mà bạn thiết kế khi suy nghĩ về các thủ tục lưu trữ là cực kỳ có lợi.
Ngoài ra, các thủ tục được lưu trữ có xu hướng sử dụng các biến liên kết, trong đó các ngôn ngữ lập trình khác đôi khi dựa vào việc xây dựng các câu lệnh SQL một cách nhanh chóng. Một bộ cố định nhỏ, các câu lệnh SQL và các biến liên kết rất nhanh. Các câu lệnh SQL động chậm.
Ứng dụng "chạy chậm gần đây" không cần thay đổi mã hóa.
Đo lường. Đo. Đo. "chậm" không có nghĩa nhiều khi nói đến điều chỉnh hiệu suất. Cái gì chậm? Giao dịch chính xác nào chậm? Bảng nào chậm? Tiêu điểm.
Kiểm soát tất cả thay đổi. Tất cả các. Những gì đã thay đổi? OS vá? RDBMS thay đổi? Thay đổi ứng dụng? Một cái gì đó thay đổi để làm chậm những thứ xuống.
Kiểm tra các hạn chế về quy mô. Bảng có chậm lại vì 80% dữ liệu là lịch sử mà bạn sử dụng để báo cáo mỗi năm một lần không?
thủ tục lưu trữ là không bao giờ là giải pháp cho vấn đề hiệu suất cho đến khi bạn hoàn toàn có thể trỏ đến một khối cụ thể của mã mà là provably nhanh như một thủ tục lưu trữ.
Lý do chính tại sao chúng tôi chạy chậm là vì chúng tôi đang ở trong mùa bận rộn của chúng tôi nhưng nó đang chạy chậm hơn so với trước đây (ngay cả trong mùa bận rộn trước đó). Do đó, chúng tôi đang cố gắng hết sức để tăng tốc độ một chút. Cảm ơn –
"chậm hơn trước" là bắt đầu, nhưng nó khá rộng. Bước tiếp theo là tập trung vào một bảng cụ thể, giao dịch, thủ tục, thủ tục, công việc hoặc nhiệm vụ. Không tập trung, bạn không thể chứng minh rằng sự thay đổi của bạn đối với SP có tác động tích cực. –
Chúng tôi nghĩ rằng đó là bảng công việc của chúng tôi và các bảng liên quan của nó bởi vì đó là một trong đó là nhận được gọi là thời gian này nhất trong năm để đó là những gì chúng ta sẽ tập trung vào. –
Có, procs được lưu trữ là một bước tiến tới việc đạt được hiệu suất tốt. Lý do chính là các thủ tục được lưu trữ có thể được biên dịch trước và kế hoạch thực thi của chúng được lưu trữ.
Tuy nhiên, trước tiên bạn cần phải phân tích nơi xảy ra hiện tượng tắc nghẽn hiệu suất của mình - để bạn tiếp cận bài tập này theo cách có cấu trúc.
Vì nó đã được đề xuất trong một trong các câu trả lời, hãy thử phân tích bằng cách sử dụng công cụ profiler nơi mà vấn đề là - ví dụ như bạn cần để tạo chỉ mục ...
Cheers
RDBMSes hiện đại nhất sẽ biên dịch trước và lập kế hoạch thực hiện bộ nhớ cache cho các câu lệnh đã chuẩn bị. –
Nếu máy chủ của bạn là nhận được chậm hơn đáng kể trong mùa bận rộn của bạn nó có thể là do bão hòa hơn là bất cứ điều gì không hiệu quả trong cơ sở dữ liệu. Basic queuing theory cho chúng ta biết rằng một máy chủ bị chậm hơn về mặt hyperbol khi nó tiếp cận bão hòa.
Mối quan hệ cơ bản là 1/(1-X) trong đó X là tỷ lệ tải. Điều này mô tả độ dài hàng đợi trung bình hoặc thời gian chờ đợi trước khi được phân phối. Do đó một máy chủ đang nhận được bão hòa sẽ làm chậm rất nhanh khi tải đột biến.
Máy chủ được tải 25% sẽ có thời gian dịch vụ trung bình là 1.333K đối với một số K không đổi (lỏng lẻo, K là thời gian cho máy thực hiện một giao dịch). Máy chủ được tải 50% sẽ có thời gian dịch vụ trung bình là 2K và máy chủ tải 90% sẽ có thời gian dịch vụ trung bình là 10K. Cho rằng sự chậm lại là hyperbolic trong tự nhiên, nó thường không mất một sự thay đổi lớn trong tải tổng thể để tạo ra một sự suy thoái đáng kể trong thời gian đáp ứng.
Rõ ràng điều này hơi đơn giản vì máy chủ sẽ xử lý nhiều yêu cầu đồng thời (có nhiều mô hình xếp hàng phức tạp hơn cho tình huống này), nhưng nguyên tắc chung vẫn được áp dụng.
Vì vậy, nếu máy chủ của bạn đang gặp phải các tải tạm thời đang bão hòa, bạn sẽ gặp phải các bản vá có tốc độ chậm đáng chú ý. Lưu ý rằng những sự chậm lại này chỉ cần ở một khu vực bị tắc nghẽn của hệ thống để làm chậm toàn bộ quá trình. Nếu bạn chỉ trải qua điều này ngay bây giờ trong một mùa bận rộn, có khả năng máy chủ của bạn chỉ đơn giản là nhấn một ràng buộc vào một tài nguyên, thay vì đặc biệt chậm hoặc không hiệu quả.
Lưu ý rằng khả năng này không phản đối khả năng thiếu hiệu quả trong mã. Bạn có thể thấy rằng cách để giảm bớt tắc nghẽn là điều chỉnh một số truy vấn của bạn.
Để biết liệu hệ thống có bị tắc nghẽn hay không, hãy bắt đầu thu thập thông tin hồ sơ. Nếu bạn có thể tìm thấy tài nguyên với số lượng chờ đợi lớn, điều này sẽ cho bạn một điểm khởi đầu tốt.
Khả năng cuối cùng là bạn cần phải nâng cấp máy chủ của mình. Nếu không có sự thiếu hiệu quả lớn trong mã (điều này cũng có thể là trường hợp nếu hồ sơ không chỉ ra bất kỳ tắc nghẽn lớn không cân xứng nào), bạn có thể chỉ cần phần cứng lớn hơn.Tôi không biết khối lượng của bạn là bao nhiêu, nhưng không giảm thiểu khả năng bạn có thể phát triển máy chủ của mình.
thủ tục lưu trữ có thể thực sự hữu ích nếu họ tránh gửi lượng dữ liệu khổng lồ và/hoặc tránh thực hiện các chuyến đi đến máy chủ, vì vậy chúng có thể có giá trị nếu ứng dụng của bạn gặp một trong những vấn đề này.
Sau khi bạn hoàn thành nghiên cứu, bạn sẽ nhận ra có hai quan điểm cực đoan ở phía đối diện của quang phổ. Trong lịch sử cộng đồng Java đã chống lại procs cửa hàng do sự sẵn có của khung như ngủ đông, ngược lại cộng đồng .NET đã sử dụng nhiều procs được lưu trữ và di sản này đi xa như vb5/6 ngày. Đặt tất cả thông tin này trong bối cảnh và tránh xa những ý kiến cực đoan ở hai bên của đồng xu.
Tốc độ không nên là yếu tố chính để quyết định hoặc ủng hộ các procs được lưu trữ. Bạn có thể đạt được hiệu suất sp bằng cách sử dụng SQL nội tuyến với khung ngủ đông và các khung công tác khác. Xem xét việc bảo trì và các chương trình khác như báo cáo, tập lệnh có thể sử dụng cùng một procs được lưu trữ được ứng dụng của bạn sử dụng. Nếu kịch bản của bạn yêu cầu nhiều người tiêu dùng cho cùng một mã SQL, các thủ tục lưu trữ là một ứng cử viên tốt, việc bảo trì sẽ dễ dàng hơn. Nếu đây không phải là trường hợp, và bạn quyết định sử dụng nội tuyến sql, hãy xem xét bên ngoài nó trong tập tin cấu hình để tạo điều kiện bảo trì.
Vào cuối ngày, điều được tính là điều sẽ làm cho kịch bản cụ thể của bạn thành công cho các bên liên quan của bạn.
Giống như tất cả các bài viết trên đề nghị, trước hết bạn muốn dọn sạch các câu lệnh SQL của mình, có các chỉ mục thích hợp. bộ nhớ đệm có thể phức tạp, tôi không thể nhận xét trừ khi tôi có thêm chi tiết về những gì bạn đang cố gắng hoàn thành.
Nhưng có một điều về sprocs, chắc chắn rằng bạn không để cho nó tạo câu lệnh SQL động
bởi vì đối với một, nó sẽ là vô nghĩa và nó có thể phải chịu SQL Injection tấn công ... Đây có đã xảy ra ở một trong những dự án mà tôi đã xem xét.
Tôi khuyên bạn nên sử dụng sprocs để cập nhật chủ yếu, sau đó chọn câu lệnh. chúc may mắn :)
"làm theo cách cũ với chuỗi kết nối" Sử dụng sql động hoặc các thủ tục được lưu trữ đều yêu cầu bạn sử dụng chuỗi kết nối! – fretje
câu trả lời ngắn: không – BlackTigerX