ĐẶT HÀNG theo hiệu suất MySQL

Điều chỉnh hiệu suất MySQL phụ thuộc vào một số yếu tố. Đối với một điều, MySQL chạy trên các hệ điều hành khác nhau. Mặt khác, có nhiều công cụ lưu trữ và định dạng tệp khác nhau — mỗi công cụ có sắc thái riêng. Trong hướng dẫn này, bạn sẽ học cách cải thiện hiệu suất MYSQL. Nhưng trước tiên, bạn cần thu hẹp vấn đề xuống MySQL

Giả sử Retrace đang báo cáo một trang chậm trên một trong các trang web của bạn. Bạn đã theo dõi trang đó trong Truy xuất và bạn có thể thấy rằng đó chắc chắn là lệnh gọi MySQL hoạt động kém. Bây giờ bạn đã biết cách cải thiện các vấn đề về hiệu suất của MySQL nhưng có thể bạn không biết bắt đầu từ đâu. Vì vậy, hãy bắt đầu từ đầu với những điều cơ bản

Mẹo. Tìm lỗi ứng dụng và các vấn đề về hiệu suất ngay lập tức với Stackify Retrace

Khắc phục sự cố và tối ưu hóa mã của bạn thật dễ dàng với các lỗi tích hợp, nhật ký và thông tin chi tiết về hiệu suất cấp mã

MySQL là gì

MySQL là một cơ sở dữ liệu quan hệ. Các bảng của bạn cần được tổ chức hợp lý để cải thiện nhu cầu hiệu suất MYSQL. Để hiểu điều này có nghĩa là gì, bạn phải hiểu cơ chế lưu trữ và lập chỉ mục cơ bản. Hãy bắt đầu bằng cách xem dữ liệu tồn tại trên đĩa như thế nào

Dữ liệu trên đĩa

MySQL lưu trữ dữ liệu trong các bảng trên đĩa. Tất nhiên, có những ngoại lệ, chẳng hạn như các bảng tạm thời trong bộ nhớ. Và các công cụ lưu trữ khác nhau tổ chức dữ liệu theo những cách khác nhau. Vì InnoDB là công cụ lưu trữ mặc định và đã có từ năm 2010 nên chúng tôi sẽ tiếp tục tập trung thảo luận vào đó. Điều đáng nói là InnoDB tự hào có một số cải tiến hiệu suất so với người tiền nhiệm của nó, MyISAM. Nếu bạn có thể chuyển từ MyISAM sang InnoDB, đặc biệt đối với các bảng lớn, rộng, bạn sẽ nhận thấy hiệu suất được cải thiện

Chỉ số nhóm

InnoDB lưu trữ dữ liệu trong một chỉ mục được nhóm. Một chỉ mục nhóm sắp xếp dữ liệu trên đĩa theo một hoặc nhiều cột của bảng, được gọi là khóa chính

Ví dụ: lấy một bảng có hai cột. id và tên. Bạn có thể xác định bảng có id làm khóa chính. Nếu nó được tạo tự động bằng tùy chọn auto_increment, thì mỗi hàng được chèn sẽ nằm ở cuối chỉ mục được nhóm như thế này

id | name
1 | ...
2 | ...
3 | ...
...
4396 | 'Zak'
4397 | 'Fred'
^ inserted ('Fred')

Fred được thêm vào cuối bảng và có id tiếp theo sau Zak. Nhưng, nếu chúng ta cần chèn một bản ghi vào giữa thì sao? . Bước đầu tiên để hiểu điều này là hiểu các trang

trang

Chỉ mục nhóm được chia thành các trang—các khối không gian liên tiếp trên đĩa. Theo mặc định, 16 kilobyte dữ liệu có thể được lưu trữ trong một trang của chỉ mục nhóm InnoDB. InnoDB tổ chức các trang thành một cây B+ (dấu + có nghĩa là các nút lá trỏ tới các nút lân cận của chúng)

Các giá trị lớn được lưu trữ ngoài trang ở một vị trí khác. Lưu trữ các giá trị lớn ngoài trang giúp tiết kiệm không gian và thời gian trong chỉ mục được nhóm. Tuy nhiên, làm như vậy có thể làm chậm hiệu suất nếu bạn đang tìm kiếm thông qua các giá trị lớn đó—và ngay cả khi bạn không. Vì vậy, có thể tốt hơn nếu sử dụng một bảng khác cho các đối tượng lớn hơn

Mục đích của trang là cho phép không gian để chèn dữ liệu trong tương lai. Để đạt được kỳ tích này, InnoDB cố gắng để trống 1/16 trang cho các lần chèn sau. Tuy nhiên, nếu bạn chèn không theo thứ tự (dựa trên khóa chính), nó sẽ chiếm 1/2 đến 1/16 trang. Những khoảng trống này trên trang giúp giữ dữ liệu theo thứ tự

Đĩa phải tìm thông qua các bản ghi để định vị dữ liệu. Khi bạn có một ổ đĩa cứng (HDD), điều này có nghĩa là quay các đĩa cứng và di chuyển các đầu đến vị trí. Nếu dữ liệu nằm rải rác trên đĩa, những người đứng đầu sẽ phải nhảy xung quanh để quét qua các bảng. Vì vậy, thứ tự các bảng trên đĩa là quan trọng

Nếu bạn lấp đầy một trang, InnoDB sẽ chia nó thành hai trang. Trang mới sẽ không theo thứ tự trên đĩa cho đến khi có thể xây dựng lại chỉ mục, việc này mất nhiều thời gian và không được thực hiện thường xuyên. Điều đó có nghĩa là việc đọc đĩa sẽ không còn xảy ra theo thứ tự đối với phần (phạm vi) dữ liệu đó

Còn ổ cứng thể rắn (SSD) thì sao?

Ổ cứng thể rắn

Sử dụng ổ đĩa nhanh hơn. SSD nhanh hơn nhiều so với HDD. Chúng sẽ có giá cao hơn, vì vậy nếu bạn có ý thức về chi phí, bạn có thể sử dụng hệ thống kết hợp. Đặt các bảng lớn được truy cập thường xuyên trên SSD cùng với chỉ mục của chúng. Sau đó, bạn có thể đặt các bảng nhỏ hơn và những thứ như bảng lưu trữ hoặc bảng kiểm toán trên đĩa cứng

Nếu bạn thực sự muốn tìm hiểu về SSD, bài viết này sẽ cung cấp thông tin chi tiết về công nghệ. Các mô hình chuyên nghiệp sử dụng các ô đơn cấp (SLC), nghĩa là chỉ có một bóng bán dẫn trên mỗi ô. SSD cấp tiêu dùng có nhiều bóng bán dẫn hơn trên mỗi tế bào và không nhanh hoặc bền

Nhưng nói về ổ đĩa đủ rồi, hãy quay lại với những thứ mà bạn với tư cách là một lập trình viên có nhiều quyền kiểm soát hơn

khóa chính

Chúng tôi đã cung cấp đủ thông tin về cách tổ chức dữ liệu trên đĩa để bắt đầu nói về điều gì đó thực sự hữu ích. lựa chọn khóa chính. Khi chọn khóa chính, bạn cần hiểu dữ liệu của mình sẽ được sử dụng như thế nào. Có một số quy tắc về khóa chính sẽ ảnh hưởng đến lựa chọn của bạn

Đối với một điều, khóa chính phải là một giá trị duy nhất. Bạn không thể chọn một khóa chính có nhiều hàng có cùng (các) giá trị, chẳng hạn như họ và tên. Mặt khác, nó không thể có giá trị null. Khóa chính phải là duy nhất và không rỗng. Chèn một hàng có giá trị null hoặc giá trị trùng lặp và thay vào đó, bạn sẽ gặp lỗi. Vì vậy, hãy lựa chọn một cách khôn ngoan. Nhưng bằng cách nào?

Chọn đúng phím

Bạn muốn chọn một khóa chính được sử dụng phổ biến nhất trong các truy vấn quan trọng nhất. Khi không có khóa duy nhất, bạn có thể thêm cột id tăng tự động vào bảng. Đây là một tài liệu tham khảo hữu ích cho các bảng liên quan cũng như con người. Bạn cũng có thể để InnoDB thêm một ẩn cho bạn. Nó có thể tự làm điều đó, nếu bạn không xác định khóa chính

Với các loại khóa chính khác, bạn cần ghi nhớ hai điều

1. Khóa chính nên ngắn. Điều này sẽ tiết kiệm không gian trong các chỉ mục khác tham chiếu hàng và các chỉ mục nhỏ hơn có thể được truy cập nhanh hơn
2. Khóa chính phải bao gồm một giá trị được lọc thường xuyên. Sử dụng thứ gì đó thường xuyên được truy vấn, chẳng hạn như tên người dùng, sẽ mang lại cho bạn hiệu suất tối ưu

Và cùng với đó, đây là một số cân nhắc khác cho các khóa chính

Sử dụng khóa tự nhiên

Khóa tự nhiên là một cột hoặc tổ hợp các cột tự nhiên là duy nhất và không rỗng. Nếu bạn có nhiều ứng cử viên, hãy sử dụng ứng cử viên sẽ hiển thị trong hầu hết các truy vấn

Ví dụ: nếu bạn có một bảng người dùng có cột tên người dùng, rất có thể bạn sẽ có nhiều truy vấn trên cột đó. Hãy nghĩ về truy vấn sau

SELECT name, points, email WHERE username = @username;

Truy vấn mẫu này sẽ được gọi bất cứ khi nào người dùng đăng nhập. Trong trường hợp này, bảng có thể được sắp xếp trên đĩa theo tên người dùng. Tên người dùng là khóa chính tự nhiên. Tuy nhiên, hãy nhớ rằng một varchar sẽ chiếm nhiều không gian hơn, đặc biệt nếu bạn đang sử dụng một bộ ký tự sử dụng nhiều hơn hai bit. Ngoài ra, lưu ý rằng việc thay đổi loại khóa chính là một công việc tương đối lớn. Tất cả các tham chiếu khóa ngoại cũng phải được cập nhật. Liên kết với các loại không khớp chậm hơn so với liên kết với cùng loại. Đó là bởi vì MySQL phải chuyển đổi chúng để khớp

Sử dụng phím kết hợp

Khóa tổ hợp bao gồm nhiều cột tạo thành khóa chính. Nếu bạn sử dụng một phím kết hợp, hãy đảm bảo rằng bạn chọn một phím sẽ được sử dụng trong nhiều truy vấn. Nếu không, những nỗ lực, dung lượng ổ đĩa, bộ nhớ và sức mạnh xử lý của bạn sẽ bị lãng phí. Đây là một ví dụ về một phím kết hợp đang hoạt động

SELECT comment_text, timestamp WHERE username = @username AND post_id = @post_id;

Trong bảng nhận xét, tên người dùng, post_id và dấu thời gian được sử dụng làm khóa chính. Nhưng có một vấn đề. Họ không thực sự tạo ra chìa khóa tốt nhất. Đối với một điều, chìa khóa sẽ rộng. Điều này có nghĩa là nó sẽ chiếm nhiều dung lượng hơn trên đĩa và trong bất kỳ chỉ mục nào trên bảng và các khóa ngoại trỏ đến bảng này. Mặt khác, bạn sẽ có rất nhiều phần chèn vào giữa chỉ mục được nhóm. Điều này có nghĩa là các trang sẽ phải được chia nhỏ và chúng sẽ không kết thúc theo thứ tự tuần tự trên đĩa

Đây là thời điểm tốt để nói về lập chỉ mục ngoài khóa chính

Thêm chỉ mục khi cần thiết

Khi nói đến việc cải thiện hiệu suất MYSQL, miễn là bạn đã đặt các bảng của mình đúng vị trí, thì việc lập chỉ mục là rất quan trọng. Bây giờ chúng ta đã xem qua một số điều cơ bản, đã đến lúc tìm hiểu sâu hơn một chút về thế giới này

Bạn có thể tạo các chỉ mục phụ, như tên gọi của chúng, để cải thiện hiệu suất cho các truy vấn phổ biến hoặc hoạt động chậm. Không cần thiết phải lập chỉ mục cho một bảng nhỏ hơn, nhưng khi bạn có nhiều hàng, bạn bắt đầu nghĩ về loại điều này. Những cột nào được sử dụng trong các truy vấn hoạt động kém?

Đây là cách nó hoạt động. Giả sử chúng ta có một bảng với một số người dùng, như trước đây

CREATE TABLE users
(
    id INT UNSIGNED AUTO_INCREMENT,
    username VARCHAR(100),
    given_name VARCHAR(100),
    family_name VARCHAR(100),
    created_date_utc DATETIME,
    modify_date_utc DATETIME,
    stars MEDIUMINT UNSIGNED,
    PRIMARY KEY(id)
)

Bạn cũng có một số tính năng tìm kiếm cho phép người dùng tìm kiếm những người dùng khác. Tìm kiếm xem xét tên người dùng, tên_đã cho và tên_họ, vì vậy truy vấn của bạn có thể giống như thế này

SELECT username, given_name, family_name
FROM users
WHERE username LIKE @like_clause
    OR given_name LIKE @like_clause
    OR family_name LIKE @like_clause
LIMIT @page, @size;

Truy vấn này sẽ quét toàn bộ bảng, từng hàng, tìm kiếm kết quả phù hợp với @like_clause. Khi bạn có hàng triệu người dùng, việc này sẽ mất nhiều thời gian. Nó thậm chí còn tồi tệ hơn khi bạn cần trả về dữ liệu bổ sung cùng với kết quả từ các bảng khác. Ví dụ này quá đơn giản, nhưng thậm chí nó sẽ được hưởng lợi từ một chỉ mục. Hãy tạo một cái ngay bây giờ

CREATE INDEX users_given_name_IDX USING BTREE ON `_poc2`.users (given_name,family_name,username);

Và bây giờ, khi có chỉ mục, các tìm kiếm của chúng tôi sẽ hoạt động tốt hơn nhiều. Hãy nhớ rằng điều này áp dụng cho các bảng rất lớn vì MySQL sẽ thực hiện tốt các truy vấn đối với các bảng nhỏ hơn. Điều đó nói rằng, điều quan trọng là phải ghi nhớ chiều rộng bảng của bạn và kích thước loại dữ liệu. Cố gắng cải thiện hiệu suất MYSQL càng nhỏ càng tốt

Hãy suy nghĩ trước khi thêm các chỉ mục phụ vì mỗi chỉ mục phụ sẽ khiến các thao tác chèn và cập nhật hoạt động chậm hơn. Thêm vào đó, chúng chiếm nhiều dung lượng đĩa hơn. Thay vào đó, bạn có thể cấu trúc lại các bảng hiện có để cải thiện các truy vấn. Và, bạn sẽ thu được nhiều hơn từ bộ tái cấu trúc bên cạnh hiệu suất của một truy vấn

Sử dụng chỉ mục toàn văn để tìm kiếm

Nếu bạn đang thực hiện bất kỳ tìm kiếm nào mà @like_clause bắt đầu bằng ký tự đại diện, thì điều này sẽ làm chậm truy vấn của bạn một cách đáng kể. Bạn có thể chọn sử dụng chỉ mục toàn văn, nhưng chúng cũng không hoàn hảo. Thông thường, bạn cần ít nhất ba ký tự để thực hiện tìm kiếm. Nhưng nếu bạn đang tìm kiếm người dùng có họ “Li” thì sao? . Ví dụ: bạn có thể sử dụng thứ gì đó như Elaticsearch, sử dụng chỉ mục Lucene để tìm kiếm hiệu quả

Sau khi lập chỉ mục, bạn vẫn phải xem xét cách truy vấn của mình được cấu trúc. Cách bạn viết các truy vấn của mình tạo ra tất cả sự khác biệt khi cải thiện hiệu suất MYSQL. Truy vấn có cấu trúc kém có thể thực hiện chậm hơn hàng nghìn lần so với truy vấn được viết tốt

Điều chỉnh hiệu suất truy vấn MySQL

Mặc dù cấu trúc và lược đồ rất quan trọng đối với hiệu suất, nhưng cách bạn truy vấn dữ liệu cũng quan trọng không kém. Sự khác biệt giữa truy vấn tối ưu và dưới tối ưu có thể tạo ra sự khác biệt 1.000% về tốc độ và mức sử dụng tài nguyên. Không có gì tệ hơn việc tất cả các truy vấn khác phải đợi một truy vấn hoạt động kém trong khi máy chủ bị thiếu tài nguyên. Vì vậy, hãy xem nơi chúng ta có thể giải quyết việc điều chỉnh hiệu suất truy vấn trong MySQL

Các vấn đề cơ bản

Khi nói đến các truy vấn, có một số vấn đề cơ bản có thể dễ dàng tránh được. Trước khi đi vào một số chi tiết cụ thể như sắp xếp và tổng hợp các truy vấn con, tôi muốn đề cập đến một quy tắc ngón tay cái thực sự đơn giản. tránh áp dụng hàm cho mọi hàng trong bảng trong truy vấn

Nếu bạn phải áp dụng một chức năng, hãy làm như vậy sau khi lọc ra càng nhiều hàng không cần thiết càng tốt. Khi bạn thực sự nghĩ về nó, đây là nguyên tắc cơ bản của tất cả các tối ưu hóa hiệu suất. Đó là điều mà trình tối ưu hóa MySQL tìm cách thực hiện khi nó tạo một kế hoạch cho các truy vấn của bạn. Nhưng đôi khi nó cần sự giúp đỡ của bạn

Đặt bởi

Tin hay không tùy bạn, điều quan trọng là bạn sắp xếp các cột của mình như thế nào. Trước đó trong bài đăng này, bạn đã thấy rằng các chỉ mục tăng tốc truy vấn đối với các cột được lập chỉ mục. Họ cũng tăng tốc độ sắp xếp theo các cột được lập chỉ mục thường. Các chỉ mục chỉ được sắp xếp tăng dần. Điều đó không có nghĩa là bạn không thể tiến và lùi thông qua chỉ mục; . Nhưng bạn không thể đi qua những chiếc lá theo cả hai hướng cùng một lúc

Nói cách khác, việc sắp xếp sau sẽ diễn ra rất chậm vì nó phải sử dụng một filesort.

SELECT user, timestamp
FROM comments
ORDER BY user ASC,
    timestamp DESC;

Bạn có thể tự tìm hiểu. Tạo một bảng như thế này và điền vào đó hoặc sử dụng một bảng bạn đã có chứa nhiều hàng. Để thấy sự khác biệt trong cách trình tối ưu hóa truy vấn sẽ sắp xếp dữ liệu, hãy sử dụng GIẢI THÍCH trước truy vấn như thế này

EXPLAIN
SELECT user, timestamp
FROM comments
ORDER BY user ASC,
    timestamp DESC;

Điều đó sẽ giúp bạn có một kế hoạch truy vấn hiển thị các chỉ mục (nếu có) mà trình tối ưu hóa sẽ sử dụng cùng với bất kỳ thông tin “Bổ sung” nào. Phần "Thêm" có một số thông tin chính chứa manh mối về hiệu suất của truy vấn. “Sử dụng chỉ mục” là tốt. Nhưng, “Sử dụng chỉ mục; . Và đây chính xác là những gì bạn sẽ nhận được khi bạn không có các cột sắp xếp mục tiêu trong một chỉ mục hoặc khi bạn sắp xếp chúng theo hướng ngược lại

Để tận dụng tối đa tính năng sắp xếp, hãy đảm bảo các cột "thứ tự theo" được lập chỉ mục. Ngoài ra, hãy đảm bảo rằng bạn đang sắp xếp theo cùng một hướng nếu bạn đặt hàng theo nhiều cột

truy vấn phụ tổng hợp

Có một mẹo khác mà tôi muốn chia sẻ đã cải thiện đáng kể một truy vấn mà tôi đã điều chỉnh gần đây. Trong trường hợp này, tôi cần lấy dấu thời gian gần đây nhất của bản ghi liên quan

Chúng tôi có thể sử dụng người dùng và nhận xét làm ví dụ. Giả sử bạn muốn có một danh sách người dùng có thể phân trang trong một ứng dụng web. Chúng có thể được sắp xếp, phân trang và lọc theo một số tiêu chí hoặc các tiêu chí khác. Một trong các cột sẽ hiển thị ngày nhận xét gần đây nhất của người dùng

Có một số cách tiếp cận bạn có thể thực hiện để thực hiện điều này. Bạn có thể sử dụng truy vấn con trong phần chọn. Bạn có thể tham gia bảng nhận xét tổng hợp trong truy vấn con. Hoặc bạn có thể sử dụng truy vấn con tổng hợp trong câu lệnh chọn. Tham gia tổng hợp hoặc truy vấn con tổng hợp sẽ hoạt động tốt hơn trong hầu hết các trường hợp. Đây là một ví dụ về cách họ nhìn

Cái này sử dụng một truy vấn con tổng hợp (được gọi là “QUI CÁO PHỤ PHỤ THUỘC” theo đầu ra của trình tối ưu hóa). Truy vấn con tổng hợp đã tham gia sẽ hoạt động tốt hơn nữa, đặc biệt là khi bạn có nhiều người dùng hơn. Truy vấn đó sẽ trông như thế này

SELECT
    user,
    aggregate.latest_timestamp
FROM users
LEFT JOIN (
    SELECT
        user_id,
        MAX(timestamp) AS latest_timestamp
    FROM comments
    GROUP BY user_id
) aggregate
ON aggregate.user_id = users.id
ORDER BY username
LIMIT @i, @r;

Truy vấn con đã được chuyển sang liên kết bên trái (có thể không có bản ghi cho tất cả người dùng). Hãy nhớ đảm bảo rằng bạn có đúng chỉ mục, nếu không bạn sẽ vẫn thấy các vấn đề về hiệu suất

lưu hàng loạt

Mẹo cuối cùng để cải thiện hiệu suất MYSQL rất hữu ích khi bạn có nhiều bản ghi cần lưu. Đây có thể là danh sách các giá trị được phân tách bằng dấu phẩy (danh sách CSV) đến từ một tệp hoặc giao diện người dùng. Bạn có thể lặp lại danh sách và lưu từng bản ghi một truy vấn tại một thời điểm. Đây là một cách chậm và còn được gọi là RBAR (hàng theo hàng đau đớn)

Cách nhanh chóng là lưu tất cả chúng cùng một lúc—làm việc theo lô trong MySQL luôn nhanh hơn. Không có cách tích hợp nào để gửi một tập hợp các bản ghi đến một thủ tục được lưu trữ cùng một lúc. Nhưng có một cách giải quyết rắc rối nhưng hiệu quả. Bạn có thể chuyển danh sách CSV dưới dạng chuỗi và phân tích các giá trị thành bảng tạm thời. Sau đó, bảng tạm thời có thể được sử dụng để chèn hoặc cập nhật các bản ghi trong (các) bảng đích

Bạn sẽ cần tạo thủ tục được lưu trữ của riêng mình thành một bảng tạm thời. Nó thực sự phức tạp khi bạn cần lưu nhiều thuộc tính cho mỗi thực thể. Cách yêu thích của tôi để giải quyết vấn đề này là chuyển đổi danh sách CSV thành danh sách XML. Chỉ cần mã hóa từng thực thể thành XML và phân tách bằng dấu phân cách, chẳng hạn như dấu phẩy. Sau đó, sử dụng phiên bản đơn giản hơn của thủ tục được lưu trữ để ánh xạ nó vào bảng tạm thời. Tiếp theo, sử dụng hàm trong MySQL để lấy giá trị cho mỗi cột

Đây là một ví dụ mà chúng tôi đang tiết kiệm hai người dùng trong một cuộc gọi

SELECT name, points, email WHERE username = @username;

There is a limitation with this method. The “reverse_group_concat” procedure gets fairly costly as the string gets longer. Keeping your XML shorter by using single-letter node names will help. For example, “” becomes “” and “” becomes “”. This won’t eliminate the cost completely, but it’ll help. If you notice a significant slowdown after a certain number of records, splitting the save into batches will speed things up a bit. You may have five batch calls to make, but it beats 5,000 calls to do it row by agonizing row!

Tìm các truy vấn MySQL chậm trong Truy xuất

Tôi muốn chia sẻ một công cụ đảm bảo rằng bạn đang tìm kiếm các truy vấn MySQL chậm và có thể dễ dàng xác định các vấn đề. Giải pháp của Stackify, Retrace, chỉ cho bạn cách tìm các truy vấn chậm cũng như số lần truy vấn đã được thực thi và giao dịch nào đang gọi nó, đảm bảo bạn có tất cả thông tin chi tiết cần thiết để cải thiện hiệu suất MYSQL

Dễ dàng xem truy vấn SQL nào mất nhiều thời gian nhất

Với tất cả các số liệu thống kê cần cải thiện hiệu suất MYSQL ở một nơi, bạn có thể chỉ cần tìm kiếm các truy vấn cụ thể để tìm ra các sự cố tiềm ẩn

Bằng cách chọn một truy vấn riêng lẻ, bạn sẽ nhanh chóng nhận được thông tin chuyên sâu về tần suất truy vấn đó được gọi và thời gian thực hiện cũng như những trang web nào sử dụng truy vấn SQL và truy vấn đó ảnh hưởng như thế nào đến hiệu suất của chúng

Đừng hiểu ý tôi, chỉ cần tận dụng bản dùng thử Truy xuất miễn phí để tự mình xem

Nhận thêm trợ giúp ở đâu

Chúng tôi đã đề cập rất nhiều vấn đề khi nói đến việc cải thiện hiệu suất MYSQL, nhưng còn rất nhiều lĩnh vực khác cần thảo luận. Ví dụ: chúng tôi chưa nói nhiều về cấu hình. MySQL có khả năng cấu hình cao, nhưng hầu hết các vấn đề liên quan đến hiệu suất đều có thể được giải quyết bằng cách sử dụng cấu trúc bảng phù hợp, lập chỉ mục và tối ưu hóa các truy vấn

Tất nhiên, khi bạn thực sự cần tận dụng tối đa MySQL hoặc nếu bạn có quá nhiều dữ liệu đang hoạt động, bạn sẽ cần phải đi xa hơn. Phân vùng, quản lý không gian bảng, sử dụng các đĩa riêng biệt và bảo trì định kỳ sẽ là một yếu tố. Nếu bạn muốn biết thêm thông tin, các liên kết tài liệu MySQL bên dưới có rất nhiều câu trả lời cho những loại câu hỏi tinh chỉnh đó

• https. // nhà phát triển. mysql. com/doc/refman/8. 0/en/optimizing-innodb-diskio. html
• https. // nhà phát triển. mysql. com/doc/refman/5. 5/vi/sự cố đĩa. html
• https. // nhà phát triển. mysql. com/doc/refman/8. 0/en/innodb-buffer-pool. html

Trong thời gian chờ đợi, tôi hy vọng tôi đã cung cấp cho bạn một số ý tưởng để giải quyết tốt hơn các vấn đề về MySQL điều chỉnh hiệu suất hàng ngày của bạn