Hướng dẫn how many connections can a mysql db handle? - mysql db có thể xử lý bao nhiêu kết nối?

Question

how many concurrent connections can handle 2 GB RAM managed MySQL database ??

---

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

---

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Trong bài đăng này, chúng tôi mô tả các kết nối MySQL, luồng người dùng và tỷ lệ. Chúng tôi hy vọng rằng sự hiểu biết ngày càng tăng về cách MySQL hoạt động sẽ giúp các nhà phát triển ứng dụng và quản trị viên hệ thống đưa ra lựa chọn và đánh đổi tốt. Chúng tôi mô tả cách các kết nối hoạt động trong một máy chủ cộng đồng đơn giản và chúng tôi không bao gồm các chủ đề liên quan như gộp chủ đề, nhóm tài nguyên hoặc ghép kênh kết nối trong bài đăng này.

Máy chủ MySQL (MySQLD) thực thi như một quy trình HĐH duy nhất, với nhiều luồng thực hiện các hoạt động đồng thời. MySQL không có triển khai luồng riêng, nhưng dựa vào việc triển khai luồng của HĐH cơ bản. Khi người dùng kết nối với cơ sở dữ liệu, luồng người dùng được tạo bên trong MySQLD và luồng người dùng này thực thi truy vấn người dùng, & nbsp; Gửi kết quả trở lại cho người dùng, cho đến khi người dùng ngắt kết nối.

Khi ngày càng nhiều người dùng kết nối với cơ sở dữ liệu, ngày càng có nhiều luồng người dùng thực hiện song song. Miễn là tất cả các luồng người dùng thực thi như thể họ ở một mình, chúng ta có thể nói rằng hệ thống (MySQL) có tỷ lệ tốt. Nhưng tại một số điểm, chúng tôi đạt đến giới hạn và thêm nhiều luồng người dùng sẽ không hữu ích hoặc hiệu quả.

Kết nối và ngắt kết nối

Kết nối tương ứng với các phiên trong thuật ngữ tiêu chuẩn SQL. Một máy khách kết nối với máy chủ MySQL và giữ kết nối cho đến khi nó ngắt kết nối. Hình 1 minh họa những gì xảy ra khi máy khách MySQL kết nối với máy chủ MySQL.

Hình 1: Kết nối

Khách hàng. Máy khách MySQL là một công cụ dòng lệnh hoặc một ứng dụng nói chuyện với Máy chủ MySQL & NBSP; Trên giao thức máy khách MYSQL-máy chủ-máy chủ bằng thư viện LibMysqlClient hoặc một số trong nhiều đầu nối MySQL. Một máy khách đa luồng duy nhất có thể mở nhiều kết nối đến máy chủ, nhưng để đơn giản, chúng tôi nói rằng một ứng dụng khách mở một kết nối với máy chủ.

Yêu cầu kết nối. Máy khách MySQL gửi các yêu cầu kết nối đến máy chủ MySQL. Yêu cầu kết nối chỉ đơn giản là thông báo kết nối TCP-IP được gửi đến cổng 3306 trên máy chủ máy chủ.

Chủ đề máy thu. Các yêu cầu kết nối đến được xếp hàng và sau đó được xử lý bởi chủ đề máy thu từng cái một. Công việc duy nhất của luồng máy thu là tạo luồng người dùng, việc xử lý thêm được thực hiện bởi luồng người dùng.

Bộ đệm. Chủ đề máy thu sẽ tạo ra một luồng hệ điều hành mới hoặc sử dụng lại một luồng hệ điều hành miễn phí hiện có nếu được tìm thấy trong bộ đệm luồng. Bộ đệm chủ đề được sử dụng rất quan trọng đối với tốc độ kết nối khi các luồng hệ điều hành tốn kém để tạo. Ngày nay, việc tạo ra một luồng hệ điều hành tương đối rẻ và bộ đệm chủ đề có thể được coi là di sản. Giá trị mặc định của Thread_Cache_Size được tính là 8 + (Max_Connections / 100) và hiếm khi được thay đổi. Có thể có ý nghĩa khi thử tăng bộ đệm chỉ trong trường hợp số lượng kết nối dao động giữa có rất ít kết nối và có nhiều kết nối.

Chủ đề người dùng. Đó là luồng người dùng xử lý giao thức máy khách-máy chủ, ví dụ: Gửi lại gói bắt tay ban đầu. Chủ đề người dùng này sẽ phân bổ và khởi tạo THD tương ứng, và sau đó tiếp tục với việc đàm phán và xác thực khả năng. Trong quá trình này, thông tin đăng nhập của người dùng được lưu trữ trong bối cảnh bảo mật THD. Nếu mọi thứ diễn ra tốt đẹp trong giai đoạn kết nối, luồng người dùng sẽ nhập giai đoạn lệnh.

THD. Kết nối được biểu thị bằng cấu trúc dữ liệu được gọi là THD được tạo khi kết nối được thiết lập và xóa khi kết nối bị hủy. Luôn luôn có sự tương ứng một-một giữa kết nối người dùng và THD, tức là THD không được sử dụng lại trên các kết nối. Kích thước của THD là ~ 10k và định nghĩa của nó được tìm thấy trong sql_class.h. THD là một cấu trúc dữ liệu lớn được sử dụng để theo dõi các khía cạnh khác nhau của trạng thái thực thi. Bộ nhớ bắt nguồn từ THD sẽ phát triển đáng kể trong quá trình thực thi truy vấn, nhưng chính xác nó sẽ phát triển bao nhiêu sẽ phụ thuộc vào truy vấn. & NBSP; Đối với mục đích lập kế hoạch bộ nhớ, chúng tôi khuyên bạn nên lập kế hoạch cho ~ 10MB cho mỗi kết nối.

Hình 2: Kết nối hoạt động

Hình 2 minh họa giai đoạn lệnh. Tại đây, máy khách gửi truy vấn đến máy chủ và nhận lại kết quả trong một vài vòng. Nói chung, một chuỗi các câu lệnh có thể được gửi kèm theo giao dịch bắt đầu và cam kết/rollback. Trong trường hợp này, cần phải theo dõi bối cảnh giao dịch. Trong chế độ tự động-cam kết, mỗi câu lệnh sẽ được thực thi dưới dạng giao dịch (mỗi câu lệnh tạo thành bối cảnh giao dịch đầy đủ). Ngoài ra, có bối cảnh phiên, tức là phiên có thể giữ các biến phiên, biến người dùng và NBSP; và bảng tạm thời. Do đó, miễn là bối cảnh có liên quan để thực hiện các truy vấn, tất cả các truy vấn trên kết nối phải sử dụng cùng một THD.

Hình 3: Ngắt kết nối

Hình 3 minh họa những gì xảy ra khi máy khách MySQL ngắt kết nối với máy chủ MySQL. Khách hàng gửi A & NBSP; Lệnh COM_QUIT khiến máy chủ đóng ổ cắm. Một sự ngắt kết nối cũng có thể xảy ra khi một trong hai bên đóng đầu của ổ cắm. Khi ngắt kết nối, luồng người dùng sẽ dọn dẹp, hãy phân bổ THD và cuối cùng tự đặt vào bộ đệm của luồng như là lơ lửng nếu có các khe miễn phí. Nếu không có khe cắm miễn phí, luồng người dùng sẽ bị chấm dứt.

Kết nối ngắn ngủi

Một kết nối ngắn ngủi là một kết nối chỉ mở trong một khoảng thời gian ngắn. Đây thường là trường hợp cho các ứng dụng PHP, máy khách mở kết nối, thực hiện một truy vấn đơn giản và sau đó đóng kết nối. Do kiến ​​trúc của nó, MySQL thực sự rất giỏi trong việc chấp nhận các kết nối mới ở tốc độ cao, lên tới 80.000 kết nối/ngắt kết nối mỗi giây như trong Hình 4 bên dưới.

Hình 4: Kết nối+Truy vấn+Ngắt kết nối mỗi giây

Hình 4 minh họa hiệu suất kết nối/ngắt kết nối MySQL. Máy kiểm tra có Intel (R) Xeon (R) E5-2699 V4 CPU, 2CPU-SOCKETS, 22 lõi-HT mỗi ổ cắm, 2,20GHz (Broadwell). Chúng tôi đang chạy các máy khách Sysbench và máy chủ MySQL trên cùng một bộ lõi. Mỗi luồng Sysbench kết nối mặc dù ổ cắm, đưa ra một điểm chọn, ngắt kết nối và sau đó lặp lại. Dữ liệu là trong bộ nhớ. Biểu đồ hiển thị TPS cho số lượng khách hàng khác nhau, 20.000 cho 8 máy khách, 43.000 cho 16 máy khách, 73.000 cho 32 máy khách và 80.000 cho 64 máy khách.

MySQL luôn tương đối giỏi trong việc kết nối/ngắt kết nối, nhưng thực sự rất tốt với một số trợ giúp từ Facebook trong MySQL 5.6. Xem các bài đăng trên blog của Domas Mituzas và & NBSP; Yoshinori Matsunobu. Một số cải tiến bổ sung đã được thực hiện trong MySQL 5.7.

Kết nối lâu dài

Một kết nối sống lâu là một kết nối mở ra vô thời hạn. Ví dụ, người ta có thể có máy chủ web hoặc máy chủ ứng dụng & NBSP; Mở nhiều kết nối đến máy chủ MySQL và giữ cho chúng mở cho đến khi ứng dụng khách (máy chủ web/ứng dụng) bị dừng, có lẽ trong nhiều tháng.

Số lượng máy khách tối đa mà máy chủ cho phép kết nối đồng thời được xác định bởi biến hệ thống max_connections, có thể định cấu hình bởi người dùng. Khi đạt đến mức tối đa này, máy chủ sẽ không chấp nhận các kết nối mới cho đến khi một trong các máy khách đang hoạt động ngắt kết nối. Máy chủ MySQL sẽ có một luồng người dùng (với THD) cho thời gian sống của kết nối, như được minh họa trong Hình 5.

Hình 5: Nhiều máy khách kết nối với một máy chủ MySQL duy nhất

Vì vậy, giá trị tốt nhất cho max_connections là gì? Câu trả lơi con phụ thuộc vao nhiêu thư". Nó sẽ chủ yếu phụ thuộc vào hai điều, tải máy khách và phần cứng MySQL đang chạy.

Một kết nối có thể ít nhiều bận rộn. Một kết nối rất bận rộn khi máy khách gửi các truy vấn quay lại đến máy chủ, nghĩa là mỗi lần khách hàng nhận lại kết quả, nó ngay lập tức gửi một truy vấn mới đến máy chủ. Một kết nối không bận nếu khách hàng bây giờ và sau đó gửi một truy vấn đến máy chủ và có những khoảng dừng dài giữa việc nhận kết quả từ một truy vấn cho đến khi truy vấn tiếp theo được gửi (khoảng thời gian nhàn rỗi). Trong một tình huống khi có nhiều kết nối và tất cả các kết nối đều rất bận rộn, chúng tôi nói rằng máy chủ MySQL đang bị tải nặng.

Khi các kết nối ít bận rộn hơn, người ta có thể chấp nhận nhiều kết nối hơn. Hãy để chúng tôi nói một thể hiện máy chủ nhất định đang tối đa hóa 5000 TPS cho tải người dùng trên 200 kết nối. Cùng một máy chủ sau đó sẽ có thể xử lý cùng một đồng thời (5000 TPS) trên 10000 kết nối, nhưng việc thêm nhiều kết nối sẽ không tăng sự đồng thời. Tuy nhiên, 10000 kết nối sẽ yêu cầu sử dụng bộ nhớ cao hơn cho (nhiều) THD và sẽ dẫn đến việc sử dụng phần cứng kém hiệu quả hơn. Người ta cũng cần lưu ý rằng khi cài đặt MAX_CONNENTS lên 10000, có nguy cơ quá tải máy chủ nếu tất cả các kết nối gửi ngày càng nhiều truy vấn vượt quá dung lượng tổng thể 5000 TPS. Trong trường hợp này, máy chủ có thể bắt đầu đập.

Tải tối đa là bao nhiêu? Và làm thế nào để tôi biết rằng máy chủ đã đạt tải tối đa? Bạn phải kiểm tra khối lượng công việc của mình, ví dụ như sau: Bạn có thể bắt đầu với 2 máy khách bận rộn và đo TPS và độ trễ của máy chủ, sau đó tiếp tục bước tiến bằng cách nhân đôi số lượng máy khách cho mỗi bước. Ban đầu, TPS sẽ tăng và độ trễ sẽ không đổi cho mỗi bước bạn thực hiện. Tại một số điểm TPS sẽ giống như trước đây và độ trễ sẽ bắt đầu tăng và đây là tải tối đa và số lượng máy khách (hữu ích) tối đa.

MYSQL đồng thời chủ đề người dùng tối đa có thể xử lý là gì? & NBSP; Chúng ta hãy tìm một tải đạt đến giới hạn đồng thời của chủ đề trước khi nó đạt đến các giới hạn khác. Một tải phù hợp với yêu cầu này là tra cứu khóa chính (chọn điểm Sysbench) của dữ liệu có trong bộ nhớ chính (nhóm bộ đệm). Do khóa chính trong MySQL/Innodb được lưu trữ cùng với dữ liệu (chỉ mục phân cụm), điều duy nhất MySQL phải làm cho một điểm chọn là điều hướng cây B trong bộ nhớ, hãy tìm bản ghi và trả về kết quả.

Vì chúng tôi muốn minh họa đồng thời chủ đề, chúng tôi chọn một máy có 48 lõi CPU. Máy kiểm tra có Intel (R) Xeon (R) Platinum 8168 CPU, 2CPU-sockets, 24 lõi-HT mỗi ổ cắm, 2,70GHz (Skylake). Chúng tôi đang chạy máy khách Sysbench và máy chủ MySQL 8.0.15 trên cùng một bộ lõi.

Hình 6: Sysbench point_select (dữ liệu phù hợp với bộ nhớ)

Hình 6 cho thấy mối quan hệ giữa số lượng kết nối (luồng người dùng) và tải tổng thể về giao dịch mỗi giây (TPS). Mỗi máy khách tạo điểm chọn Tải Back-to-back. Ban đầu, tổng tải phát triển gần với tuyến tính so với số lượng máy khách đồng thời, ví dụ 16 máy khách cung cấp cho bạn 300 nghìn TPS, 32 máy khách cung cấp cho bạn 600 & NBSP; nghìn TPS, 64 máy khách cung cấp cho bạn 1,2 triệu TP. Tối đa đạt được với 128 máy khách với 1,8 triệu TP. Với hơn 128 khách hàng, các điểm dừng tăng và sau đó bắt đầu giảm. Vậy thì chuyện gì đã xảy ra ở đây?

Hình 7: Sysbench point_select (độ trễ)

Hãy cùng xem xét độ trễ truy vấn được mô tả trong Hình 7 ở trên. Từ 1 đến 64 máy khách thời gian phản hồi truy vấn (độ trễ) không đổi khoảng 50 micro giây. Sau đó, nó tăng lên 70 micro giây cho 128 máy khách, 140 micro giây cho 256 máy khách và 300 micro giây cho 512 máy khách.

MySQL đạt hiệu suất tối đa cho 128 luồng người dùng, với TPS tối đa (1,8 triệu) và độ trễ thấp (70 micro giây). & NBSP; Do đó, ở mức cao nhất, luồng người dùng trên mỗi tỷ lệ lõi là 128/48 = 2,7 và & NBSP; Từ đó về hiệu quả đi xuống. Thêm nhiều luồng người dùng sẽ khiến độ trễ phát triển và nó sẽ phụ thuộc vào các yêu cầu ứng dụng Những gì độ trễ chấp nhận được, tức là Thỏa thuận cấp độ dịch vụ được xác định. Trong ví dụ của chúng tôi ở đây, 95% tất cả các giao dịch có độ trễ dưới 210 micro giây, có thể đủ tốt cho hầu hết các ứng dụng. Điều này cung cấp cho chúng tôi một luồng người dùng trên mỗi tỷ lệ lõi là 256/48 = 5.3. Dựa trên kinh nghiệm tích lũy, chúng tôi đề xuất tối đa 4 lần số lượng người dùng là số lượng lõi CPU thực, do đó 4 × 48 = 196 Chủ đề người dùng trong ví dụ của chúng tôi.

MySQL không phải lúc nào cũng có tỷ lệ cũng như hiển thị ở trên. MySQL 5.6 đi kèm với các cải tiến khả năng kiểm soát RO lớn, nhưng bạn phải sử dụng tính năng giao dịch chỉ đọc và cam kết tự động để có được hiệu ứng. & NBSP; MySQL 5.7 đi kèm với tự động khám phá các giao dịch RO và loại bỏ sự tranh chấp xung quanh khóa dữ liệu meta, thr_lock và innodb trx_sys mutex và mutex lock_sys. Đối với những người quan tâm đến lịch sử chuyên sâu hoàn chỉnh, hãy xem các bài đăng của Dimitri ở đây, ở đây, ở đây, ở đây và ở đây.

Điều gì xảy ra nếu bạn đánh một số nút cổ chai khác trước khi bạn nhấn nút cổ chai đồng thời chủ đề? Một ví dụ như vậy được minh họa trong Hình 8 dưới đây. Hình 8 cho thấy truy vấn chọn điểm sysbench tương tự như trong Hình 6 ở trên, nhưng bây giờ khối lượng dữ liệu cao hơn nhiều và dữ liệu phải được đọc từ đĩa hầu hết thời gian. Trong ví dụ này, chúng tôi đang sử dụng SSD Intel Optane Fast Intel nhưng vẫn có thể bão hòa băng thông từ đĩa đến bộ nhớ. I E. Các chủ đề của người dùng trong ví dụ này đang chờ các trang đĩa được mang từ SSD đến nhóm bộ đệm Innodb. Kết quả tổng thể là TPS thấp hơn (1 triệu so với 1,8 triệu) vì mỗi truy vấn sẽ dành nhiều thời gian hơn để chờ dữ liệu. Thêm nhiều máy khách tăng TPS cho đến khi dung lượng đĩa được bão hòa, ở mức khoảng 128-256 kết nối. Tại thời điểm này, tất cả các luồng người dùng chỉ đang chờ IO và thêm nhiều luồng người dùng sẽ có hiệu quả.

Hình 8: Sysbench point_select (IO ràng buộc)

Bài đăng của Dimitri ở đây thảo luận về các cải tiến 8.0 về khả năng mở rộng IO, loại bỏ sự tranh chấp xung quanh innodb fil_system mutex. Trong bối cảnh hiện tại, nó chỉ cho thấy rằng mặc dù sự tranh chấp ở đây là trên đĩa IO và TPS thấp hơn (1,1 triệu) Chủ đề, tối đa trên 256 luồng người dùng đạt 1,1 triệu qps.

Những gì giới hạn sự đồng thời chủ đề?

Một chủ đề sẽ vui vẻ thực hiện các hướng dẫn cho đến khi nó cần chờ một cái gì đó hoặc cho đến khi nó đã sử dụng thời gian của nó theo quyết định của bộ lập lịch hệ điều hành. Có ba điều mà một chủ đề có thể cần phải chờ: & nbsp; Một mutex, khóa cơ sở dữ liệu hoặc IO.

Mutex. Một mutex bảo vệ một cấu trúc dữ liệu nội bộ được chia sẻ, tức là khi người ta cần đảm bảo rằng chỉ có một luồng có thể thực thi bất cứ lúc nào. Nếu một luồng giữ một mutex, các luồng khác phải chờ xếp hàng cho đến khi đến lượt của chúng. Việc sử dụng của MuTexes là một kỹ thuật thực hiện và do đó, một cái gì đó có thể được các lập trình viên tung hứng miễn là duy trì tính chính xác của chương trình tổng thể. Các kỹ thuật bao gồm việc sử dụng các thuật toán không có khóa và để phân tách các tài nguyên được bảo vệ thành các tài nguyên hạt mịn hơn để đảm bảo rằng các luồng khác nhau yêu cầu các loại mutex khác nhau (giảm sự tranh chấp về tài nguyên toàn cầu). Phần lớn công việc mở rộng được thực hiện bởi các nhà phát triển MYSQL trong 5-10 năm qua đã tập trung vào việc sử dụng tốt hơn các loại mutexes.

Khóa. Khóa cơ sở dữ liệu theo một nghĩa nào đó giống như điều tương tự nhưng chúng được gắn với ngữ nghĩa cơ sở dữ liệu và do đó khó tránh hơn. (MySQL/Innodb khá giỏi trong việc tránh khóa do điều khiển đồng thời đa phiên bản của nó, MVCC). Khóa cơ sở dữ liệu có thể được chia thành các khóa dữ liệu (gây ra bởi SQL DML) và khóa dữ liệu meta (gây ra bởi SQL DDL). Một khóa dữ liệu như khóa hàng thường sẽ bảo vệ dữ liệu được cập nhật bởi một luồng khỏi được đọc hoặc viết bởi một luồng khác. Khóa dữ liệu meta thường sẽ bảo vệ lược đồ cơ sở dữ liệu khỏi các bản cập nhật đồng thời, không tương thích. Duy trì ngữ nghĩa cơ sở dữ liệu quan trọng hơn hiệu suất và quy mô, vì vậy việc loại bỏ khóa khó hơn là loại bỏ các loại mutexes. Kết quả là, các tắc nghẽn khả năng mở rộng do khóa thường phải được giải quyết ở cấp độ thiết kế ứng dụng OLTP, ví dụ: Một thiết kế lược đồ cơ sở dữ liệu tốt hơn kết hợp với các thiết kế truy vấn tốt hơn. MySQL 8.0 cũng cung cấp một số tính năng thú vị mới cho các nhà phát triển ứng dụng để tránh khóa, ví dụ: Không chờ và bỏ qua bị khóa.

Đĩa và mạng IO. IO là thứ mà người ta cố gắng giảm thiểu bất cứ khi nào có thể, và khi không thể cố gắng làm điều đó hiệu quả nhất có thể, ví dụ: Lấy trước, song song hóa, hàng loạt, vv Nhưng đến một lúc nào đó, hầu hết các chủ đề người dùng sẽ cần IO. Khi luồng người dùng cần đợi IO, HĐH thường sẽ đặt luồng ở trạng thái chờ và đưa CPU vào một luồng chờ khác. Điều này sẽ hoạt động tốt nếu chủ đề mới có khả năng đạt được tiến bộ và sẽ dẫn đến việc sử dụng CPU hiệu quả. Nhưng, ví dụ, nếu băng thông IO đã bị bão hòa, luồng mới cũng có khả năng cũng chỉ chờ IO và không có tiến triển nào có thể được thực hiện. Vì vậy, sự đồng thời của chủ đề sẽ bị giới hạn bởi công suất IO, như chúng ta đã thấy trong Hình 8.

Điều gì xảy ra khi một chủ đề bị đình chỉ bởi HĐH? Đầu tiên, nó không tiến triển nữa. Thứ hai, nó có thể giữ Mutexes hoặc khóa ngăn các luồng khác tiến triển. Thứ ba, khi nó được đánh thức một lần nữa, các vật phẩm được lưu trong bộ nhớ cache có thể đã bị trục xuất yêu cầu dữ liệu phải được đọc lại. Tại một số điểm, nhiều chủ đề sẽ chỉ khiến hàng đợi các luồng chờ phát triển và hệ thống sẽ sớm bị kẹt. Giải pháp là giới hạn số lượng luồng người dùng bằng cách giới hạn MAX_Connections, chỉ cho phép nhiều luồng người dùng đồng thời như hệ thống có thể xử lý hiệu quả.

Vai trò của các nhà phát triển ứng dụng

Trong một số trường hợp, các nhà phát triển ứng dụng đang kiểm soát kiến ​​trúc hệ thống tổng thể, lược đồ cơ sở dữ liệu và truy vấn cơ sở dữ liệu. Nhưng có lẽ thường xuyên hơn không, các nhà phát triển ứng dụng sẽ được yêu cầu phát triển một ứng dụng trên cơ sở dữ liệu hiện có. Trong cả hai trường hợp, nhà phát triển ứng dụng sẽ cần chú ý đến các truy vấn được gửi đến lớp cơ sở dữ liệu.

Trường hợp sử dụng cổ điển cho MySQL là xử lý giao dịch trực tuyến (OLTP) thường có yêu cầu thời gian đáp ứng. Thời gian phản hồi cơ sở dữ liệu có thể chấp nhận thường được chỉ định tính bằng mili giây và điều này tất nhiên sẽ giới hạn loại truy vấn có thể được dự kiến ​​sẽ chạy (có thể kết hợp với các hạn chế về khối lượng dữ liệu và cấu trúc của lược đồ cơ sở dữ liệu). Điều này thường trái ngược với & nbsp; Xử lý phân tích trực tuyến (OLAP) trong đó có các truy vấn phức tạp hơn, nhưng tần suất truy vấn thấp hơn và yêu cầu thời gian đáp ứng có thể được thư giãn hơn.

Đặc biệt đối với OLTP, nhà phát triển ứng dụng phải cẩn thận trong việc thiết kế các truy vấn có thể thực thi trong SLA thời gian phản hồi nhất định và có thể được thực hiện song song. & NBSP; Không khó để tạo ra một khối lượng công việc không quy mô, ví dụ như nhiều máy khách song song không làm gì khác ngoài việc cập nhật cùng một hàng trong cùng một bảng (xem các thiết kế thay thế ở đây).

Sự kết luận

• MySQL rất giỏi trong việc xử lý nhiều máy khách kết nối và ngắt kết nối với cơ sở dữ liệu ở tần số cao, lên tới 80 nghìn kết nối và ngắt kết nối mỗi giây
• MySQL tỷ lệ tốt trên CPU đa lõi và có thể cung cấp tới 2 triệu lần tra cứu chính mỗi giây trên 48 lõi CPU.
• Quy tắc ngón tay cái: Số lượng kết nối tối đa = 4 lần lõi CPU có sẵn
• Việc sử dụng hiệu quả các kết nối sẽ phụ thuộc vào tải người dùng, số lượng kết nối người dùng hữu ích thậm chí có thể thấp hơn số lượng lõi CPU khi nút cổ chai ở một nơi khác ngoài việc xâu chuỗi
• Kiểm tra tải của riêng bạn bằng cách nhân đôi số lượng kết nối cho đến khi TPS không còn tăng và độ trễ bắt đầu tăng

Cảm ơn bạn đã sử dụng MySQL!

Có bao nhiêu kết nối cơ sở dữ liệu MySQL?

DB có thể xử lý bao nhiêu kết nối?

Làm thế nào để MySQL xử lý quá nhiều kết nối?

Cơ sở dữ liệu MySQL có thể lớn đến mức nào?