MySQL được thành lập khi nào?
|
Phần lớn, kiến trúc MySQL bất chấp định nghĩa hoặc đặc điểm kỹ thuật chính thức. Khi phần lớn mã ban đầu được viết, nó không được thực hiện để trở thành một phần của hệ thống tuyệt vời nào đó trong tương lai, mà là để giải quyết một số vấn đề rất cụ thể. Tuy nhiên, nó đã được viết rất hay và đủ sâu sắc đến mức có đủ các phần chất lượng để lắp ráp một máy chủ cơ sở dữ liệu Show Tôi cố gắng trong phần này để xác định các mô-đun cốt lõi trong hệ thống. Tuy nhiên, hãy để tôi thêm tuyên bố từ chối trách nhiệm rằng đây chỉ là một nỗ lực để chính thức hóa những gì tồn tại. Các nhà phát triển MySQL hiếm khi nghĩ theo những thuật ngữ đó. Thay vào đó, họ có xu hướng nghĩ về các tệp, thư mục, lớp, cấu trúc và chức năng. Việc nghe “Điều này xảy ra trong Đối với MySQL, tôi sử dụng thuật ngữ “mô-đun” khá lỏng lẻo. Không giống như cái mà người ta thường gọi là mô-đun, trong nhiều trường hợp, nó không phải là thứ bạn có thể dễ dàng rút ra và thay thế bằng một triển khai khác. Mã từ một mô-đun có thể trải rộng trên nhiều tệp và bạn thường tìm thấy mã từ nhiều mô-đun khác nhau trong cùng một tệp. Điều này đặc biệt đúng với mã cũ hơn. Mã mới hơn có xu hướng phù hợp với mô hình mô-đun tốt hơn. Vì vậy, theo định nghĩa của chúng tôi, một mô-đun là một đoạn mã thuộc về logic theo một cách nào đó và thực hiện một chức năng quan trọng nhất định trong máy chủ Người ta có thể xác định các mô-đun sau trong máy chủ
Tương tác của các mô-đun cốt lõiKhi máy chủ được khởi động trên dòng lệnh, Mô-đun khởi tạo sẽ kiểm soát. Nó phân tích tệp cấu hình và các đối số dòng lệnh, phân bổ bộ đệm bộ nhớ chung, khởi tạo các biến và cấu trúc toàn cục, tải các bảng điều khiển truy cập và thực hiện một số tác vụ khởi tạo khác. Khi công việc khởi tạo hoàn tất, Mô-đun khởi tạo sẽ chuyển quyền điều khiển tới Trình quản lý kết nối, bắt đầu lắng nghe các kết nối từ máy khách trong một vòng lặp Khi một máy khách kết nối với máy chủ cơ sở dữ liệu, Trình quản lý kết nối sẽ thực hiện một số tác vụ giao thức mạng cấp thấp và sau đó chuyển quyền điều khiển cho Trình quản lý luồng, từ đó cung cấp một luồng để xử lý kết nối (từ giờ trở đi sẽ được gọi là . Chủ đề kết nối có thể được tạo lại hoặc được truy xuất từ bộ đệm luồng và được gọi để thực hiện nhiệm vụ đang hoạt động. Khi Chuỗi kết nối nhận được quyền kiểm soát, trước tiên, nó sẽ gọi Mô-đun xác thực người dùng. Thông tin đăng nhập của người dùng kết nối được xác minh và khách hàng hiện có thể đưa ra yêu cầu Chủ đề kết nối chuyển dữ liệu yêu cầu tới Bộ điều phối lệnh. Một số yêu cầu, được biết đến trong thuật ngữ mã MySQL là các lệnh, có thể được Bộ điều phối lệnh cung cấp trực tiếp, trong khi những yêu cầu phức tạp hơn cần được chuyển hướng đến một mô-đun khác. Một lệnh điển hình có thể yêu cầu máy chủ chạy truy vấn, thay đổi cơ sở dữ liệu đang hoạt động, báo cáo trạng thái, gửi kết xuất liên tục các bản cập nhật sao chép, đóng kết nối hoặc thực hiện một số thao tác khác Trong thuật ngữ máy chủ MySQL, có hai loại yêu cầu máy khách. một truy vấn và một lệnh. Truy vấn là bất cứ thứ gì phải đi qua trình phân tích cú pháp. Lệnh là một yêu cầu có thể được thực thi mà không cần gọi trình phân tích cú pháp. Chúng tôi sẽ sử dụng thuật ngữ truy vấn trong ngữ cảnh của nội bộ MySQL. Do đó, không chỉ Nếu tính năng ghi nhật ký truy vấn đầy đủ được bật, Bộ điều phối Lệnh sẽ yêu cầu Mô-đun Ghi nhật ký ghi truy vấn hoặc lệnh vào nhật ký văn bản thuần túy trước khi gửi đi. Do đó, trong cấu hình ghi nhật ký đầy đủ, tất cả các truy vấn sẽ được ghi lại, ngay cả những truy vấn không đúng về mặt cú pháp và sẽ không bao giờ được thực thi, ngay lập tức sẽ trả về lỗi Bộ điều phối lệnh chuyển tiếp các truy vấn tới Trình phân tích cú pháp thông qua Mô-đun bộ đệm truy vấn. Mô-đun bộ nhớ cache truy vấn kiểm tra xem truy vấn có thuộc loại có thể được lưu vào bộ nhớ cache hay không và liệu có tồn tại kết quả được lưu trong bộ nhớ cache được tính toán trước đó vẫn hợp lệ hay không. Trong trường hợp xảy ra lỗi, quá trình thực thi bị ngắt mạch tại thời điểm này, kết quả được lưu trong bộ nhớ cache được trả về cho người dùng và Chuỗi kết nối nhận quyền kiểm soát và hiện đã sẵn sàng để xử lý một lệnh khác. Nếu Mô-đun bộ đệm truy vấn báo cáo lỗi, truy vấn sẽ chuyển đến Trình phân tích cú pháp, trình phân tích cú pháp này sẽ đưa ra quyết định về cách chuyển quyền kiểm soát dựa trên loại truy vấn Người ta có thể xác định các mô-đun sau có thể tiếp tục từ thời điểm đó. Trình tối ưu hóa, Mô-đun Sửa đổi Bảng, Mô-đun Bảo trì Bảng, Mô-đun Sao chép và Mô-đun Báo cáo Trạng thái. Các truy vấn chọn lọc được chuyển tiếp đến Trình tối ưu hóa; . Ngoài ra còn tồn tại một số Mô-đun sửa đổi bảng. Xóa mô-đun, tạo mô-đun, cập nhật mô-đun, chèn mô-đun và thay đổi mô-đun Tại thời điểm này, mỗi mô-đun sẽ nhận quyền kiểm soát từ Trình phân tích cú pháp sẽ chuyển danh sách các bảng liên quan đến truy vấn tới Mô-đun Kiểm soát Truy cập và sau đó, khi thành công, tới Trình quản lý Bảng, sẽ mở các bảng và lấy các khóa cần thiết. Giờ đây, mô-đun vận hành bảng đã sẵn sàng để tiến hành nhiệm vụ cụ thể của nó và sẽ đưa ra một số yêu cầu tới Mô-đun Công cụ Lưu trữ Trừu tượng cho các hoạt động cấp thấp như chèn hoặc cập nhật bản ghi, truy xuất bản ghi dựa trên giá trị khóa hoặc thực hiện Mô-đun Công cụ lưu trữ trừu tượng sẽ tự động dịch các lệnh gọi sang các phương thức tương ứng của Mô-đun Công cụ lưu trữ cụ thể thông qua đa hình đối tượng. Nói cách khác, khi xử lý đối tượng Công cụ lưu trữ, người gọi nghĩ rằng nó đang xử lý đối tượng trừu tượng, trong khi thực tế đối tượng thuộc loại cụ thể hơn. nó là đối tượng Công cụ lưu trữ tương ứng với loại bảng đã cho. Các phương thức giao diện là ảo, tạo hiệu ứng trong suốt. Phương thức chính xác sẽ được gọi và người gọi không cần biết loại đối tượng chính xác của đối tượng Công cụ lưu trữ Khi truy vấn hoặc lệnh đang được xử lý, mô-đun tương ứng có thể gửi các phần của tập kết quả tới máy khách khi chúng có sẵn. Nó cũng có thể gửi cảnh báo hoặc thông báo lỗi. Nếu thông báo lỗi được đưa ra, cả máy khách và máy chủ sẽ hiểu rằng truy vấn hoặc lệnh không thành công và thực hiện các biện pháp thích hợp. Máy khách sẽ không chấp nhận thêm bất kỳ dữ liệu thông báo lỗi, cảnh báo hoặc tập kết quả nào cho truy vấn đã cho, trong khi máy chủ sẽ luôn chuyển quyền kiểm soát sang Chủ đề kết nối sau khi đưa ra lỗi. Lưu ý rằng vì MySQL không sử dụng các ngoại lệ vì lý do ổn định triển khai và tính di động, tất cả các lệnh gọi ở tất cả các cấp phải được kiểm tra lỗi bằng cách chuyển quyền kiểm soát thích hợp trong trường hợp không thành công Nếu mô-đun cấp thấp đã thực hiện sửa đổi dữ liệu theo một cách nào đó và nếu tính năng ghi nhật ký cập nhật nhị phân được bật, thì mô-đun đó sẽ chịu trách nhiệm yêu cầu Mô-đun ghi nhật ký ghi sự kiện cập nhật vào nhật ký cập nhật nhị phân, đôi khi được gọi là nhật ký cập nhật nhị phân. Sau khi hoàn thành tác vụ, luồng thực thi sẽ quay trở lại Chuỗi kết nối, chuỗi này thực hiện việc dọn dẹp cần thiết và đợi một truy vấn hoặc lệnh khác từ máy khách. Phiên tiếp tục cho đến khi máy khách ra lệnh Thoát Ngoài việc tương tác với các máy khách thông thường, máy chủ có thể nhận lệnh từ nô lệ sao chép để liên tục đọc nhật ký cập nhật nhị phân của nó. Lệnh này sẽ được xử lý bởi Replication Master Module Nếu máy chủ được cấu hình như một nô lệ sao chép, Mô-đun khởi tạo sẽ gọi Mô-đun nô lệ sao chép, mô-đun này sẽ bắt đầu hai luồng, được gọi là luồng SQL và luồng I/O. Họ đảm nhiệm việc tuyên truyền các bản cập nhật đã xảy ra trên máy chủ cho nô lệ. Có thể cùng một máy chủ được cấu hình vừa là chủ vừa là nô lệ Giao tiếp mạng với máy khách đi qua Mô-đun Giao thức Máy khách/Máy chủ, chịu trách nhiệm đóng gói dữ liệu ở định dạng phù hợp và tùy thuộc vào cài đặt kết nối, nén nó. Lần lượt, Mô-đun Giao thức Máy khách/Máy chủ sử dụng mô-đun I/O Mạng Cấp thấp, chịu trách nhiệm gửi và nhận dữ liệu ở cấp ổ cắm theo cách di động đa nền tảng. Nó cũng chịu trách nhiệm mã hóa dữ liệu bằng các cuộc gọi thư viện OpenSSL nếu các tùy chọn kết nối được đặt phù hợp Khi họ thực hiện các nhiệm vụ tương ứng, các thành phần cốt lõi của máy chủ phụ thuộc rất nhiều vào API lõi. API lõi cung cấp một bộ chức năng phong phú, bao gồm tệp I/O, quản lý bộ nhớ, thao tác chuỗi, triển khai các cấu trúc dữ liệu và thuật toán khác nhau cũng như nhiều khả năng hữu ích khác. Các nhà phát triển MySQL được khuyến khích tránh các cuộc gọi libc trực tiếp và sử dụng API lõi để tạo điều kiện chuyển sang các nền tảng mới và tối ưu hóa mã trong tương lai minh họa các mô-đun cốt lõi và sự tương tác của chúng Hình 1-1. Chế độ xem cấp cao của các mô-đun MySQL Xem chi tiết các mô-đun cốt lõiBây giờ chúng ta sẽ xem xét kỹ hơn từng thành phần. Một mục đích của cuộc thảo luận là kết nối ngôn ngữ khái niệm được sử dụng trước đó với nguồn thực tế. Ngoài ra, chúng tôi sẽ đề cập đến một số lịch sử của từng thành phần và cố gắng ước tính lộ trình phát triển trong tương lai của nó Các tham chiếu thường xuyên đến nguồn sẽ được thực hiện và bạn có thể thấy hữu ích khi mở các tệp được đề cập trong trình soạn thảo văn bản và tìm tham chiếu hàm. Điều này cũng có thể được thực hiện trong trình sửa lỗi, như được trình bày trong Chương 3. Chương đó cũng sẽ cho bạn biết cách lấy mã nguồn Mô-đun khởi tạo máy chủMô-đun khởi tạo máy chủ chịu trách nhiệm khởi tạo máy chủ khi khởi động. Hầu hết mã được tìm thấy trong tệp sql/mysql. cc. Điểm đầu vào là những gì một lập trình viên C/C++ mong đợi.
Mặc dù mã được tìm thấy trong phiên bản 3. 22 chưa bao giờ được viết lại từ đầu, nó đã được tái cấu trúc đáng kể khi các tính năng mới được thêm vào MySQL. Một đoạn mã khởi tạo lớn từng nằm trong Trong phiên bản 5. 1, một phần đáng kể đã được thêm vào Nhìn chung, khu vực này của mã là khá ổn định. Dựa trên lịch sử trong quá khứ, chúng ta nên dự đoán các bổ sung gia tăng có thể có trong tương lai khi các tính năng mới yêu cầu khởi tạo đặc biệt khi khởi động được thêm vào. Tuy nhiên, việc viết lại mã này là không thể Trình quản lý kết nối lắng nghe các kết nối đến từ máy khách và gửi yêu cầu đến Trình quản lý luồng. Mô-đun này thực sự chỉ là một chức năng trong sql/mysqld. cc. Theo thời gian, mã đã phát triển phần nào để phù hợp với những điều kỳ quặc trong các cuộc gọi hệ thống mạng của các hệ điều hành khác nhau. Những thay đổi khác có thể cần thiết trong tương lai khi các cổng mới được thử nghiệm hoặc khi các nhà cung cấp hệ điều hành khác giới thiệu các tính năng mới vào các phiên bản mới của sản phẩm của họ Trình quản lý luồng chịu trách nhiệm theo dõi các luồng và đảm bảo luồng được phân bổ để xử lý kết nối từ máy khách. Đây là một mô-đun rất nhỏ khác. Hầu hết các mã được tìm thấy trong sql/mysql. cc. Điểm vào là Có lẽ người ta có thể xem xét lớp Mã quản lý luồng đã được làm lại đáng kể trong phiên bản 3. 23 khi bộ đệm luồng được thêm vào. Kể từ đó nó đã không được thay đổi đáng kể. Thật hợp lý khi kỳ vọng rằng nó sẽ không nhận được bất kỳ thay đổi đáng kể nào trong tương lai Tuy nhiên, nếu chúng ta, theo cách trừu tượng của mình, coi chính lớp THD là một phần của mô-đun này, thì chúng ta sẽ có một câu chuyện khác khi có liên quan đến các thay đổi. Việc bổ sung các tính năng mới như câu lệnh đã chuẩn bị, con trỏ phía máy chủ và quy trình được lưu trữ đã dẫn đến việc làm lại đáng kể THD trong phiên bản 4. 1 và 5. 0. Bây giờ nó là một siêu lớp của Chủ đề kết nối là trung tâm của công việc xử lý các yêu cầu của khách hàng trên một kết nối đã được thiết lập. Mô-đun này cũng rất nhỏ. Nó chỉ bao gồm một chức năng. Mã phát triển theo thời gian, dần dần trở nên nhỏ gọn hơn và dễ đọc hơn khi các khởi tạo khác nhau liên quan đến các biến Mô-đun xác thực người dùngMô-đun xác thực người dùng xác thực người dùng kết nối và khởi tạo các cấu trúc và biến chứa thông tin về mức độ đặc quyền của anh ta. Điểm vào cho mô-đun này là
Mã đã được làm lại đáng kể chỉ một lần, trong phiên bản 4. 1. Do tác động có thể có của các thay đổi, các nhà phát triển MySQL đã đợi một lúc trước khi họ thử cập nhật giao thức cần thiết để triển khai xác thực an toàn hơn Kể từ đó, không có nhiều thay đổi đối với mã này. Tuy nhiên, với việc bổ sung khả năng plug-in trong 5. 1, Các nhà phát triển MySQL đang có kế hoạch bổ sung các khả năng vai trò và xác thực có thể cắm được, điều này sẽ yêu cầu các thay đổi trong mã này Mô-đun Kiểm soát Truy cập xác minh rằng người dùng máy khách có đủ đặc quyền để thực hiện thao tác được yêu cầu. Hầu hết mã nằm trong sql/sql_acl. cc. Tuy nhiên, một trong những chức năng được sử dụng thường xuyên nhất,
Bản thân mã không thay đổi nhiều kể từ phiên bản 3. 22. Tuy nhiên, các loại đặc quyền mới đã được thêm vào trong phiên bản 4. 0, phần nào đã thay đổi cách mô-đun này được sử dụng bởi phần còn lại của mã. Các nhà phát triển MySQL đang có kế hoạch thêm hỗ trợ cho các vai trò, điều này sẽ yêu cầu những thay đổi đáng kể đối với mô-đun này Trình phân tích cú pháp chịu trách nhiệm phân tích cú pháp truy vấn và tạo cây phân tích cú pháp. Điểm vào là
Khi các tính năng SQL mới được thêm vào, trình phân tích cú pháp sẽ tiếp tục thay đổi để phù hợp với chúng. Tuy nhiên, cấu trúc cốt lõi của trình phân tích cú pháp khá ổn định và cho đến nay đã có thể đáp ứng sự phát triển. Thật hợp lý khi kỳ vọng rằng trong khi một số yếu tố sẽ được thêm vào, thì cốt lõi sẽ không bị thay đổi nhiều trong một thời gian. Các nhà phát triển MySQL đã và đôi khi vẫn nói về việc viết lại cốt lõi của trình phân tích cú pháp và chuyển nó ra khỏi yacc/Bison để làm cho nó nhanh hơn. Tuy nhiên, họ đã nói về nó ít nhất bảy năm rồi và điều này vẫn chưa trở thành ưu tiên Bộ điều phối lệnh chịu trách nhiệm hướng các yêu cầu đến các mô-đun cấp thấp hơn sẽ biết cách giải quyết chúng. Nó bao gồm hai hàm trong sql/sql_ parse. cc. Mô-đun tiếp tục phát triển theo thời gian khi tập hợp các lệnh được hỗ trợ tăng lên. Dự kiến tăng trưởng nhỏ trong tương lai, nhưng cấu trúc cốt lõi khó có thể thay đổi Mô-đun bộ nhớ đệm truy vấn lưu trữ các kết quả truy vấn trong bộ đệm ẩn và cố gắng rút ngắn thời gian thực hiện các truy vấn bằng cách cung cấp kết quả được lưu trong bộ đệm ẩn bất cứ khi nào có thể. Nó được thực hiện trong sql/sql_cache. cc. Một số phương pháp quan tâm bao gồm
Mô-đun đã được thêm vào trong phiên bản 4. 0. Một số thay đổi ngoài việc sửa lỗi được mong đợi trong tương lai Trình tối ưu hóa chịu trách nhiệm tạo chiến lược tốt nhất để trả lời truy vấn và thực hiện nó để cung cấp kết quả cho khách hàng. Nó có lẽ là mô-đun phức tạp nhất trong mã MySQL. Điểm vào là
Khi bạn đi sâu vào trình tối ưu hóa, có một hang động đáng để ghé thăm. Nó là trình tối ưu hóa phạm vi, đủ tách biệt với lõi của trình tối ưu hóa và đủ phức tạp để được tách thành một tệp riêng biệt, sql/opt_range. cc. Trình tối ưu hóa phạm vi chịu trách nhiệm tối ưu hóa các truy vấn sử dụng khóa có phạm vi giá trị nhất định hoặc tập hợp các phạm vi. Điểm vào cho trình tối ưu hóa phạm vi là Trình tối ưu hóa luôn ở trạng thái thay đổi. Việc bổ sung các truy vấn con trong 4. 1 đã thêm một lớp phức tạp khác. Phiên bản 5. 0 đã thêm một tìm kiếm tham lam cho thứ tự tham gia bảng tối ưu và khả năng sử dụng một số khóa trên mỗi bảng (hợp nhất chỉ mục). Thật hợp lý khi mong đợi rằng nhiều thay đổi hơn nữa sẽ được thực hiện trong tương lai. Một thay đổi được chờ đợi từ lâu là những cải tiến trong việc tối ưu hóa các truy vấn phụ Trình quản lý bảng chịu trách nhiệm tạo, đọc và sửa đổi các tệp định nghĩa bảng (. frm), duy trì bộ đệm của bộ mô tả bảng được gọi là bộ đệm bảng và quản lý khóa cấp bảng. Hầu hết các mã được tìm thấy trong sql/sql_base. cc, sql/bảng. cc, sql/unireg. cc và sql/khóa. cc. Mô-đun này sẽ được thảo luận chi tiết trong Chương 9. Một số chức năng quan tâm bao gồm
Mã không thay đổi nhiều kể từ phiên bản 3. 22 ngoại trừ định dạng tệp định nghĩa bảng mới trong phiên bản 4. 1. Trong quá khứ, Monty đã bày tỏ sự không hài lòng với sự thiếu hiệu quả trong mã bộ nhớ cache của bảng và muốn viết lại nó. Trong một thời gian, đây không phải là ưu tiên hàng đầu. Tuy nhiên, một số tiến bộ cuối cùng đã được thực hiện trong phiên bản 5. 1 Mô-đun sửa đổi bảngTập hợp các mô-đun này chịu trách nhiệm cho các hoạt động như tạo, xóa, đổi tên, xóa, cập nhật hoặc chèn vào bảng. Đây thực sự là một đoạn mã rất quan trọng. Rất tiếc, do hạn chế về không gian, cuốn sách này sẽ không đề cập chi tiết. Tuy nhiên, khi bạn đã quen thuộc với phần còn lại của mã, bạn sẽ có thể tìm ra chi tiết bằng cách đọc nguồn và sử dụng trình gỡ lỗi mà không gặp quá nhiều khó khăn bằng cách bắt đầu từ các điểm nhập sau
Các mô-đun Cập nhật và Xóa đã được thay đổi đáng kể trong phiên bản 4. 0 với việc bổ sung các cập nhật và xóa nhiều bảng. Một số tổ chức lại cũng đã xảy ra trong các mô-đun Cập nhật, Chèn và Xóa để hỗ trợ các câu lệnh đã chuẩn bị sẵn trong phiên bản 4. 1 và kích hoạt trong 5. 1. Mặt khác, ngoài những cải tiến khá nhỏ theo thời gian, chúng không thay đổi nhiều. Thật hợp lý khi kỳ vọng rằng phần lớn mã sẽ vẫn như vậy trong tương lai Mô-đun bảo trì bảng chịu trách nhiệm cho các hoạt động bảo trì bảng như kiểm tra, sửa chữa, sao lưu, khôi phục, tối ưu hóa (chống phân mảnh) và phân tích (cập nhật thống kê phân phối khóa). Mã được tìm thấy trong sql/sql_table. cc. Chức năng cốt lõi là
Mô-đun được giới thiệu trong phiên bản 3. 23 để cung cấp giao diện SQL để bảo trì bảng. Trước đó, việc bảo trì bảng phải được thực hiện ngoại tuyến. Trong phiên bản 4. 1, các thay đổi quan trọng đã được thực hiện đối với Mô-đun Giao thức Mạng để hỗ trợ các câu lệnh đã chuẩn bị. Điều này ảnh hưởng đến tất cả các mô-đun trao đổi lại với máy khách, bao gồm cả Mô-đun bảo trì bảng. Mặt khác, không có nhiều thay đổi kể từ khi được giới thiệu và thật hợp lý khi kỳ vọng rằng sẽ không có nhiều thay đổi trong tương lai Mô-đun báo cáo trạng thái chịu trách nhiệm trả lời các truy vấn về cài đặt cấu hình máy chủ, các biến theo dõi hiệu suất, thông tin cấu trúc bảng, tiến trình sao chép, tình trạng của bộ đệm bảng và những thứ khác. Nó xử lý các truy vấn bắt đầu bằng
Mô-đun đã không ngừng phát triển. Việc bổ sung chức năng mới đã tạo ra nhu cầu báo cáo trạng thái bổ sung. Thật hợp lý khi kỳ vọng rằng mô hình này sẽ tiếp tục trong tương lai Giao diện công cụ lưu trữ trừu tượng (Trình xử lý bảng)Mô-đun này thực sự là một lớp trừu tượng có tên là trình xử lý và một cấu trúc được gọi là trình xử lý. Cấu trúc handlerton đã được thêm vào trong phiên bản 5. 1 để tích hợp plug-in. Nó cung cấp một giao diện được tiêu chuẩn hóa để thực hiện các thao tác truy xuất và lưu trữ ở mức độ thấp Trình xử lý bảng được định nghĩa trong sql/handler. h và được triển khai một phần trong sql/handler. cc. Các lớp công cụ lưu trữ cụ thể dẫn xuất sẽ phải triển khai tất cả các phương thức ảo thuần túy của lớp này. Nó sẽ được thảo luận chi tiết hơn trong Chương 9 Mô-đun này đã được giới thiệu trong phiên bản 3. 23 để tạo thuận lợi cho việc tích hợp các bảng Berkeley DB. Động thái này đã có những hậu quả sâu rộng. giờ đây, nhiều công cụ lưu trữ cấp thấp có thể được đặt bên dưới MySQL một cách dễ dàng. Mã đã được tinh chỉnh thêm trong quá trình tích hợp InnoDB. Tương lai của mô-đun sẽ phụ thuộc phần lớn vào công cụ lưu trữ mới nào sẽ được tích hợp vào MySQL và cách thức những công cụ lưu trữ hiện có sẽ thay đổi. Ví dụ: đôi khi một tính năng mới trong một số công cụ lưu trữ cơ bản có thể yêu cầu bổ sung giao diện trừu tượng để cung cấp cho các mô-đun cấp cao hơn Triển khai công cụ lưu trữ (MyISAM, InnoDB, MEMORY, Berkeley DB)Mỗi công cụ lưu trữ cung cấp một giao diện tiêu chuẩn cho các hoạt động của nó bằng cách mở rộng lớp trình xử lý đã đề cập trước đó. Các phương thức của lớp dẫn xuất xác định các hoạt động giao diện tiêu chuẩn theo các lệnh gọi cấp thấp của công cụ lưu trữ cụ thể. Quá trình này và công cụ lưu trữ riêng lẻ sẽ được thảo luận chi tiết trong Chương 10. Trong khi đó, để giới thiệu nhanh, bạn có thể muốn xem qua một số tệp và thư mục quan tâm
Khi giao diện công cụ lưu trữ lần đầu tiên được trừu tượng hóa (phiên bản 3. 23), chỉ có ba công cụ lưu trữ đầy đủ chức năng. MyISAM, ISAM (phiên bản MyISAM cũ hơn) và BỘ NHỚ. (Lưu ý rằng công cụ lưu trữ BỘ NHỚ từng được gọi là HEAP và một số tên tệp và thư mục trong cây nguồn vẫn phản ánh tên trước đó. ) Tuy nhiên, danh sách đã tăng lên nhanh chóng với việc bổ sung BerkeleyDB, MERGE, InnoDB và gần đây hơn là NDB cho Cụm MySQL. Hầu hết các công cụ lưu trữ vẫn đang trong quá trình phát triển khá tích cực và chúng tôi có thể thấy một số công cụ mới được thêm vào trong tương lai Mô-đun ghi nhật ký chịu trách nhiệm duy trì nhật ký (logic) cấp cao hơn. Ngoài ra, một công cụ lưu trữ có thể duy trì các nhật ký cấp thấp hơn (vật lý hoặc logic) của riêng nó cho các mục đích riêng của nó, nhưng Mô-đun ghi nhật ký sẽ không quan tâm đến những nhật ký đó; . Nhật ký logic tại thời điểm này bao gồm nhật ký cập nhật nhị phân (được sử dụng chủ yếu để sao chép), nhật ký lệnh (được sử dụng chủ yếu để giám sát máy chủ và gỡ lỗi ứng dụng) và nhật ký truy vấn chậm (được sử dụng để theo dõi các truy vấn được tối ưu hóa kém) Trước phiên bản 5. 1, phần lớn mô-đun được chứa bởi lớp Tuy nhiên, hầu hết công việc ghi nhật ký xảy ra trong nhật ký sao chép nhị phân. Các lớp để tạo và đọc sự kiện nhật ký cho nhật ký sao chép nhị phân được định nghĩa trong sql/log_event. h và được triển khai trong sql/log_event. cc. Cả mô-đun Replication Master và Replication Slave đều phụ thuộc rất nhiều vào chức năng này của Mô-đun ghi nhật ký Những thay đổi đáng kể đã được thực hiện cho mô-đun này với việc giới thiệu bản sao. Phiên bản 5. 0 mang lại một số thay đổi cần thiết cho các giao dịch XA. Phiên bản 5. 1 đã thêm khả năng tìm kiếm nhật ký như thể chúng là một bảng SQL, yêu cầu tái cấu trúc đáng kể mã này. Phần ghi nhật ký nhị phân yêu cầu các thay đổi quan trọng để phù hợp với bản sao dựa trên hàng. Tại thời điểm này, thật khó để dự đoán mã này sẽ đi về đâu trong tương lai Mô-đun tổng thể sao chépReplication Master Module chịu trách nhiệm về chức năng sao chép trên master. Hoạt động phổ biến nhất cho mô-đun này là cung cấp nguồn cấp dữ liệu liên tục các sự kiện nhật ký sao chép cho nô lệ theo yêu cầu. Hầu hết mã được tìm thấy trong sql/sql_repl. cc. Chức năng cốt lõi là Mô-đun đã được thêm vào trong phiên bản 3. 23 và nó không trải qua bất kỳ thay đổi lớn nào ngoài việc dọn dẹp kỹ lưỡng để tách các đoạn mã thành các chức năng. Ban đầu, mã này có các kế hoạch phát triển rất tham vọng để sao chép không an toàn. Tuy nhiên, trước khi các kế hoạch đó có thể được thực hiện, MySQL đã mua mã NDB Cluster từ Ericsson và bắt đầu theo đuổi một lộ trình khác đến mục tiêu cuối cùng là chuyển đổi dự phòng tự động. Trước những phát triển đó, tại thời điểm này vẫn chưa rõ quá trình sao chép MySQL gốc sẽ tiến triển như thế nào Mô-đun này sẽ được thảo luận chi tiết hơn trong Chương 12 Mô-đun nô lệ sao chép chịu trách nhiệm về chức năng sao chép của nô lệ. Vai trò của nô lệ là truy xuất các bản cập nhật từ chủ và áp dụng chúng trên nô lệ. Nô lệ bắt đầu từ phiên bản 4. 0 là hai luồng. Chuỗi I/O mạng yêu cầu và nhận nguồn cấp dữ liệu cập nhật liên tục từ chủ và ghi chúng vào nhật ký chuyển tiếp cục bộ. Chuỗi SQL áp dụng chúng khi nó đọc chúng từ nhật ký chuyển tiếp. Mã cho mô-đun này được tìm thấy trong sql/slave. cc. Các chức năng quan trọng nhất để nghiên cứu là Các mô-đun đã được thêm vào trong 3. 23 cùng với mô-đun Replication Master. Nó đã trải qua một sự thay đổi đáng kể trong phiên bản 4. 0 khi luồng nô lệ nguyên khối được chia thành luồng SQL và luồng I/O Mô-đun này sẽ được thảo luận chi tiết hơn trong Chương 12 API giao thức máy khách/máy chủGiao thức truyền thông máy khách/máy chủ MySQL nằm trên giao thức hệ điều hành (TCP/IP hoặc ổ cắm cục bộ) trong ngăn xếp giao thức. Mô-đun này triển khai API được sử dụng trên máy chủ để tạo, đọc, diễn giải và gửi các gói giao thức. Mã được tìm thấy trong sql/protocol. cc, sql/giao thức. h và sql/net_serv. cc Các tệp sql/giao thức. h và sql/giao thức. cc xác định và triển khai hệ thống phân cấp của các lớp.
Trong phiên bản 4. 0, giao thức đã được thay đổi để hỗ trợ các gói có kích thước lên tới 4 GB. Trước đó, giới hạn là 24 MB. Hệ thống phân cấp lớp Giao thức đã được thêm vào trong phiên bản 4. 1 để đối phó với báo cáo chuẩn bị. Có vẻ như tại thời điểm này, hầu hết các khu vực có vấn đề trong giao thức ở cấp độ này đã được giải quyết và thật hợp lý khi kỳ vọng rằng mã này sẽ không thay đổi nhiều trong tương lai gần. Tuy nhiên, các nhà phát triển MySQL đang nghĩ đến việc thêm hỗ trợ cho thông báo Mô-đun này sẽ được thảo luận chi tiết hơn trong Chương 5 API I/O mạng cấp thấpAPI I/O mạng cấp thấp cung cấp một bản tóm tắt cho các phiên I/O và SSL mạng cấp thấp. Mã được tìm thấy trong thư mục vio/. Tất cả các chức năng trong mô-đun này có tên bắt đầu bằng Mô-đun này đã được giới thiệu trong 3. 23, được thúc đẩy bởi nhu cầu hỗ trợ kết nối SSL. Trừu tượng hóa I/O mạng cấp thấp cũng tạo điều kiện thuận lợi cho việc chuyển sang các nền tảng mới và duy trì các cổng cũ API cốt lõi là con dao quân đội Thụy Sĩ của MySQL. Nó cung cấp chức năng cho I/O tệp di động, quản lý bộ nhớ, thao tác chuỗi, điều hướng hệ thống tệp, in định dạng, bộ sưu tập cấu trúc dữ liệu và thuật toán phong phú, cùng một số thứ khác. Nếu có vấn đề phát sinh, thường có giải pháp cho vấn đề đó trong Mô-đun API lõi. Nếu không có, nó sẽ được mã hóa. Mô-đun này phần lớn thể hiện khả năng và quyết tâm của Monty không bao giờ chỉ giải quyết một vấn đề. Nó có lẽ là thành phần cốt lõi của Phép lạ của MySQL Mã này nằm trong thư mục mysys/ và strings/. Nhiều chức năng API cốt lõi có tên bắt đầu bằng Mô-đun luôn trong tình trạng phát triển và cải tiến. Khi chức năng mới được thêm vào, chúng tôi hết sức cẩn thận để duy trì tính ổn định và mức hiệu suất cao của nó. Thật hợp lý khi kỳ vọng rằng mô hình này sẽ tiếp tục trong tương lai MySQL được phát triển khi nào?Phiên bản đầu tiên của MySQL xuất hiện vào 23 tháng 5 năm 1995 .
Lần đầu tiên MySQL được phát hành là khi nào?Công ty MySQL AB của Thụy Điển phát hành MySQL lần đầu tiên vào 1995 .
Ai đã tạo ra MySQL?MySQL, hệ thống quản lý cơ sở dữ liệu SQL nguồn mở phổ biến nhất, được phát triển, phân phối và hỗ trợ bởi Tập đoàn Oracle .
Tại sao MySQL được tạo ra?MySQL do công ty MySQL AB của Thụy Điển tạo ra vào năm 1995. Các nhà phát triển của nền tảng này là Michael Widenius (Monty), David Axmark và Allan Larsson. Mục đích quan trọng nhất là cung cấp các tùy chọn quản lý dữ liệu hiệu quả và đáng tin cậy cho người dùng gia đình và người dùng chuyên nghiệp . |
