VietNetwork.Vn

1. Giới thiệu.

Sau khi cài đặt MySQL, bạn cần phải cấu hình nó. May mắn thay, bạn không cần phải cấu hình MySQL mỗi khi khởi động lại nó. Cấu hình của bạn được lưu trong một tập tin tùy chọn, tập tin này còn được gọi là tập tin cấu hình. Với những cấu hình này, bạn cần nghĩ đến hiệu suất của máy chủ. Hiệu suất máy chủ là điều tối quan trọng đối với một ứng dụng ổn định. Hiệu suất thúc đẩy lợi nhuận và năng suất cho một công ty, vì vậy bạn phải tinh chỉnh cơ sở dữ liệu MySQL của mình để có hiệu suất tối ưu. Bài viết này thảo luận về điều chỉnh hiệu suất và cấu hình cho máy chủ MySQL của bạn và cơ sở dữ liệu của nó.

2. Tập tin cấu hình của MySQL.

Tập tin cấu hình của MySQL có thể ngắn hoặc nhiều dòng tùy chọn, tùy thuộc vào số lượng cấu hình bạn đã đặt. Đối với các cài đặt máy chủ MySQL mới, nó nhỏ và phát triển khi bạn tiếp tục thêm các tùy chọn khác. Chúng ta sẽ thảo luận về một số cấu hình chính mà mỗi quản trị cơ sở dữ liệu nên biết.

Đầu tiên, bạn cần biết vị trí của tệp. Đối với Linux và Unix, tập tin được lưu trữ trong thư mục /etc/ hoặc SYSCONFDIR cho các tùy chọn chung. Các tùy chọn máy chủ cụ thể được lưu trữ trong thư mục $MYSQL_HOME và các cấu hình người dùng cụ thể được lưu trữ trong ~/ nơi ~/ là thư mục chính của người dùng.

Với Windows, bạn không cần phải tìm kiếm trong các thư mục để tìm các tập tin tùy chọn. Mở Dịch vụ từ phần Tùy chọn quản trị bảng điều khiển. Nhấp chuột phải vào dịch vụ MySQL và chọn "Thuộc tính". Trong đường dẫn thực thi, nó hiển thị vị trí của tập tin my.ini.

Bạn có thể mở các tập tin ini bằng bất kỳ trình soạn thảo văn bản nào. Tập tin cấu hình của có một số phần được đánh dấu trong ngoặc. Ví dụ: phần [mysql] có các cấu hình máy chủ cụ thể. Phần [client] được đặt cho các ứng dụng máy khách.

Định dạng là "configuration = value" trong đó giá trị là giá trị cấu hình của bạn. Cấu hình là biến cụ thể của MySQL mà bạn có thể đặt. Nếu bạn không đặt cấu hình, MySQL sẽ sử dụng giá trị mặc định của riêng nó.

3. Chúng ta hãy xem xét phần cấu hình client tiêu biểu.

[client]

port = 3306
Phần này có một biến có tên là cổng. Cổng là nơi các ứng dụng khách kết nối. Vì mục đích bảo mật, một số quản trị viên MySQL sử dụng một cổng không chuẩn cho các kết nối máy chủ MySQL. Lý do họ làm điều này là để tránh phát hiện ra máy chủ cơ sở dữ liệu từ máy quét cổng. Khi tin tặc quét các cổng cho các dịch vụ, chúng sẽ quét các cổng tiêu chuẩn. Tất nhiên, không có gì đảm bảo rằng tất cả tin tặc sẽ không bao giờ quét các cổng không chuẩn, nhưng việc di chuyển các dịch vụ cơ sở dữ liệu sang một cổng không chuẩn sẽ tránh bị phát hiện ra cơ sở dữ liệu cho các vụ hack không cụ thể. Trong ví dụ này, quản trị viên đặt cổng 3306 làm cổng kết nối máy khách MySQL, cổng này sẽ mở ra cho các kết nối cơ sở dữ liệu. Khi bạn nghe quản trị viên cơ sở dữ liệu đề cập đến cổng này, họ thường nói rằng máy chủ đang "lắng nghe" trên cổng này.

Bây giờ chúng ta hãy xem xét một phần dài hơn có tên [mysqld]. Phần này có các cấu hình dịch vụ cụ thể được đặt cho máy chủ cơ sở dữ liệu. Đây là phần cấu hình ví dụ cho mysqld.

[mysqld]

basedir="C:/Program Files/MySQL/MySQL Server 5.5/"

datadir="C:/Documents and Settings/All Users/Application Data/MySQL/MySQL Server 5.5/Data/"

default-storage-engine=INNODB

max_connections=341

query_cache_size=9M

table_cache=700
Bạn có thể có một số tùy chọn khác trong tệp, nhưng mình đang đề cập đến một số tùy chọn chính, phổ biến. Như bạn có thể quan sát, hệ thống cơ sở dữ liệu nằm trên máy chủ Windows theo định dạng của các thư mục lưu trữ. Biết cơ sở dữ liệu chạy trên máy chủ Windows giúp bạn khắc phục sự cố nếu bạn không thể giải quyết bất kỳ sự cố cụ thể nào về cấu hình.

Đầu tiên, bạn có biến "basedir". Đây là vị trí cài đặt dịch vụ. Bất kỳ thành phần cài đặt bổ sung nào đều sử dụng thư mục này, vì vậy hãy luôn giữ các tập tin cài đặt trong cấu trúc thư mục này. Đó cũng là vị trí của các tập tin hệ thống quan trọng. Nếu bạn di chuyển vị trí cài đặt MySQL của mình, thì bạn sẽ thay đổi giá trị này. Nếu bạn vô tình thay đổi thư mục này, nó có thể ảnh hưởng nghiêm trọng đến ứng dụng cơ sở dữ liệu của bạn.

Thứ hai, có biến "datadir". Đây là thư mục cho cơ sở dữ liệu biết nơi tìm tất cả các tập tin dữ liệu. Đây là gốc cơ bản của cơ sở dữ liệu và mọi thay đổi đối với giá trị này cần được thực hiện cẩn thận. Nếu bạn thay đổi vị trí, bạn phải chắc chắn rằng dữ liệu sẽ di chuyển theo vị trí đó.

Dòng tiếp theo là giá trị và biến "default-storage-engine". Nếu bạn nhớ lại từ các chương trước, mình đã đề cập rằng lệnh CREATE TABLE mặc định cho công cụ lưu trữ MyISAM. Với biến này, mình thay đổi loại công cụ lưu trữ mặc định. Đối với hầu hết các ứng dụng, bạn muốn đặt nó là InnoDB hoặc MyISAM. Đặt mặc định cho bất kỳ công cụ lưu trữ nào khác sẽ không khả thi đối với một ứng dụng đang hoạt động. Ví dụ: thay đổi mặc định thành loại công cụ lưu trữ lưu trữ có nghĩa là bạn sẽ không thể tạo khóa chính hoặc ghi giao dịch trên bảng của mình.

Biến tiếp theo là biến "max_connections". Giá trị này xác định số lượng người dùng có thể đồng thời kết nối với cơ sở dữ liệu MySQL của bạn. Nếu giá trị này quá nhỏ, bạn có nguy cơ chặn người dùng hợp pháp sử dụng ứng dụng. Tuy nhiên, quá nhiều người dùng đồng thời cũng có thể gây ra các vấn đề nghiêm trọng về hiệu suất trên cơ sở dữ liệu. Bạn luôn nên để lại các kết nối bổ sung nếu bạn không chắc chắn về lượng người dùng đồng thời cần thiết, nhưng đừng đánh giá quá cao giá trị này quá nhiều và làm mất hiệu suất.

Trong ví dụ này, mình đã sử dụng 341 kết nối đồng thời. Con số này không bao gồm người dùng superuser (hoặc người dùng root) có thể kết nối ngay cả khi đạt đến mức tối đa. Ví dụ: nếu cơ sở dữ liệu của bạn hiện có 341 kết nối và nó bắt đầu gặp sự cố, bạn phải có thể kết nối để khắc phục mọi sự cố. MySQL cho phép thêm 1 kết nối để giải quyết nhu cầu của quản trị viên kết nối trong trường hợp khẩn cấp ngay cả khi đã đạt đến giới hạn kết nối hiện tại.

Tùy chọn tiếp theo là "query_cache_size." Giá trị này giúp tăng tốc các câu lệnh SELECT thường được sử dụng. Ví dụ: giả sử bạn truy vấn cùng một câu lệnh Khách hàng và Đơn hàng. Trong một số phần của ứng dụng, bạn truy xuất danh sách khách hàng có các đơn đặt hàng được liên kết. Thay vì liên tục truy vấn các tập tin cơ sở dữ liệu để tìm các thay đổi, giá trị này lưu trữ các kết quả trong bộ nhớ cache. Ưu điểm là thời gian phản hồi nhanh hơn từ máy chủ MySQL đối với dữ liệu tĩnh. Giá trị này thực sự có thể là một bất lợi nếu dữ liệu bảng của bạn thay đổi thường xuyên. Bạn muốn lưu vào bộ nhớ cache các giá trị nhất quán giống nhau, nhưng hãy giảm bộ nhớ cache nếu dữ liệu bảng của bạn thay đổi thường xuyên. Ví dụ: bạn sẽ không lưu vào bộ nhớ cache các bảng kiểm tra của mình vì chúng thay đổi mỗi khi dữ liệu được thay đổi hoặc truy cập.

Biến cuối cùng trong ví dụ của mình là giá trị "table_cache". Giá trị này làm tăng số lượng mô tả bảng. Một lần nữa, giá trị này có thể cải thiện hiệu suất trên các bảng và truy vấn của bạn.

Trong một số trường hợp, tập tin tùy chọn chỉ chạy cho trường hợp cụ thể của bạn. Bạn có thể có cài đặt chung và cài đặt người dùng cụ thể. Bạn có thể sử dụng lệnh SHOW VARIABLES để xem danh sách các biến và giá trị liên quan đến phiên bản cụ thể.

4. Tối ưu hiệu suất Máy chủ cơ sở dữ liệu MySQL.

Các công ty khởi nghiệp và cơ sở dữ liệu nhỏ thường không cần điều chỉnh hiệu suất vì số lượng bảng và bản ghi nhỏ. Tuy nhiên, cơ sở dữ liệu lớn hơn có khối lượng hoạt động cao sẽ không thể tồn tại bất kỳ thay đổi nào nếu không có bất kỳ điều chỉnh hiệu suất nào. Mình đã đề cập đến các tập tin tùy chọn, vì các tùy chọn điều chỉnh hiệu suất này được đặt trong tập tin  cấu hình.
 
Trước khi bắt đầu điều chỉnh hiệu suất, bạn phải hoàn toàn chắc chắn rằng mỗi thay đổi có tác dụng gì. Bạn cũng nên lưu ý các khuyến nghị sau trước khi bắt đầu.

• Chỉ thay đổi một cài đặt tại một thời điểm, nếu bạn không chắc chắn về nguyên nhân gốc rễ của vấn đề hiệu suất. Ví dụ: nếu bạn có cơ sở dữ liệu MySQL chậm và bạn không biết nguyên nhân gốc rễ chính xác, hãy thay đổi từng cài đặt một. Điều này tránh thực hiện những thay đổi gây hại nhiều hơn lợi. Nó cũng cho phép bạn xác định chính xác nơi xảy ra sự cố.
• Bạn phải đặt các thay đổi vào phần bên phải. Mình đã đề cập trong phần trước rằng các tập tin cấu hình được phân đoạn thành các phần khác nhau. Các phần này xác định từng biến được phép. Nếu bạn đặt sai cấu hình và biến điều chỉnh trong phần sai, bạn sẽ không thấy bất kỳ thay đổi nào có hiệu lực.
• Nếu cơ sở dữ liệu MySQL của bạn không khởi động, bạn phải xem lại tập tin để tìm bất kỳ điểm nào không chính xác. Ví dụ: nếu bạn sử dụng megabyte cho một biến yêu cầu byte, nó có thể gây ra sự cố khi bạn khởi động lại dịch vụ. Điều này cũng xảy ra nếu bạn không đặt đúng cài đặt trong phần thích hợp.

Khi bạn biết chính xác cài đặt nào bạn cần thay đổi, bạn có thể xem lại tập tin cấu hình và chọn cài đặt phù hợp.

5. Hãy xem lại một số cài đặt cơ bản trước.

5.1. Biến innodb_buffer_pool_size.

Cài đặt này là tùy chọn điều chỉnh hiệu suất đầu tiên dành cho quản trị viên cơ sở dữ liệu sử dụng công cụ lưu trữ InnoDB. Như mình đã nhấn mạnh trong phần trước, bạn có thể lưu vào bộ đệm các truy vấn, bảng và các cấu trúc tập tin phổ biến khác. Mình đã đề cập đến một số bộ nhớ đệm truy vấn SELECT, nhưng mình không xem xét bất kỳ bộ nhớ đệm cụ thể của công cụ lưu trữ nào.

Cài đặt innodb_buffer_pool_size là cài đặt đầu tiên để điều chỉnh hiệu suất với InnoDB. Đây là kích thước vùng đệm cho dữ liệu và chỉ mục. Khi bạn lưu vào bộ nhớ cache các thuộc tính này, bạn sẽ cải thiện tốc độ mà cơ sở dữ liệu MySQL có thể truy cập và hiển thị dữ liệu cho người dùng của bạn. Bộ nhớ đệm lưu trữ dữ liệu và lập chỉ mục trong bộ nhớ, tốc độ đọc đĩa nhanh hơn nhiều. Giá trị bạn sử dụng phụ thuộc vào kích thước cơ sở dữ liệu của bạn. Bạn có thể sử dụng giá trị nhỏ nhất là 5GB và cao nhất là 128GB.

5.2. Biến innodb_log_file_size.

Cấu hình này kiểm soát kích thước của tập tin nhật ký, còn được gọi là "tập tin làm lại". Như tên cho thấy, tập tin nhật ký có thể được sử dụng để "làm lại" các giao dịch khi máy chủ MySQL của bạn gặp sự cố hoặc bị hỏng. Các tập tin nhật ký ghi lại từng phiên bản có thể ghi vào cơ sở dữ liệu, bao gồm các lệnh UPDATE, DELETE và INSERT. MySQL tiếp tục cải thiện hiệu suất tập tin nhật ký. Thông thường, nhiều tùy chọn khôi phục sự cố hơn gây ra hiệu suất chậm hơn, nhưng phiên bản MySQL mới nhất đã cải thiện hạn chế này.

Nếu bạn có một cơ sở dữ liệu nhỏ với ít giao dịch ghi, bạn có thể bắt đầu giá trị ở mức 512M. Nếu bạn có một ứng dụng MySQL cấp doanh nghiệp lớn, bạn có thể đặt giá trị này thành 4G.

5.3. Biến max_connections.

Mình đã đề cập đến biến này trong phần trước. Tuy nhiên, mình đã không truyền đạt tầm quan trọng của nó khi điều chỉnh hiệu suất máy chủ của bạn. Giá trị mặc định cho biến này là 151. Đối với hầu hết các công ty nhỏ, giá trị này là cài đặt phù hợp. Nhiều nhà phát triển ứng dụng không đóng được kết nối MySQL sau khi họ sử dụng xong. Điều này có nghĩa là máy chủ MySQL giữ kết nối mở ngay cả khi ứng dụng không sử dụng nó. Nếu ứng dụng mở quá nhiều kết nối, MySQL engine sẽ trả về lỗi "quá nhiều kết nối" cho ứng dụng. Điều này có nghĩa là mọi hoạt động hiện tại đều không thành công cho dù đó là đối với khách hàng hay nhân viên.

Bạn có thể tăng giá trị này để tránh những lỗi này. Tuy nhiên, quá nhiều kết nối mở đồng thời có thể dẫn đến các vấn đề về hiệu suất. Khi quá nhiều kết nối được mở, cơ sở dữ liệu MySQL sẽ không phản hồi và phải khởi động lại. Bạn nên làm việc với giá trị này để tìm ra tốc độ và hiệu suất phù hợp cho các truy vấn của mình mà không làm hỏng máy chủ hoặc cắt các ứng dụng mở quá nhiều kết nối cùng một lúc.

Các biến này là giá trị chung mà bạn có thể đặt cho máy chủ MySQL. Chúng ta hãy xem xét một số cài đặt cụ thể của InnoDB. Nếu bạn còn nhớ, InnoDB là một công cụ lưu trữ cơ sở dữ liệu tuân thủ ACID, cũng hỗ trợ các ràng buộc khôi phục, cam kết và khóa ngoại. Nếu bạn dựa vào tính toàn vẹn và chuẩn hóa dữ liệu trong cơ sở dữ liệu của mình, bạn có thể sử dụng công cụ lưu trữ InnoDB.

5.4. Biến innodb_flush_log_at_trx_commit.

Tuân thủ hoàn toàn ACID có lợi thế nếu bạn chỉ dựa vào tính toàn vẹn của dữ liệu và các thủ tục. Tuy nhiên, để có loại hệ thống bảo mật và khôi phục này phải trả giá bằng hiệu suất. Đặt giá trị này thành 1 làm cho cơ sở dữ liệu MySQL của bạn hoàn toàn tuân thủ ACID. Bạn thường có thể khôi phục bất kỳ lúc nào và khôi phục sau bất kỳ sự cố nào.

Bạn cũng có thể sử dụng giá trị là 2. Giá trị này làm cho máy chủ MySQL kém tin cậy hơn một chút, nhưng nó cải thiện hiệu suất nếu bạn nhận thấy rằng bạn không có hiệu suất tốt nhất cho ứng dụng của mình. Trong hầu hết các trường hợp, đây là một lựa chọn an toàn. Tùy chọn cuối cùng là 0. Đặt giá trị thành 0 sẽ cải thiện hiệu suất, nhưng bạn cũng có cơ hội mất một số dữ liệu nếu bạn cần khôi phục các giao dịch. Tùy chọn này ít được khuyến nghị nhất, nhưng nó có thể giúp tăng hiệu suất cho các máy chủ cần điều chỉnh hiệu suất rộng rãi.

5.5. Biến innodb_flush_method.
 
Biến này khó hiểu hơn một chút nếu bạn không quen với hiệu suất đĩa RAID. Giá trị mặc định là fdatasync. Phổ biến nhất là O_DIRECT. Giá trị này phổ biến khi bạn có thành phần bộ nhớ cache dự phòng pin. Cài đặt kiểm soát cách nhật ký được chuyển vào đĩa thay vì bộ nhớ. Trong hầu hết các trường hợp, giá trị O_DIRECT được sử dụng, vì vậy bạn nên thay đổi biến này từ mặc định của nó để đánh giá điều gì tốt nhất cho hiệu suất hệ thống của bạn.

5.6. Biến innodb_log_buffer_size.

Như tên gợi ý, biến này kiểm soát kích thước bộ đệm cho các tập tin nhật ký. Đối với cơ sở dữ liệu thông thường có lưu lượng truy cập ít, giá trị mặc định 1MB là đủ. Tuy nhiên, giá trị này nhỏ khi bạn có một số kiểu dữ liệu trường lớn chẳng hạn như các đốm màu. Bộ đệm đầy nhanh chóng và bạn không còn hiệu suất mà bạn cần. Nếu bạn có một số giao dịch ghi với giá trị kiểu dữ liệu lớn, bạn nên tăng giá trị của biến để trợ giúp hiệu suất.

5.7. Biến query_cache_size.

Biến này có lợi khi bạn có cùng một truy vấn chạy nhiều lần trong giờ. Tuy nhiên, nhiều quản trị viên cơ sở dữ liệu gợi ý rằng biến này là một điểm nghẽn đã biết và nên được thay đổi. Một số quản trị viên cơ sở dữ liệu đề nghị rằng nó nên được tắt hoàn toàn. Các phiên bản MySQL hiện tại vô hiệu hóa tùy chọn này theo mặc định. Tùy chọn biến này được sử dụng khi bạn không có chỉ mục tốt và các truy vấn được tối ưu hóa và cần một cách để khắc phục tình hình.

5.8. Biến log_bin.

Biến này được sử dụng khi bạn cần khôi phục kịp thời từ các tập tin nhật ký của mình. Nếu bạn sử dụng MySQL làm bản sao chính, thì bạn phải bật giá trị biến này. Khôi phục tại thời điểm xảy ra khi bạn mất dữ liệu hoặc dữ liệu bị hỏng xảy ra tại một thời điểm cụ thể. Khi bạn cần khôi phục sau sự cố tại một thời điểm cụ thể, bạn có thể sử dụng nhật ký nhị phân để khôi phục dữ liệu của mình.

Các tập tin này phát triển đến kích thước khổng lồ và máy chủ tiếp tục lưu trữ các tập tin nhật ký mới với phần mở rộng mới là số. Do đó, rõ ràng là các tập tin nhật ký có thể chiếm dung lượng đĩa. Bạn sẽ không cần các tập tin nhật ký trong một khoảng thời gian dài, vì vậy bạn nên xóa các tập tin này khi chúng không còn cần thiết nữa. Bạn có thể xóa tập tin bằng lệnh PURGE BINARY LOGS MySQL.

Một tùy chọn khác để xóa tập tin là sử dụng tùy chọn expire_logs_days trong tập tin cấu hình của bạn. Đặt giá trị biến này thành số ngày bạn muốn giữ các tập tin nhật ký. Ví dụ: giữ tập tin nhật ký trong 30 ngày nếu chính sách công ty của bạn yêu cầu tập tin nhật ký trong 30 ngày. Giá trị này sẽ xóa tập tin 30 ngày một lần thay vì yêu cầu bạn phải xóa tập tin theo cách thủ công mỗi tháng.

6. Tối ưu Truy vấn.

Chúng ta đã thảo luận về việc điều chỉnh MySQL engine bằng cách sử dụng các tùy chọn cấu hình, nhưng bạn cũng có thể tăng tốc cơ sở dữ liệu bằng cách điều chỉnh các truy vấn. Các truy vấn không được tối ưu hóa đúng cách có thể làm giảm hiệu suất, đặc biệt khi có một số lượng lớn các bản ghi được trả về. Là quản trị viên cơ sở dữ liệu, bạn có thể xem lại các truy vấn SQL để đảm bảo rằng chúng được tối ưu hóa cho hiệu suất.

Chúng ta hãy xem xét một số phương pháp tối ưu hóa mà bạn có thể sử dụng cho các truy vấn.

6.1. Truy vấn trên các chỉ mục tăng tốc độ truy vấn lên rất nhiều.

Hãy xem truy vấn sau.

SELECT first_name, last_name FROM Customer

WHERE first_name = 'john' and last_name = 'smith';
Truy vấn này tìm mọi bản ghi có tên là "John" và họ là "Smith", nhưng nếu các cột first_name và last_name không phải là chỉ mục, thì truy vấn này không được tối ưu hóa. Thay vào đó, bạn nên sử dụng các truy vấn trên các chỉ mục. Khóa chính trên bất kỳ bảng nào là một chỉ mục, vì vậy thay vì truy vấn họ và tên khách hàng, bạn nên truy vấn trên cột customer_id. Truy vấn trên sẽ biến thành như sau:

SELECT first_name, last_name FROM Customer

WHERE customer_id = 2;
Truy vấn trên sẽ nhanh hơn nhiều, giả sử rằng customer_id là khóa chính của bảng.

6.2. Một kỹ thuật tối ưu hóa khác là đặt các chỉ mục trên các cột mà bạn nối các bảng.

Chúng ta hãy xem xét truy vấn sau đây.

SELECT first_name, last_name FROM Customer AS c

INNER JOIN Order AS o ON c.first_name = o.first_name

WHERE c.customer_id = 2;
Bỏ qua một bên rằng truy vấn trên sẽ không cung cấp kết quả chính xác từ việc kết hợp, mục tiêu của mình là chỉ ra sự tối ưu hóa cần thiết cho truy vấn này. Việc kết hợp các bảng trên các cột không được lập chỉ mục và có cấu trúc kém sẽ làm giảm hiệu suất trên các truy vấn đó. Thông thường, việc nối các bảng được thực hiện trên các khóa chính với các khóa ngoại được liên kết. Tuy nhiên, đôi khi bạn muốn nối các bảng trên các phần tử không phải là khóa. Nếu bạn thực hiện loại truy vấn này, hãy đảm bảo rằng bạn thêm chỉ mục trên các cột được sử dụng để nối.

6.3. Mẹo tối ưu hóa cuối cùng của mình là luôn sử dụng các câu lệnh JOIN thay vì các truy vấn con.

Mình đã thảo luận về các truy vấn con với các mẫu câu lệnh UPDATE. Bạn cũng có thể sử dụng truy vấn con với các câu lệnh khác. Các truy vấn con đôi khi được yêu cầu, nhưng bất kỳ truy vấn phổ biến nào chạy thường xuyên nên sử dụng câu lệnh JOIN thay vì truy vấn con.

Hãy xem truy vấn sau.

SELECT first_name, last_name FROM Customer AS c

WHERE customer_id IN (SELECT customer_id FROM Order WHERE order.customer_id = c.customer_id);
Truy vấn trên tìm đơn đặt hàng được liên kết với id khách hàng trong bảng Khách hàng. Truy vấn này hợp lệ và nó sẽ trả về kết quả chính xác. Tuy nhiên, nó không được tối ưu hóa và sẽ cung cấp cho bạn kết quả chậm hơn những gì bạn sẽ nhận được với câu lệnh JOIN. Đầu tiên, truy vấn trên thực hiện một câu lệnh SELECT trên toàn bộ bảng Đơn hàng. Sau đó, toàn bộ bảng Khách hàng được truy vấn. Khi tìm thấy một kết quả phù hợp, máy chủ cơ sở dữ liệu trả về các bản ghi được liên kết. Nếu bạn có hàng triệu bản ghi trong một trong hai bảng, điều này gây căng thẳng cho tài nguyên máy chủ MySQL của bạn.

Truy vấn trên có thể được thay đổi thành như sau:

SELECT first_name, last_name FROM Customer AS c

INNER JOIN Order AS o ON c.customer_id = o.customer_id;
Truy vấn này cung cấp cho bạn kết quả tương tự, nhưng nhanh hơn nhiều. Bạn càng thêm nhiều truy vấn phụ vào các truy vấn chính của mình, bạn càng dành nhiều thời gian cho tập hợp kết quả. Nếu có bất kỳ truy vấn nào sử dụng truy vấn con nhưng có thể sử dụng câu lệnh JOIN để thay thế, hãy viết lại truy vấn để tối ưu hóa tốt hơn.

Bài viết này mô tả một số kỹ thuật tối ưu hóa mà bạn có thể thực hiện trên máy chủ của mình. Hiệu suất của MySQL phụ thuộc vào kiến ​​trúc máy chủ và tài nguyên mạng, nhưng việc tối ưu hóa và cấu hình phù hợp sẽ cải thiện đáng kể độ ổn định và tốc độ. Bạn sẽ cần điều chỉnh cấu hình của mình để tìm ra sự kết hợp phù hợp cho máy chủ của mình.