CFSDN nhấn mạnh vào việc tạo ra giá trị thông qua mã nguồn mở. Chúng tôi cam kết xây dựng một nền tảng chia sẻ tài nguyên để mọi người làm CNTT có thể tìm thấy thế giới tuyệt vời của riêng mình tại đây.

Bài đăng trên blog CFSDN này "Hướng dẫn cho người mới bắt đầu về MySQL -- quy trình thực thi sql" được tác giả thu thập và sắp xếp. Nếu bạn quan tâm đến bài viết này, vui lòng thích nó.

1. Quy trình

2. Kiến trúc cốt lõi

Nói một cách đơn giản, MySQL chủ yếu được chia thành lớp máy chủ và lớp công cụ lưu trữ:

• Lớp máy chủ: chủ yếu bao gồm các trình kết nối, bộ đệm truy vấn, trình phân tích, trình tối ưu hóa, trình thực thi, v.v. Tất cả các chức năng của công cụ lưu trữ chéo đều được triển khai trong lớp này, chẳng hạn như các thủ tục được lưu trữ, trình kích hoạt, chế độ xem, hàm, v.v. Ngoài ra còn có một mô-đun nhật ký chung là mô-đun nhật ký binglog.
• Công cụ lưu trữ: Chủ yếu chịu trách nhiệm lưu trữ và đọc dữ liệu, sử dụng kiến ​​trúc plug-in có thể thay thế và hỗ trợ nhiều công cụ lưu trữ như InnoDB, MyISAM, Memory, v.v. Trong số đó, công cụ InnoDB có mô-đun nhật ký riêng là mô-đun redolog. Công cụ lưu trữ được sử dụng phổ biến nhất hiện nay là InnoDB, được dùng làm công cụ lưu trữ mặc định kể từ MySQL 5.5.5.

 2.1 Giới thiệu các thành phần cơ bản của lớp máy chủ

1. Đầu nối.

Các đầu nối chủ yếu liên quan đến chức năng xác thực danh tính và cấp phép, giống như người gác cửa cấp cao.

Chủ yếu chịu trách nhiệm cho việc đăng nhập của người dùng vào cơ sở dữ liệu và xác thực danh tính người dùng, bao gồm xác minh mật khẩu tài khoản, quyền và các hoạt động khác. Nếu mật khẩu tài khoản người dùng đã vượt qua, trình kết nối sẽ truy vấn tất cả các quyền của người dùng trong bảng quyền. Phán đoán logic quyền tiếp theo trong kết nối này sẽ dựa trên dữ liệu quyền được đọc tại thời điểm này. Nói cách khác, miễn là kết nối không bị ngắt kết nối, ngay cả khi quản trị viên sửa đổi quyền của người dùng, người dùng sẽ không bị ảnh hưởng.

2. Bộ nhớ đệm truy vấn (đã bị xóa sau phiên bản MySQL 8.0).

Bộ đệm truy vấn chủ yếu được sử dụng để lưu trữ câu lệnh SELECT mà chúng ta đã thực thi và tập kết quả của câu lệnh đó.

Sau khi kết nối được thiết lập, khi thực hiện một câu lệnh truy vấn, bộ nhớ đệm sẽ được truy vấn trước. MySQL sẽ xác minh xem SQL đã được thực hiện chưa và lưu trữ nó trong bộ nhớ dưới dạng Khóa-Giá trị. Khóa là ước tính truy vấn và Giá trị là tập kết quả. Nếu phím bộ nhớ đệm được nhấn, nó sẽ được trả về trực tiếp cho máy khách. Nếu không được nhấn, các hoạt động tiếp theo sẽ được thực hiện và kết quả sẽ được lưu vào bộ nhớ đệm sau khi hoàn tất cho lần gọi tiếp theo. Tất nhiên, khi truy vấn bộ nhớ đệm thực sự được thực thi, quyền của người dùng vẫn sẽ được kiểm tra để xem có điều kiện truy vấn nào cho bảng hay không.

Không nên sử dụng bộ nhớ đệm cho các truy vấn MySQL vì việc vô hiệu hóa bộ nhớ đệm truy vấn có thể xảy ra rất thường xuyên trong các tình huống kinh doanh thực tế. Nếu bạn cập nhật một bảng, tất cả bộ nhớ đệm truy vấn trên bảng này sẽ bị xóa. Đối với dữ liệu không được cập nhật thường xuyên, bạn vẫn có thể sử dụng bộ nhớ đệm.

Do đó, trong hầu hết các trường hợp, chúng tôi không khuyến khích sử dụng bộ đệm truy vấn.

Chức năng bộ nhớ đệm đã bị xóa sau MySQL 8.0. Người này cũng tin rằng chức năng này có ít trường hợp ứng dụng thực tế nên đã bị xóa.

3. Máy phân tích.

Nếu MySQL không truy cập vào bộ nhớ đệm, nó sẽ vào trình phân tích, chủ yếu dùng để phân tích mục đích của câu lệnh SQL. Trình phân tích cũng được chia thành nhiều bước:

1. Bước đầu tiên là phân tích từ vựng. Một câu lệnh SQL bao gồm nhiều chuỗi. Đầu tiên, chúng ta cần trích xuất các từ khóa, chẳng hạn như select, đề xuất bảng truy vấn, đề xuất tên trường, đề xuất điều kiện truy vấn, v.v. Sau khi hoàn tất các thao tác này, bạn sẽ chuyển sang bước thứ hai.
2. Bước thứ hai, phân tích cú pháp, chủ yếu là để xác định xem SQL bạn nhập có đúng không và có tuân thủ cú pháp MySQL không.

Sau khi hoàn tất hai bước này, MySQL đã sẵn sàng để bắt đầu thực thi, nhưng làm thế nào để thực thi và thực thi như thế nào để có được kết quả tốt nhất? Đây là lúc trình tối ưu hóa phát huy tác dụng.

4. Trình tối ưu hóa.

Vai trò của trình tối ưu hóa là thực thi kế hoạch thực thi tối ưu mà nó cho là tốt nhất (đôi khi có thể không phải là tốt nhất, bài viết này sẽ giải thích sâu hơn về phần kiến ​​thức này), chẳng hạn như cách chọn chỉ mục khi có nhiều chỉ mục, cách chọn thứ tự liên kết khi truy vấn nhiều bảng, v.v.

Có thể nói rằng sau khi tối ưu hóa, cách thức thực thi câu lệnh này đã được xác định.

5. Bộ truyền động.

Sau khi chọn kế hoạch thực thi, MySQL đã sẵn sàng để bắt đầu thực thi. Đầu tiên, nó sẽ kiểm tra xem người dùng có quyền trước khi thực thi hay không. Nếu không, một thông báo lỗi sẽ được trả về. Nếu người dùng có quyền, giao diện engine sẽ được gọi và kết quả thực thi giao diện sẽ được trả về.

3. Phân tích câu lệnh

3.1 Câu lệnh truy vấn

SQL có thể được chia thành hai loại, một là truy vấn và loại còn lại là cập nhật (thêm, cập nhật, xóa). Trước tiên, chúng ta hãy phân tích câu lệnh truy vấn. Câu lệnh như sau:

chọn * từ tb_student A nơi A.age='18' và A.name=' 张三',

Kết hợp với mô tả ở trên, chúng tôi phân tích luồng thực thi của câu lệnh này:

Trước tiên hãy kiểm tra xem câu lệnh có được cấp phép hay không. Nếu không, một thông báo lỗi sẽ được trả về trực tiếp. Nếu có quyền, trước MySQL 8.0, bộ nhớ đệm sẽ được truy vấn trước, sử dụng câu lệnh SQL này làm khóa để kiểm tra xem có kết quả nào trong bộ nhớ hay không. Nếu có, nó sẽ được lưu trực tiếp vào bộ nhớ đệm. Nếu không, hãy tiến hành bước tiếp theo.

Thông qua trình phân tích, phân tích từ vựng được thực hiện để trích xuất các thành phần chính của câu lệnh SQL. Ví dụ, câu lệnh trên là truy vấn select, tên bảng cần truy vấn là tb_student, tất cả các cột cần được truy vấn và điều kiện truy vấn là id của bảng này = '1'. Sau đó xác định xem câu lệnh SQL có lỗi cú pháp nào không, chẳng hạn như từ khóa có đúng không, v.v. Nếu kiểm tra đúng, hãy tiến hành bước tiếp theo.

Tiếp theo, trình tối ưu hóa xác định kế hoạch thực hiện. Câu lệnh SQL trên có thể được thực hiện theo hai cách:

a. Đầu tiên, hãy truy vấn bảng học sinh để tìm học sinh có tên là "Zhang San", sau đó xác định xem tuổi của học sinh đó có phải là 18 không. b. Đầu tiên tìm những học sinh 18 tuổi, sau đó tìm những học sinh có tên là "Trương Tam".

Sau đó, trình tối ưu hóa sẽ chọn giải pháp có hiệu quả thực thi tốt nhất dựa trên thuật toán tối ưu hóa của riêng nó (trình tối ưu hóa tin rằng đây không phải lúc nào cũng là giải pháp tốt nhất). Sau khi kế hoạch thực hiện được xác nhận, kế hoạch đã sẵn sàng để bắt đầu thực hiện.

Thực hiện kiểm tra quyền. Nếu không có quyền, thông báo lỗi sẽ được trả về. Nếu có quyền, giao diện công cụ cơ sở dữ liệu sẽ được gọi và kết quả thực thi công cụ sẽ được trả về.

3.2 Cập nhật tuyên bố

Phía trên là quá trình thực thi của một truy vấn SQL, vậy chúng ta hãy cùng xem một câu lệnh cập nhật được thực thi như thế nào? Câu lệnh SQL như sau:

cập nhật tb_student Một tập hợp A.age='19' trong đó A.name=' 张三',

Chúng ta hãy sửa đổi tuổi của Trương Tam. Trong cơ sở dữ liệu thực tế, trường tuổi này chắc chắn sẽ không được thiết lập, nếu không bạn sẽ bị giám đốc kỹ thuật đánh. Trên thực tế, câu lệnh này về cơ bản sẽ tuân theo quy trình của truy vấn trước đó, nhưng cần phải ghi lại nhật ký khi thực hiện cập nhật, điều này sẽ giới thiệu mô-đun nhật ký. Mô-đun nhật ký tích hợp của MySQL là binlog (nhật ký lưu trữ), có thể được sử dụng bởi tất cả các công cụ lưu trữ. Công cụ InnoDB thường được sử dụng cũng đi kèm với mô-đun nhật ký redo log (nhật ký làm lại). Chúng ta sẽ thảo luận về quy trình thực hiện câu lệnh này ở chế độ InnoDB. Quá trình này như sau:

Đầu tiên hãy truy vấn dữ liệu của Trương Tam, nếu có bộ nhớ đệm thì cũng sẽ được sử dụng.

Sau đó lấy câu lệnh truy vấn, đổi age thành 19 và gọi giao diện API của engine để ghi hàng dữ liệu này. Engine InnoDB lưu dữ liệu trong bộ nhớ và ghi lại nhật ký làm lại cùng lúc. Lúc này, nhật ký làm lại sẽ chuyển sang trạng thái chuẩn bị và thông báo cho trình thực thi rằng quá trình thực thi đã hoàn tất và có thể gửi bất kỳ lúc nào.

Sau khi nhận được thông báo, trình thực thi sẽ ghi lại binlog, sau đó gọi giao diện công cụ để gửi nhật ký làm lại đến trạng thái đã cam kết.

Đã hoàn tất cập nhật.

Một số sinh viên chắc chắn sẽ hỏi ở đây, tại sao chúng ta cần hai mô-đun ghi nhật ký? Chúng ta không thể sử dụng một mô-đun ghi nhật ký sao?

Điều này là do MySQL ban đầu không đi kèm với công cụ InnoDB (công cụ InnoDB đã được các công ty khác cắm vào MySQL) và công cụ gốc của MySQL là MyISAM. Tuy nhiên, chúng ta biết rằng nhật ký làm lại là duy nhất đối với công cụ InnoDB và các công cụ lưu trữ khác không có. Điều này dẫn đến việc thiếu khả năng chống sập (khả năng chống sập có nghĩa là ngay cả khi cơ sở dữ liệu khởi động lại bất thường, các bản ghi đã gửi trước đó sẽ không bị mất) và nhật ký binlog chỉ có thể được sử dụng để lưu trữ.

Điều này không có nghĩa là không thể sử dụng chỉ một mô-đun nhật ký, nhưng công cụ InnoDB hỗ trợ các giao dịch thông qua nhật ký làm lại. Sau đó, một số sinh viên có thể hỏi, tôi có thể sử dụng hai mô-đun nhật ký nhưng không làm cho nó quá phức tạp không? Tại sao nhật ký làm lại cần phải giới thiệu trạng thái chuẩn bị trước khi cam kết? Ở đây chúng tôi sử dụng chứng minh phản chứng để giải thích tại sao chúng tôi làm điều này.

Trước tiên hãy viết nhật ký làm lại và gửi trực tiếp, sau đó viết binlog. Nếu máy bị sập sau khi viết nhật ký làm lại và binlog không được viết, thì sau khi máy khởi động lại, máy sẽ khôi phục dữ liệu thông qua nhật ký làm lại, nhưng binlog không ghi lại dữ liệu tại thời điểm này. Khi máy được sao lưu sau đó, phần dữ liệu này sẽ bị mất và đồng bộ hóa chủ-tớ cũng sẽ mất phần dữ liệu này.

Viết binlog trước, sau đó viết redo log. Giả sử sau khi viết binlog, máy khởi động lại bất thường. Vì không có redo log nên máy không thể khôi phục bản ghi này. Tuy nhiên, binlog có một bản ghi khác. Khi đó, cùng lý do như trên sẽ gây ra sự không nhất quán dữ liệu.

Nếu áp dụng phương pháp cam kết hai giai đoạn nhật ký làm lại, tình hình sẽ khác. Sau khi viết binglog, việc gửi nhật ký làm lại sẽ ngăn chặn các vấn đề trên xảy ra, do đó đảm bảo tính nhất quán của dữ liệu. Vậy câu hỏi đặt ra là liệu có tình huống cực đoan nào không? Giả sử rằng nhật ký làm lại đang ở trạng thái trước khi cam kết và binglog đã được ghi. Điều gì sẽ xảy ra nếu khởi động lại bất thường xảy ra tại thời điểm này? Điều này phụ thuộc vào cơ chế xử lý của MySQL. Quá trình xử lý của MySQL như sau:

Xác định xem nhật ký làm lại đã hoàn tất chưa. Nếu đã hoàn tất, hãy cam kết ngay lập tức.

Nếu nhật ký làm lại chỉ ở trạng thái đã cam kết trước nhưng chưa cam kết, hệ thống sẽ kiểm tra xem binlog đã hoàn tất chưa. Nếu đã hoàn tất, nhật ký làm lại sẽ được cam kết. Nếu chưa hoàn tất, giao dịch sẽ bị hủy bỏ.

Điều này giải quyết được vấn đề về tính nhất quán của dữ liệu.

4. Kết luận

• MySQL chủ yếu được chia thành lớp máy chủ và lớp động cơ. Lớp máy chủ chủ yếu bao gồm các trình kết nối, bộ đệm truy vấn, trình phân tích, trình tối ưu hóa, trình thực thi và mô-đun nhật ký (binlog). Mô-đun nhật ký này có thể được chia sẻ bởi tất cả các công cụ thực thi và redolog chỉ khả dụng trong InnoDB.
• Lớp engine dựa trên plug-in và hiện tại chủ yếu bao gồm MyISAM, InnoDB, Memory, v.v.
• Quá trình thực thi SQL được chia thành hai loại. Một loại dành cho các quá trình truy vấn như sau: Kiểm tra quyền -> bộ đệm truy vấn -> trình phân tích -> trình tối ưu hóa -> kiểm tra quyền -> trình thực thi -> công cụ
• Quá trình thực thi cho các câu lệnh cập nhật như sau: Analyzer ----》Kiểm tra quyền ----》Executor—》Engine—redo log prepare—》binlog—》redo log commit

Bài viết này đến đây là kết thúc, hy vọng các bạn có thể chú ý hơn đến những nội dung khác của tôi! .

Liên kết gốc: https://blog.csdn.net/goodjobman/article/details/117734348.

Cuối cùng, bài viết này về Mysql dành cho người mới bắt đầu - quy trình thực thi sql đã kết thúc tại đây. Nếu bạn muốn biết thêm về Mysql dành cho người mới bắt đầu - quy trình thực thi sql, vui lòng tìm kiếm các bài viết trên CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .