Bảng gian lận hiệu suất MySQL

MySQL rất rộng và có rất nhiều lĩnh vực cần tối ưu hóa và điều chỉnh để đạt được hiệu suất mong muốn. Một số thay đổi có thể được thực hiện động, những thay đổi khác yêu cầu khởi động lại máy chủ. Việc tìm thấy cài đặt MySQL với cấu hình mặc định là khá phổ biến, mặc dù cấu hình sau có thể không phù hợp với khối lượng công việc và thiết lập của bạn.

Dưới đây là các lĩnh vực chính trong MySQL mà tôi đã lấy từ các nguồn chuyên gia khác nhau trong thế giới MySQL, cũng như kinh nghiệm của chính chúng tôi ở đây tại Somenines. Blog này sẽ đóng vai trò là bảng gian lận của bạn để điều chỉnh hiệu suất và làm cho MySQL của bạn trở nên tuyệt vời trở lại :-)

Hãy xem xét những điều này bằng cách phác thảo các khu vực chính trong MySQL.

Biến hệ thống

MySQL có rất nhiều biến mà bạn có thể cân nhắc để thay đổi. Một số biến là động có nghĩa là chúng có thể được thiết lập bằng cách sử dụng câu lệnh SET. Những người khác yêu cầu khởi động lại máy chủ, sau khi chúng được đặt trong tệp cấu hình (ví dụ:/etc/my.cnf, etc / mysql / my.cnf). Tuy nhiên, tôi sẽ điểm qua những điểm chung khá phổ biến cần điều chỉnh để làm cho máy chủ được tối ưu hóa.

sort_buffer_size

Biến này kiểm soát dung lượng bộ đệm tệp của bạn, có nghĩa là bất cứ khi nào truy vấn cần sắp xếp các hàng, giá trị của biến này được sử dụng để giới hạn kích thước cần được cấp phát. Hãy lưu ý rằng biến này là trên cơ sở mỗi truy vấn được xử lý (hoặc mỗi kết nối), có nghĩa là sẽ rất tốn bộ nhớ khi bạn đặt giá trị này cao hơn và nếu bạn có nhiều kết nối yêu cầu sắp xếp các hàng của mình. Tuy nhiên, bạn có thể theo dõi nhu cầu của mình bằng cách kiểm tra biến trạng thái chung Sort_merge_passes. Nếu giá trị này lớn, bạn nên cân nhắc việc tăng giá trị của biến hệ thống sort_buffer_size. Nếu không, hãy đưa nó đến giới hạn vừa phải mà bạn cần. Nếu bạn đặt giá trị này quá thấp hoặc nếu bạn có nhiều truy vấn cần xử lý, hiệu quả của việc sắp xếp các hàng của bạn có thể chậm hơn mong đợi vì dữ liệu được truy xuất ngẫu nhiên khi ổ đĩa lặn. Điều này có thể làm giảm hiệu suất. Tuy nhiên, cách tốt nhất là sửa các truy vấn của bạn. Mặt khác, nếu ứng dụng của bạn được thiết kế để kéo các truy vấn lớn và yêu cầu sắp xếp, thì sẽ hiệu quả khi sử dụng các công cụ xử lý bộ nhớ đệm truy vấn như Redis. Theo mặc định, trong MySQL 8.0, giá trị hiện tại được đặt là 256 KiB. Chỉ đặt tùy chọn này cho phù hợp khi bạn có các truy vấn đang sử dụng nhiều hoặc gọi các loại.

read_buffer_size

Tài liệu MySQL đề cập rằng đối với mỗi yêu cầu thực hiện quét tuần tự một bảng, nó sẽ cấp phát một bộ đệm đọc. Biến hệ thống read_buffer_size xác định kích thước bộ đệm. Nó cũng hữu ích cho MyISAM, nhưng biến này cũng ảnh hưởng đến tất cả các công cụ lưu trữ. Đối với bảng MEMORY, nó được sử dụng để xác định kích thước khối bộ nhớ.

Về cơ bản, mỗi luồng thực hiện quét tuần tự cho một bảng MyISAM sẽ phân bổ một bộ đệm có kích thước này (tính bằng byte) cho mỗi bảng mà nó quét. Nó cũng áp dụng cho tất cả các công cụ lưu trữ (bao gồm cả InnoDB), vì vậy nó rất hữu ích cho các truy vấn đang sắp xếp các hàng bằng ORDER BY và lưu vào bộ nhớ đệm các chỉ mục của nó trong một tệp tạm thời. Nếu bạn thực hiện nhiều lần quét tuần tự, chèn hàng loạt vào bảng phân vùng, lưu vào bộ nhớ đệm kết quả của các truy vấn lồng nhau, thì hãy xem xét việc tăng giá trị của nó. Giá trị của biến này phải là bội số của 4KB. Nếu nó được đặt thành giá trị không phải là bội số của 4KB, giá trị của nó sẽ được làm tròn xuống bội số gần nhất của 4KB. Lưu ý rằng việc đặt giá trị này thành giá trị cao hơn sẽ tiêu tốn một phần lớn bộ nhớ máy chủ của bạn. Tôi khuyên bạn không nên sử dụng điều này mà không có điểm chuẩn thích hợp và theo dõi môi trường của bạn.

read_rnd_buffer_size

Biến này xử lý việc đọc các hàng từ bảng MyISAM theo thứ tự được sắp xếp sau thao tác sắp xếp khóa, các hàng được đọc qua bộ đệm này để tránh tìm đĩa. Tài liệu cho biết, khi đọc các hàng theo trình tự tùy ý hoặc từ bảng MyISAM theo thứ tự được sắp xếp sau thao tác sắp xếp khóa, các hàng được đọc qua bộ đệm này (và được xác định thông qua kích thước bộ đệm này) để tránh tìm kiếm đĩa. Đặt biến thành một giá trị lớn có thể cải thiện hiệu suất ORDER BY khá nhiều. Tuy nhiên, đây là bộ đệm được phân bổ cho từng máy khách, vì vậy bạn không nên đặt biến toàn cục thành giá trị lớn. Thay vào đó, chỉ thay đổi biến phiên từ bên trong các ứng dụng khách cần chạy các truy vấn lớn. Tuy nhiên, bạn nên lưu ý rằng điều này không áp dụng cho MariaDB, đặc biệt là khi tận dụng MRR. MariaDB sử dụng mrr_buffer_size trong khi MySQL sử dụng read_buffer_size read_rnd_buffer_size.

join_buffer_size

Theo mặc định, giá trị là 256K. Kích thước tối thiểu của bộ đệm được sử dụng để quét chỉ mục thuần túy, quét chỉ mục phạm vi và các phép nối không sử dụng chỉ mục và do đó thực hiện quét toàn bộ bảng. Cũng được sử dụng bởi tính năng tối ưu hóa BKA (bị tắt theo mặc định). Tăng giá trị của nó để nhận được các phép tham gia đầy đủ nhanh hơn khi không thể thêm chỉ mục. Hãy cẩn thận mặc dù có thể là vấn đề về bộ nhớ nếu bạn đặt mức này quá cao. Hãy nhớ rằng một bộ đệm nối được cấp phát cho mỗi phép nối đầy đủ giữa hai bảng. Đối với một phép nối phức tạp giữa một số bảng mà chỉ mục không được sử dụng, nhiều bộ đệm nối có thể cần thiết. Tốt nhất để ở mức thấp nhất trên toàn cầu và đặt ở mức cao trong các phiên (bằng cách sử dụng cú pháp SET SESSION) yêu cầu liên kết lớn đầy đủ. Trong nền tảng 64-bit, Windows cắt bớt các giá trị trên 4GB xuống còn 4GB-1 kèm theo cảnh báo.

max_heap_table_size

Đây là kích thước tối đa tính bằng byte cho các bảng MEMORY do người dùng tạo được phép phát triển. Điều này rất hữu ích khi ứng dụng của bạn đang xử lý các bảng công cụ lưu trữ MEMORY. Đặt biến trong khi máy chủ đang hoạt động không ảnh hưởng đến các bảng hiện có trừ khi chúng được tạo lại hoặc thay đổi. Kích thước max_heap_table_size và tmp_table_size nhỏ hơn cũng giới hạn các bảng trong bộ nhớ nội bộ. Biến này cũng được kết hợp với tmp_table_size để giới hạn kích thước của các bảng trong bộ nhớ trong (điều này khác với các bảng được tạo rõ ràng là Engine =MEMORY vì nó chỉ áp dụng max_heap_table_size), cái nào nhỏ hơn sẽ được áp dụng giữa hai.

tmp_table_size

Kích thước lớn nhất cho các bảng tạm thời trong bộ nhớ (không phải bảng MEMORY) mặc dù nếu max_heap_table_size nhỏ hơn thì giới hạn dưới sẽ được áp dụng. Nếu bảng tạm thời trong bộ nhớ vượt quá giới hạn, MySQL sẽ tự động chuyển nó thành bảng tạm thời trên đĩa. Tăng giá trị của tmp_table_size (và max_heap_table_size nếu cần) nếu bạn thực hiện nhiều truy vấn GROUP BY nâng cao và bạn có dung lượng bộ nhớ khả dụng lớn. Bạn có thể so sánh số lượng bảng tạm thời trên đĩa nội bộ được tạo với tổng số bảng tạm thời bên trong được tạo bằng cách so sánh giá trị của các biến Created_tmp_disk_tables và Created_tmp_tables. Trong ClusterControl, bạn có thể theo dõi điều này qua Bảng điều khiển -> Đồ thị đối tượng tạm thời.

table_open_cache

Bạn có thể tăng giá trị của biến này nếu bạn có số lượng lớn các bảng được truy cập thường xuyên trong tập dữ liệu của mình. Nó sẽ được áp dụng cho tất cả các chủ đề, nghĩa là trên mỗi cơ sở kết nối. Giá trị cho biết số lượng bảng tối đa mà máy chủ có thể mở trong bất kỳ trường hợp bộ đệm một bảng nào. Mặc dù việc tăng giá trị này sẽ làm tăng số lượng bộ mô tả tệp mà mysqld yêu cầu, vì vậy bạn cũng có thể cân nhắc kiểm tra giá trị open_files_limit của mình hoặc kiểm tra xem giới hạn SOFT và HARD được đặt trong hệ điều hành * nix của bạn lớn như thế nào. Bạn có thể theo dõi điều này xem bạn có cần tăng bộ nhớ cache của bảng hay không bằng cách kiểm tra biến trạng thái Opened_tables. Nếu giá trị của Opened_tables lớn và bạn không sử dụng FLUSH TABLES thường xuyên (chỉ buộc đóng và mở lại tất cả các bảng), thì bạn nên tăng giá trị của biến table_open_cache. Nếu bạn có một giá trị nhỏ cho table_open_cache và một số lượng lớn các bảng thường xuyên được truy cập, điều này có thể ảnh hưởng đến hiệu suất của máy chủ của bạn. Nếu bạn nhận thấy nhiều mục nhập trong danh sách quy trình MySQL với trạng thái "Mở bảng" hoặc "Đóng bảng", thì đã đến lúc điều chỉnh giá trị của biến này nhưng hãy lưu ý đến cảnh báo đã đề cập trước đó. Trong ClusterControl, bạn có thể kiểm tra điều này trong Bảng điều khiển -> Trạng thái bộ nhớ đệm mở bảng hoặc Bảng điều khiển -> Bảng mở. Bạn có thể kiểm tra nó tại đây để biết thêm thông tin.

table_open_cache_instances

Đặt biến này sẽ giúp cải thiện khả năng mở rộng và tất nhiên, hiệu suất sẽ làm giảm sự tranh cãi giữa các phiên. Giá trị bạn đặt ở đây giới hạn số lượng phiên bản bộ đệm ẩn bảng đang mở. Bộ đệm ẩn các bảng đang mở có thể được phân vùng thành một số phiên bản bộ đệm nhỏ hơn có kích thước table_open_cache / table_open_cache_instances. Một phiên chỉ cần khóa một phiên bản để truy cập nó cho các câu lệnh DML. Điều này phân đoạn quyền truy cập bộ nhớ cache giữa các phiên bản, cho phép hiệu suất cao hơn cho các hoạt động sử dụng bộ đệm khi có nhiều phiên truy cập bảng. (Các câu lệnh DDL vẫn yêu cầu khóa trên toàn bộ bộ đệm, nhưng các câu lệnh như vậy ít thường xuyên hơn nhiều so với các câu lệnh DML.) Giá trị 8 hoặc 16 được khuyến nghị trên các hệ thống thường sử dụng 16 lõi trở lên.

table_definition_cache

Định nghĩa bảng trong bộ nhớ cache, tức là đây là nơi TẠO BẢNG được lưu vào bộ nhớ cache để tăng tốc độ mở bảng và chỉ một mục nhập cho mỗi bảng. Sẽ là hợp lý để tăng giá trị nếu bạn có số lượng bảng lớn. Bộ đệm ẩn định nghĩa bảng chiếm ít dung lượng hơn và không sử dụng bộ mô tả tệp, không giống như bộ đệm ẩn bảng thông thường. Peter Zaitsev của Percona gợi ý nếu bạn có thể thử thiết lập công thức bên dưới,

The number of user-defined tables + 10% unless 50K+ tables

Nhưng lưu ý rằng giá trị mặc định dựa trên công thức sau được giới hạn ở giới hạn 2000.

MIN(400 + table_open_cache / 2, 2000)

Vì vậy, trong trường hợp bạn có số lượng bảng lớn hơn so với mặc định, thì bạn nên tăng giá trị của nó. Lưu ý rằng với InnoDB, biến này được sử dụng như một giới hạn mềm về số lượng phiên bản bảng mở cho bộ đệm từ điển dữ liệu. Nó sẽ áp dụng cơ chế LRU khi nó vượt quá giá trị hiện tại của biến này. Giới hạn này giúp giải quyết các tình huống trong đó lượng bộ nhớ đáng kể sẽ được sử dụng để lưu vào bộ đệm các phiên bản bảng hiếm khi được sử dụng cho đến khi máy chủ tiếp theo khởi động lại. Do đó, các trường hợp bảng cha và con có mối quan hệ khóa ngoại không được đặt trong danh sách LRU và có thể áp đặt giới hạn cao hơn giới hạn được xác định bởi table_definition_cache và không bị loại bỏ trong bộ nhớ trong LRU. Ngoài ra, table_definition_cache xác định giới hạn mềm cho số lượng không gian bảng tệp InnoDB trên mỗi bảng có thể mở cùng một lúc, cũng được kiểm soát bởi innodb_open_files và trên thực tế, cài đặt cao nhất giữa các biến này được sử dụng, nếu cả hai đều được đặt . Nếu không có biến nào được đặt, table_definition_cache, có giá trị mặc định cao hơn, sẽ được sử dụng. Nếu số lượng xử lý tệp không gian bảng đang mở vượt quá giới hạn được xác định bởi table_definition_cache hoặc innodb_open_files, cơ chế LRU sẽ tìm kiếm danh sách LRU của tệp không gian bảng để tìm các tệp đã được xóa hoàn toàn và hiện không được mở rộng. Quá trình này được thực hiện mỗi khi một vùng bảng mới được mở. Nếu không có vùng bảng nào “không hoạt động” thì không có tệp vùng bảng nào bị đóng. Vì vậy, hãy ghi nhớ điều này.

max_allowed_packet

Đây là kích thước tối đa cho mỗi kết nối của truy vấn SQL hoặc hàng được trả về. Giá trị được tăng lần cuối trong MySQL 5.6. Tuy nhiên trong MySQL 8.0 (ít nhất là trên 8.0.3), giá trị mặc định hiện tại là 64 MiB. Bạn có thể xem xét điều chỉnh điều này nếu bạn có các hàng BLOB lớn cần được kéo ra (hoặc đọc), nếu không, bạn có thể để cài đặt mặc định này với 8.0 nhưng trong các phiên bản cũ hơn, mặc định là 4 MiB, vì vậy bạn có thể lưu ý điều đó trong trường hợp bạn gặp lỗi ER_NET_PACKET_TOO_LARGE. Gói lớn nhất có thể được truyền đến hoặc từ máy chủ hoặc máy khách MySQL 8.0 là 1GB.

max_connections

Đây là số lượng kết nối được phép cho máy chủ MySQL của bạn. Nếu bạn phát hiện ra lỗi trong MySQL ‘Quá nhiều kết nối’, bạn có thể cân nhắc đặt nó cao hơn. Theo mặc định, giá trị 151 là không đủ, đặc biệt là trên cơ sở dữ liệu sản xuất và xem xét rằng bạn có nhiều tài nguyên hơn của máy chủ (đừng lãng phí tài nguyên máy chủ của bạn, đặc biệt nếu đó là máy chủ MySQL chuyên dụng). Tuy nhiên, bạn phải có đủ bộ mô tả tệp nếu không bạn sẽ sử dụng hết chúng. Trong trường hợp đó, hãy xem xét điều chỉnh giới hạn SOFT và HARD của hệ điều hành * nix và đặt giá trị cao hơn của open_files_limit trong MySQL (5000 là giới hạn mặc định). Lưu ý rằng rất thường xuyên ứng dụng không đóng các kết nối với cơ sở dữ liệu một cách chính xác và việc đặt max_connections cao có thể dẫn đến một số máy chủ của bạn không phản hồi hoặc tải cao. Sử dụng nhóm kết nối ở cấp ứng dụng có thể giúp giải quyết vấn đề ở đây.

thread_cache_size

Đây là bộ nhớ đệm để ngăn chặn việc tạo luồng quá nhiều. Khi máy khách ngắt kết nối, các luồng của máy khách sẽ được đưa vào bộ đệm nếu có ít hơn luồng thread_cache_size ở đó. Yêu cầu cho các luồng được đáp ứng bằng cách sử dụng lại các luồng lấy từ bộ đệm nếu có thể và chỉ khi bộ nhớ cache trống thì một luồng mới được tạo. Biến này có thể được tăng lên để cải thiện hiệu suất nếu bạn có nhiều kết nối mới. Thông thường, điều này không cung cấp một sự cải thiện hiệu suất đáng chú ý nếu bạn có một triển khai luồng tốt. Tuy nhiên, nếu máy chủ của bạn thấy hàng trăm kết nối mỗi giây, thông thường bạn nên đặt thread_cache_size đủ cao để hầu hết các kết nối mới sử dụng các chuỗi được lưu trong bộ nhớ cache. Bằng cách kiểm tra sự khác biệt giữa các biến trạng thái Connections và Threads_create, bạn có thể thấy bộ đệm luồng hiệu quả như thế nào. Sử dụng công thức được nêu trong tài liệu, 8 + (max_connections / 100) là đủ tốt.

query_cache_size

Đối với một số thiết lập, biến này là kẻ thù tồi tệ nhất của họ. Đối với một số hệ thống chịu tải cao và bận rộn với số lần đọc cao, biến này sẽ khiến bạn sa lầy. Đã có những điểm chuẩn đã được kiểm tra và thử nghiệm tốt bởi Percona. Biến này cũng phải được đặt thành 0 cùng với query_cache_type =0 để tắt nó đi. Tin tốt trong MySQL 8.0 là Nhóm MySQL đã ngừng hỗ trợ điều này, vì biến này thực sự có thể gây ra các vấn đề về hiệu suất. Tôi phải đồng ý trên blog của họ rằng nó không có khả năng cải thiện khả năng dự đoán về hiệu suất. Nếu bạn muốn sử dụng bộ nhớ đệm truy vấn, tôi khuyên bạn nên sử dụng Redis hoặc ProxySQL.

Công cụ lưu trữ - InnoDB

InnoDB là một công cụ lưu trữ tuân thủ ACID với nhiều tính năng khác nhau để cung cấp cùng với hỗ trợ khóa ngoại (Tính toàn vẹn tham chiếu khai báo). Điều này có rất nhiều điều để nói ở đây nhưng một số biến cần xem xét để điều chỉnh:

innodb_buffer_pool_size

Biến này hoạt động giống như một bộ đệm chính của MyISAM nhưng nó có rất nhiều thứ để cung cấp. Vì InnoDB chủ yếu dựa vào vùng đệm, bạn sẽ cân nhắc đặt giá trị này thường thành 70% -80% bộ nhớ máy chủ của mình. Điều thuận lợi là bạn có không gian bộ nhớ lớn hơn tập dữ liệu của mình và đặt giá trị cao hơn cho vùng đệm của bạn nhưng không quá nhiều. Trong ClusterControl, điều này có thể được theo dõi bằng cách sử dụng Bảng điều khiển của chúng tôi -> Chỉ số InnoDB -> Đồ thị nhóm trang bộ đệm InnoDB. Bạn cũng có thể giám sát điều này với HIỂN THỊ TRẠNG THÁI TOÀN CẦU bằng cách sử dụng các biến Innodb_buffer_pool_pages *.

innodb_buffer_pool_instances

Đối với khối lượng công việc đồng thời của bạn, việc đặt biến này có thể cải thiện tính đồng thời và giảm bớt sự tranh cãi khi các chuỗi đọc / ghi khác nhau vào các trang được lưu trong bộ nhớ cache. Số innodb_buffer_pool_instances tối thiểu phải nằm trong khoảng từ 1 (tối thiểu) đến 64 (tối đa). Mỗi trang được lưu trữ trong hoặc đọc từ vùng đệm được gán ngẫu nhiên cho một trong các trường hợp vùng đệm, sử dụng hàm băm. Mỗi vùng đệm quản lý danh sách miễn phí, danh sách tuôn ra, LRU và tất cả các cấu trúc dữ liệu khác được kết nối với vùng đệm và được bảo vệ bởi mutex vùng đệm riêng của nó. Lưu ý rằng tùy chọn này chỉ có hiệu lực khi innodb_buffer_pool_size> =1GiB và kích thước của nó được chia cho các trường hợp vùng đệm.

innodb_log_file_size

Biến này là tệp nhật ký trong một nhóm nhật ký. Kích thước kết hợp của tệp nhật ký (innodb_log_file_size * innodb_log_files_in_group) không được vượt quá giá trị tối đa nhỏ hơn 512GB một chút. Theo Vadim, kích thước tệp nhật ký lớn hơn sẽ tốt hơn cho hiệu suất, nhưng nó có một nhược điểm (một nhược điểm đáng kể) mà bạn cần lo lắng:thời gian khôi phục sau sự cố. Bạn cần cân bằng thời gian khôi phục trong trường hợp hiếm khi khôi phục sự cố với việc tối đa hóa thông lượng trong các hoạt động cao điểm. Hạn chế này có thể chuyển thành quá trình khôi phục sự cố dài hơn 20 lần!

Để giải thích rõ hơn, giá trị lớn hơn sẽ tốt cho nhật ký giao dịch InnoDB và rất quan trọng để có hiệu suất ghi tốt và ổn định. Giá trị càng lớn, hoạt động xả điểm kiểm tra càng ít được yêu cầu trong vùng đệm, tiết kiệm I / O đĩa. Tuy nhiên, quá trình khôi phục diễn ra khá chậm khi cơ sở dữ liệu của bạn bị tắt bất thường (sự cố hoặc bị chết, OOM hoặc vô tình). Lý tưởng nhất là bạn có thể có 1-2GiB trong quá trình sản xuất nhưng tất nhiên bạn có thể điều chỉnh điều này. Đo điểm chuẩn những thay đổi này có thể là một lợi thế lớn để xem nó hoạt động như thế nào, đặc biệt là sau khi gặp sự cố.

innodb_log_buffer_size

Để lưu I / O đĩa, InnoDB’s ghi dữ liệu thay đổi vào bộ đệm lt’s log và nó sử dụng giá trị innodb_log_buffer_size có giá trị mặc định là 8MiB. Điều này đặc biệt có lợi cho các giao dịch lớn vì nó không cần ghi nhật ký thay đổi vào đĩa trước khi cam kết giao dịch. Nếu lưu lượng ghi của bạn quá cao (chèn, xóa, cập nhật), việc làm cho bộ đệm lớn hơn sẽ tiết kiệm I / O đĩa.

innodb_flush_log_at_trx_commit

Khi innodb_flush_log_at_trx_commit được đặt thành 1, bộ đệm nhật ký được xóa trên mọi cam kết giao dịch với tệp nhật ký trên đĩa và cung cấp tính toàn vẹn dữ liệu tối đa nhưng nó cũng có tác động đến hiệu suất. Đặt nó thành 2 có nghĩa là bộ đệm nhật ký được chuyển vào bộ đệm tệp hệ điều hành trên mọi cam kết giao dịch. Hàm ý của 2 là tối ưu và cải thiện hiệu suất nếu bạn có thể nới lỏng các yêu cầu về ACID của mình và có thể đủ khả năng để mất các giao dịch trong một hoặc hai giây cuối cùng trong trường hợp hệ điều hành gặp sự cố.

innodb_thread_concurrency

Với những cải tiến đối với công cụ InnoDB, bạn nên cho phép công cụ điều khiển đồng thời bằng cách giữ nó ở giá trị mặc định (bằng 0). Nếu bạn thấy các vấn đề về đồng thời, bạn có thể điều chỉnh biến này. Giá trị được khuyến nghị là 2 lần số CPU cộng với số đĩa. Đó là biến động có nghĩa là nó có thể đặt mà không cần khởi động lại máy chủ MySQL.

innodb_flush_method

Mặc dù vậy, biến này phải được thử và kiểm tra trên phần cứng nào phù hợp với bạn nhất. Nếu bạn đang sử dụng RAID có bộ nhớ đệm được hỗ trợ bằng pin, DIRECT_IO sẽ giúp giảm áp lực vào / ra. I / O trực tiếp không được lưu trong bộ đệm nên nó tránh được bộ đệm kép với vùng đệm và bộ đệm hệ thống tập tin. Nếu đĩa của bạn được lưu trữ trong SAN, O_DSYNC có thể nhanh hơn đối với khối lượng công việc đọc nhiều với hầu hết các câu lệnh SELECT.

innodb_file_per_table

innodb_file_per_table được BẬT theo mặc định từ MySQL 5.6. Điều này thường được khuyến nghị vì nó tránh có một không gian bảng được chia sẻ lớn và vì nó cho phép bạn lấy lại không gian khi bạn bỏ hoặc cắt bớt một bảng. Không gian bảng riêng biệt cũng mang lại lợi ích cho lược đồ sao lưu một phần Xtrabackup.

innodb_stats_on_metadata

Điều này cố gắng giữ cho phần trăm trang bẩn được kiểm soát và trước khi có plugin Innodb, đây thực sự là cách duy nhất để điều chỉnh xả bộ đệm bẩn. Tuy nhiên, tôi đã thấy các máy chủ có 3% bộ đệm bẩn và chúng đang đạt độ tuổi điểm kiểm tra tối đa. Cách này làm tăng khả năng xả bộ đệm bẩn cũng không mở rộng quy mô tốt trên các hệ thống con io cao, nó chỉ tăng gấp đôi lượng xả bộ đệm bẩn mỗi giây khi% trang bẩn vượt quá số lượng này.

innodb_io_capacity

Cài đặt này, bất chấp tất cả hy vọng lớn lao của chúng tôi rằng nó sẽ cho phép Innodb sử dụng tốt hơn IO của chúng tôi trong mọi hoạt động, chỉ cần kiểm soát lượng trang bẩn xả ra mỗi giây (và các tác vụ nền khác như đọc trước). Làm cho điều này lớn hơn, bạn tuôn ra nhiều hơn mỗi giây. Điều này không thích ứng, nó chỉ đơn giản là lặp lại nhiều lần mỗi giây nếu có bộ đệm bẩn cần xả. Nó sẽ loại bỏ hiệu quả bất kỳ sự tối ưu hóa nào của hợp nhất IO nếu bạn có khối lượng công việc ghi đủ thấp (nghĩa là các trang bẩn bị xóa gần như ngay lập tức, chúng tôi có thể tốt hơn nếu không có nhật ký giao dịch trong trường hợp này). Nó cũng có thể nhanh chóng làm đói dữ liệu đọc và ghi vào nhật ký giao dịch nếu bạn đặt mức này quá cao.

innodb_write_io_threads

Kiểm soát số lượng luồng sẽ được ghi vào đĩa. Tôi không chắc tại sao điều này vẫn hữu ích nếu bạn có thể sử dụng AIO gốc Linux. Những điều này cũng có thể trở nên vô dụng bởi các hệ thống tệp không cho phép ghi song song vào cùng một tệp bởi nhiều hơn một chuỗi (đặc biệt nếu bạn có tương đối ít bảng và / hoặc sử dụng không gian bảng chung)

innodb_adaptive_flushing

Chỉ định xem có tự động điều chỉnh tốc độ xả các trang bẩn trong vùng đệm InnoDB dựa trên khối lượng công việc hay không. Điều chỉnh tốc độ xả động nhằm mục đích tránh bùng nổ hoạt động I / O. Thông thường, điều này được bật theo mặc định. Biến này, khi được bật, sẽ cố gắng thông minh hơn trong việc xả mạnh hơn dựa trên số lượng trang bẩn và tốc độ tăng nhật ký giao dịch.

innodb_dedicated_server

Biến này là mới trong MySQL 8.0, được áp dụng trên toàn cầu và yêu cầu khởi động lại MySQL vì nó không phải là một biến động. Tuy nhiên, như tài liệu nói rằng biến này chỉ được bật nếu MySQL của bạn đang chạy trên một máy chủ chuyên dụng. Nếu không, không bật tính năng này trên máy chủ được chia sẻ hoặc chia sẻ tài nguyên hệ thống với các ứng dụng khác. Khi điều này được bật, InnoDB sẽ thực hiện cấu hình tự động cho lượng bộ nhớ được phát hiện cho các biến innodb_buffer_pool_size, innodb_log_file_size, innodb_flush_method. Nhược điểm duy nhất là bạn không thể có tính khả thi để áp dụng các giá trị mong muốn của mình trên các biến đã phát hiện được đề cập.

MyISAM

key_buffer_size

InnoDB là công cụ lưu trữ mặc định hiện nay của MySQL, mặc định cho key_buffer_size có thể được giảm trừ khi bạn đang sử dụng MyISAM một cách hiệu quả như một phần của ứng dụng của mình (nhưng ai sử dụng MyISAM trong sản xuất bây giờ?). Ở đây, tôi khuyên bạn nên đặt có lẽ 1% RAM hoặc 256 MiB khi bắt đầu nếu bạn có bộ nhớ lớn hơn và dành bộ nhớ còn lại cho bộ nhớ đệm hệ điều hành và vùng đệm InnoDB của bạn.

Các điều khoản khác cho hiệu suất

slow_query_log

Tất nhiên, biến này không giúp tăng cường máy chủ MySQL của bạn. Tuy nhiên, biến này có thể giúp bạn phân tích các truy vấn hoạt động chậm. Giá trị có thể được đặt thành 0 hoặc TẮT để tắt ghi nhật ký. Đặt nó thành 1 hoặc ON để kích hoạt tính năng này. Giá trị mặc định phụ thuộc vào việc tùy chọn --slow_query_log có được cung cấp hay không. Điểm đến cho đầu ra nhật ký được điều khiển bởi biến hệ thống log_output; nếu giá trị đó là KHÔNG, không có mục nhập nhật ký nào được ghi ngay cả khi nhật ký được bật. Bạn có thể đặt tên tệp hoặc đích của tệp nhật ký truy vấn bằng cách đặt biến slow_query_log_file.

long_query_time

Nếu một truy vấn kéo dài hơn nhiều giây này, máy chủ sẽ tăng biến trạng thái Slow_queries. Nếu nhật ký truy vấn chậm được bật, truy vấn sẽ được ghi vào tệp nhật ký truy vấn chậm. Giá trị này được đo theo thời gian thực, không phải thời gian CPU, vì vậy truy vấn nằm dưới ngưỡng trên hệ thống được tải nhẹ có thể cao hơn ngưỡng trên hệ thống được tải nhiều. Giá trị mặc định và tối thiểu của long_query_time lần lượt là 0 và 10. Cũng xin lưu ý rằng nếu biến min_examined_row_limit được đặt> 0, nó sẽ không ghi lại các truy vấn ngay cả khi mất quá nhiều thời gian nếu số hàng được trả về ít hơn giá trị được đặt trong min_examined_row_limit.

Để biết thêm thông tin về cách điều chỉnh ghi nhật ký truy vấn chậm của bạn, hãy xem tài liệu tại đây.

sync_binlog

Biến này kiểm soát tần suất MySQL sẽ đồng bộ hóa các binlog vào đĩa. Theo mặc định (> =5.7.7), giá trị này được đặt thành 1 có nghĩa là nó sẽ đồng bộ hóa với đĩa trước khi các giao dịch được cam kết. Tuy nhiên, điều này có tác động tiêu cực đến hiệu suất do số lần ghi tăng lên. Nhưng đây là cài đặt an toàn nhất nếu bạn muốn tuân thủ nghiêm ngặt ACID cùng với nô lệ của mình. Ngoài ra, bạn có thể đặt giá trị này thành 0 nếu bạn muốn tắt đồng bộ hóa đĩa và chỉ cần dựa vào Hệ điều hành để chuyển bản ghi nhị phân vào đĩa theo thời gian. Đặt nó cao hơn 1 có nghĩa là binlog được đồng bộ hóa với đĩa sau khi N nhóm cam kết nhật ký nhị phân đã được thu thập, trong đó N là> 1.

Kết xuất / Khôi phục Nhóm đệm

Một điều khá phổ biến là cơ sở dữ liệu sản xuất của bạn cần phải khởi động lại từ một lần khởi động / khởi động lại nguội. Bằng cách kết xuất vùng đệm hiện tại trước khi khởi động lại, nó sẽ lưu nội dung từ vùng đệm và khi nó hoạt động, nó sẽ tải lại nội dung vào vùng đệm .. Do đó, điều này tránh phải làm nóng cơ sở dữ liệu của bạn trở lại bộ nhớ cache. Hãy lưu ý rằng, phiên bản này đã được giới thiệu vào năm 5.6 nhưng Percona Server 5.5 đã có sẵn nó, đề phòng trường hợp bạn thắc mắc. Để bật tính năng này, hãy đặt cả hai biến innodb_buffer_pool_dump_at_shutdown =ON và innodb_buffer_pool_load_at_startup =ON.

Phần cứng

Bây giờ chúng ta đang ở trong năm 2019, đã có rất nhiều cải tiến phần cứng mới. Thông thường, không có yêu cầu cứng nào rằng MySQL sẽ yêu cầu một phần cứng cụ thể, nhưng điều này phụ thuộc vào những gì bạn cần cơ sở dữ liệu để thực hiện. Tôi mong rằng bạn sẽ không đọc blog này vì bạn đang kiểm tra xem blog có chạy trên Intel Pentium 200 MHz hay không.

Đối với CPU, bộ xử lý nhanh hơn với nhiều lõi sẽ tối ưu cho MySQL trong hầu hết các phiên bản gần đây nhất, ít nhất là kể từ phiên bản 5.6. Bộ xử lý Xeon / Itanium của Intel có thể đắt tiền nhưng được thử nghiệm cho các nền tảng máy tính có thể mở rộng và đáng tin cậy. Amazon đã vận chuyển các phiên bản EC2 của họ chạy trên kiến ​​trúc ARM. Mặc dù cá nhân tôi chưa thử chạy hoặc nhớ lại việc chạy MySQL trên kiến ​​trúc ARM, nhưng có những điểm chuẩn đã được thực hiện từ nhiều năm trước. CPU hiện đại có thể điều chỉnh tần số của chúng lên và xuống dựa trên các chính sách nhiệt độ, tải và tiết kiệm năng lượng của hệ điều hành. Tuy nhiên, có khả năng cài đặt CPU của bạn trong Hệ điều hành Linux của bạn được đặt thành một thống đốc khác. Bạn có thể kiểm tra điều đó hoặc thiết lập với thống đốc "hiệu suất" bằng cách thực hiện như sau:

echo performance | sudo tee /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor

Đối với Bộ nhớ, điều rất quan trọng là bộ nhớ của bạn phải lớn và có thể tương đương với kích thước của tập dữ liệu của bạn. Đảm bảo rằng bạn có swappiness =1. Bạn có thể kiểm tra bằng cách kiểm tra sysctl hoặc kiểm tra tệp trong procfs. Điều này đạt được bằng cách làm như sau:

$ sysctl -e vm.swappiness
vm.swappiness = 1

Hoặc đặt nó thành giá trị 1 như sau

$ sudo sysctl vm.swappiness=1
vm.swappiness = 1

Một điều tuyệt vời khác cần xem xét để quản lý bộ nhớ của bạn là xem xét việc tắt THP (Transparrent Huge Pages). Trước đây, tôi nhớ lại rằng chúng tôi đã gặp phải một số vấn đề kỳ lạ với việc sử dụng CPU và nghĩ rằng đó là do I / O đĩa. Hóa ra, vấn đề là với luồng nhân khugepaged phân bổ bộ nhớ động trong thời gian chạy. Không chỉ vậy, trong quá trình chống phân mảnh kernel, bộ nhớ của bạn sẽ nhanh chóng được cấp phát khi nó chuyển cho THP. Bộ nhớ HugePages tiêu chuẩn được cấp phát trước khi khởi động và không thay đổi trong thời gian chạy. Bạn có thể xác minh và tắt tính năng này bằng cách làm như sau:

$ cat /sys/kernel/mm/transparent_hugepage/enabled
$ echo "never" > /sys/kernel/mm/transparent_hugepage/enabled

Đối với Disk, điều quan trọng là bạn phải có thông lượng tốt. Sử dụng RAID10 là cách thiết lập tốt nhất cho cơ sở dữ liệu có bộ dự phòng pin. Với sự ra đời của ổ đĩa flash cung cấp thông lượng đĩa cao và I / O đĩa cao để đọc / ghi, điều quan trọng là nó có thể quản lý việc sử dụng đĩa cao và I / O đĩa.

Hệ điều hành

Hầu hết các hệ thống sản xuất chạy trên MySQL đều chạy trên Linux. Đó là bởi vì MySQL đã được kiểm tra và đánh giá chuẩn trên Linux, và nghe có vẻ đó là tiêu chuẩn thực tế để cài đặt MySQL. Tuy nhiên, tất nhiên, không có gì ngăn cản bạn sử dụng nó trên nền tảng Unix hoặc Windows. Sẽ dễ dàng hơn nếu nền tảng của bạn đã được thử nghiệm và có một cộng đồng rộng rãi để giúp đỡ, trong trường hợp bạn gặp một số rắc rối. Hầu hết các thiết lập chạy trên hệ thống RHEL / Centos / Fedora và Debian / Ubuntu. Trong AWS, Amazon có Amazon Linux của họ mà tôi thấy cũng được một số người sử dụng trong sản xuất.

Điều quan trọng nhất cần xem xét khi thiết lập là hệ thống tệp của bạn đang sử dụng XFS hoặc Ext4. Chắc chắn, có những ưu và nhược điểm giữa hai hệ thống tệp này nhưng tôi sẽ không đi đến chi tiết ở đây. Một số người nói rằng XFS tốt hơn Ext4 nhưng cũng có báo cáo rằng Ext4 làm tốt hơn XFS. ZFS cũng sắp ra mắt như một ứng cử viên sáng giá cho một hệ thống tệp thay thế. Jervin Real (từ Percona) có một tài nguyên tuyệt vời về tài nguyên này, bạn có thể kiểm tra bản trình bày này trong hội nghị ZFS.

Liên kết bên ngoài

https://developer.okta.com/blog/2015/05/22/tcmalloc

https://www.percona.com/blog/2012/07/05/impact-of-memory-allocators-on-mysql-performance/

https://www.percona.com/live/18/sessions/benchmark-noise-reduction-how-to-configure-your-machines-for-stable-results

https://zfs.datto.com/2018_slides/real.pdf

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/ladbi/disabling-transparent-hugepages.html#GUID-02E9147D-D565-4AF8-B12A-8E6E9F74BEEA