Một số điều một lập trình viên phải biết về SQL sever

6. SQL functions thường hiếm khi có hiệu năng tốt

If you do want to reuse code, consider stored procedures and views instead. (Granted, they can come with their own performance drawbacks, but I’m just trying to get you started on the right foot as quickly as possible here, and functions are a broken foot.) Lập trình viên thường muốn tái sử dụng mã code bằng việc đặt nó trong các hàm, và gọi hàm từ nhiều nơi khác nhau. Đó là một phương án tuyệt vời trong các lớp ứng dụng, nhưng đó là một hạn chế rất lớn về hiệu năng trong tầng cơ sở dữ liệu. Nếu bạn muốn tái sử dụng mã code, thì có thể xem xét về stored procedures hoặc lưu tại views thay thế. Chúng có thể tồn tại một số hạn chế khác nhau về hiệu năng, nhưng mình nghĩ bạn đã bắt đầu có một hướng đi đúng với nó và hãy xem việc tái sử dụng việc gọi các hàm là một phương án tồi

5. “WITH (NOLOCK)” không có nghĩa là no lock

Ở điểm này, bạn đang bắt đầu sử dụng With (NOLOCK) ở khắp nơi bởi vì nó đưa lại cho bạn kết quả câu truy vấn nhanh hơn. Đó không hẵn là một ý tồi, nhưng nó có thể đưa đến một số tác dụng phụ mà chúng ta không biết. Đấy là điều bài viết đang tập trung ở đây. Khi bạn truy vấn 1 bảng ghi - mặc dù đang dùng WITH(NOLOCK)- bạn đưa ra một khóa schema cố định. Không ai có thể thay đổi bảng ghi hoặc index cho tới khi truy vấn của bạn hoàn tất. Điều này trông khá đơn giản và không có gì nguy cơ cho đến khi bạn cần hủy một record.v.v, nhưng bạn không thể bởi vì mọi người đang liên tục truy vấn vào bảng ghi và họ cũng nghĩ rằng không có gì ảnh hưởng khi họ đang sữ dụng WITH(NOLOCK) =)) Nó không phải là viên đạn bạc, nhưng nếu bắt đầu nghiên cứu về giải pháp trong SQL thì tôi tin chắc READ COMMITTED SNAPSHOT ISOLATION là một giải pháp tốt hơn cho ứng dụng của bạn. Nó cho phép bạn lấy dữ liệu với việc hạn chế bị chặn.

4 Sử dụng 3 connection string trong ứng dụng

I know, you’ve only got one SQL Server today, but trust me, this is worth it. Set up three connection strings that all point to the same destination today, but down the road, when you need to scale, you’ll be able to set up different database servers to handle each of these:

Connection for Writes & Realtime Reads – this is the connection string you’re already using today, and you think that all data needs to come from here. You can leave all of your code in place, but as you write new code or touch existing pages, think about changing each query to one of the below connections. Connection for Data 5-15 Minutes Old – this is for data that can be slightly stale, but still needs to be from today. Connection for Data as of Yesterday – for management reports and trending data. If you run an online store, you might pull reviews from here, for example, and tell users that their reviews take a day to publish. That first connection string is the toughest one to scale; we don’t have a lot of options in SQL Server to scale out multiple servers that handle writes. (We do have options – they’re just painful to implement and manage.) The lower-tier connection strings 2 and 3 are much, much easier and cheaper to scale. For more about this technique, check out my 3 Favorite Connection String Tips. Tôi biết, bạn thường chỉ có một SQL sever hằng ngày, nhưng hãy tin tôi, nó có giá trị của nó. Thiết lập 3 connection string đến cùng một đích xuống các kênh khác nhau, và khi bạn cần scale, bạn sẽ có thể thiết lập database sever khác nhau cho mỗi line này như sau: Connection for Writes & Realtime Reads – đây là một kết nối đến cơ sở dữ liệu bạn đang sử dụng trong ngày, bạn có thể thấy tất cả dữ liệu bạn cần đến từ đây. Bạn có thể đặt tất cả mã code của mình tại đây, nhưng khi bạn viết một mã mới và nó thao tác với các trang hiện có, thì hãy nghĩ đến việc thay đổi câu querry đến một trong những connect dữ liệu dưới đây Connection for Data 5-15 Minutes Old – this is for data that can be slightly stale, but still needs to be from today. đây là những dữ liệu có thể cũ hơn nhưng vẫn cần phải thuộc ngày hôm nay. Ở đây bạn nên suy nghĩ về một số dữ liệu mà tính cập nhật không liên tục real-time, tần suất thay đổi khá trung bình Connection for Data as of Yesterday – for management reports and trending data. If you run an online store, you might pull reviews from here, for example, and tell users that their reviews take a day to publish. cho việc quản lí báo cáo, thu thập xu hướng dữ liệu. Nếu bạn chạy một của hàng online, bạn có thể kéo( lấy) các ý kiến, đánh giá từ người dùng tại đây- những đánh giá này của người dùng có thể cần check và cho publish trong vòng 24h sau khi check. That first connection string is the toughest one to scale; we don’t have a lot of options in SQL Server to scale out multiple servers that handle writes. (We do have options – they’re just painful to implement and manage.) The lower-tier connection strings 2 and 3 are much, much easier and cheaper to scale Connection string đầu tiên là cái khó nhất khi bạn muốn scale- thay đổi quy mô của sever, chúng ta không có quá nhiều sự lựa chọn trong việc scale SQL sever để đưa ra nhiều máy chủ để có thể xử lý việc đọc-ghi dữ liệu này. Chúng ta có các lựa chọn và thường rất đau đầu để quản lí và thực hiện điều đó. Các connect tần thấp hơn: 2 và 3 là rât nhiều và nó cũng dễ dàng và rẻ hơn để update quy mô lên.

3. Sử dụng các kịch bản cơ sở dữ liệu

Your app probably uses the database for some scratch work – processing, sorting, loading, caching, etc. It wouldn’t break your heart if this data disappeared, but you’d like to keep the table structures around permanently. Today, you’re doing this work in your main application database. Ứng dụng của bạn có thể sử dụng cơ sở dữ liệu cho một số công việc hàng đầu như: xử lý, sắp xếp , tải hay bộ nhớ đệm... Và nó cũng không làm bạn vỡ cả mật, rụng cả tim nếu các dữ liệu này biến mất, nhưng bạn muốn lưu trữ cấu trúc bảng ghi vĩnh viễn. Hôm nay, bạn đang làm cộng việc trong cơ sở dữ liệu chính của ứng dụng.

Tạo một cơ sở dữ liệu riêng biệt - gọi nó MyAppTemp - và làm công việc của bạn trong thay vào đấy. Đặt cơ sở dữ liệu này trong chế độ phục hồi đơn giản, và chỉ trở lại nó lên một lần mỗi ngày. Không rắc rối với tính sẵn sàng cao hoặc khắc phục thảm họa trên cơ sở dữ liệu này.

This technique accomplishes a lot of really cool scalability stuff. It minimizes the changes to the main app database, which means you get faster transaction log backups and differential backups for it. If you’re log shipping this database to a disaster recovery site, your important data will arrive faster – and not be impeded by all the scratch work. You can even use different storage for these different databases – perhaps cheap local SSD for MyAppTemp, keeping your shared storage connection free for the critical production stuff. Kỹ thuật này hoàn thành khá tốt trong việc mở rộng , nó giảm thiểu sự thay đổi cơ sở dự liệu ứng dụng chính, điều đó có nghĩa là bạn lấy được các sao lưu log nhanh hơn và tạo các backup riêng biệt cho nó. Nếu bạn đang đăng nhập và đưa dữ liệu đến một trang khắc phục sự cố, thì dữ liệu quan trọng của bạn sẽ được đưa đến nhanh hơn- mà nó không bị ngăn cản bởi các công việc trước đó. Bạn có thể sử dụng các kiểu lưu trữ dữ liệu khác nhau cho các cơ sở dữ liệu khác nhau - SSD local là phương án rẻ cho MyAppTemp, và bạn có thể chia sẻ lưu trữ dữ liệu miễn phí cho các sản phẩm quan trọng.

2 Kiến trúc, sách vở ngày hôm qua đã lạc hậu vào ngày hôm nay

SQL Sever đã được xây dựng hơn hàng thập kỉ qua, và có quá nhiều thay đổi trong thời gian đấy. Rất tiếc. những vật liệu cũ không được cập nhật để xử lý giải quyeert những gì xảy ra vào hiện tại. Thậm chí có những vật liệu từ các nguồn uy tín vẫn lỗi - có phê phán về Microsoft’s Performance Tuning SQL Server guide.v.v.

1. Tránh Order By và dùng sort thay thế

To sort your query results, SQL Server burns CPU time. SQL Server Enterprise Edition goes for about $7,000 per CPU core – not per processor, but per core. A two-socket, 6-core-each server rings up at around $84k – and that’s just the licensing costs, not the hardware costs. You can buy a heck of a lot of application servers (even ones with 256GB or more of memory) for $84k. Để sắp xếp kết quả truy vấn, SQL Server đốt cháy thời gian CPU. SQL Server Enterprise Edition đi khoảng 7.000 $ cho mỗi lõi CPU - không cho mỗi bộ vi xử lý, nhưng mỗi lõi. Một hai ổ cắm, 6-core-mỗi máy chủ nhân lên khoảng $ 84k - và đó chỉ là các chi phí cấp giấy phép, không phải là chi phí phần cứng. Bạn có thể mua một heck của rất nhiều máy chủ ứng dụng (ngay cả những người thân với 256GB hoặc nhiều bộ nhớ) cho $ 84k.

Tiêu thụ tất cả các kết quả truy vấn càng nhanh càng tốt vào bộ nhớ trong ứng dụng của bạn, và sau đó sắp xếp. Ứng dụng của bạn đã được thiết kế theo cách mà bạn có thể mở rộng ra nhiều máy chủ ứng dụng để phân phối tải CPU, trong khi máy chủ cơ sở dữ liệu của bạn ... không phải là.

UPDATE: I’ve gotten a lot of comments wailing about how the app only needs ten rows of a ten million row dataset. Sure, if you’re doing TOP 10, you’ll need an order by – but how about reworking the query to avoid juggling so much data? And if the data sounds like too much for the app server to sort, it’s probably causing work on the SQL Server too. We talk about how to find those queries in the webcast listed at the bottom of this post. Also, keep in mind that I said “Avoid ORDER BY”, not “Never use ORDER BY”. I use ORDER BY myself too – but if I can avoid that work in the very expensive data tier, I’ll avoid it. That’s what avoid means.

UPDATE: Tôi đã nhận được rất nhiều ý kiến ​​than vãn về cách ứng dụng chỉ cần mười hàng của một tập dữ liệu hàng chục triệu. Chắc chắn, nếu bạn đang làm TOP 10, bạn sẽ cần một thứ tự Order by - nhưng làm thế nào tránh truy vấn lung tung vào quá nhiều dữ liệu? Và nếu các dữ liệu âm thanh như quá nhiều cho các máy chủ ứng dụng để sắp xếp, nó có thể gây ra việc trên SQL Server quá tải và chết. Chúng tôi nói chuyện về làm thế nào để tìm thấy những truy vấn trong các webcast được liệt kê ở dưới cùng của bài viết này. Ngoài ra, hãy nhớ rằng tôi đã nói "Tránh ORDER BY", không phải "Không bao giờ sử dụng ORDER BY". Tôi sử dụng ORDER BY cho chính tôi - nhưng nếu tôi có thể tránh được việc ở tầng dữ liệu rất đắt tiền, tôi sẽ tránh nó.

(Phần này ở đây là nơi mà những kẻ MySQL và PostgreSQL bắt đầu la hét về làm thế nào bạn có thể tránh được chi phí cấp phép hoàn toàn với cơ sở dữ liệu mã nguồn mở.) (Phần này ở đây là nơi bạn mong chờ tôi để có một vặn lại dí dỏm, nhưng tôi thì không. Nếu bạn đang xây dựng một ứng dụng thương hiệu mới và bạn đang lựa chọn một cơ sở dữ liệu, đọc câu trả lời của tôi StackOverflow mà cơ sở dữ liệu xử lý tải trọng nhất.) Nguồn: Brent Ozar