Loại từ điển MySQL

Bài đăng trên blog này trình bày chi tiết về kiến ​​trúc và thiết kế của từ điển dữ liệu giao dịch sẽ là một phần của MySQL 8. 0. Một số mô tả về kiến ​​trúc sẽ được thực hiện trong các phiên bản sau. Xem  MySQL 8. 0 Từ điển dữ liệu. Bối cảnh và động lực

Lược đồ từ điển dữ liệu MySQLTừ điển dữ liệu giao dịch trong 8. 0 có cách xử lý dữ liệu từ điển đơn giản và thống nhất

Bảng  từ điển và bảng hệ thống lưu trữ dữ liệu và siêu dữ liệu mà máy chủ MySQL cần. Các bảng từ điển được thiết kế dựa trên chuẩn SQL. “Bảng hệ thống” chứa dữ liệu meta hoặc dữ liệu trong lược đồ mysql. Các bảng từ điển được thiết kế để có thể mở rộng. Lưu ý rằng do đó, bạn sẽ không tìm thấy bất kỳ trường "tương lai" nào trong định nghĩa bảng. Vui lòng xem WL#6379 để biết chi tiết về định nghĩa lược đồ của các bảng từ điển dữ liệu

Nâng cấp từ 8. 0 và chuyển tiếp

Từ điển dữ liệu sẽ có một bảng phiên bản. Điều này sẽ cho phép nâng cấp tự động từ 8. 0 và chuyển tiếp trên các bảng từ điển dữ liệu

I_S dưới dạng chế độ xem trên Bảng từ điển dữ liệu

LƯỢC ĐỒ THÔNG TIN hiện được triển khai dưới dạng các khung nhìn trên các bảng từ điển, không yêu cầu truy cập thêm đĩa, không tạo các bảng tạm thời và có thể xử lý các bộ ký tự và đối chiếu tương tự như các bảng người dùng

Hệ sinh thái của INFORMATION_SCHEMAAPI cho Từ điển dữ liệu

Chúng tôi sẽ triển khai API thống nhất cho từ điển dữ liệu. API này sau đó sẽ được sử dụng bởi mã nội bộ của máy chủ, mã API dịch vụ plugin và công cụ lưu trữ, thông qua API SE. Điều này sẽ được thực hiện theo cách có khả năng xâm nhập thấp đối với mã máy chủ truy cập từ điển dữ liệu, vì vậy mã có thể được cấu trúc lại từng phần

Bộ đệm từ điển dữ liệu mới

Có nhiều bộ nhớ đệm trong MySQL và những bộ nhớ đệm này không phải lúc nào cũng ẩn đằng sau  API. Việc triển khai bộ đệm mới nhằm mục đích thay thế cho nhiều bộ đệm và bộ đệm mới này được ẩn sau API từ điển dữ liệu. Hiện tại, chúng tôi chưa thay thế bất kỳ bộ đệm cũ nào, nhưng đã cải tiến chúng để sử dụng bộ đệm mới. Trong tương lai, chúng tôi sẽ cấu trúc lại các bộ đệm cũ, tạo các API phù hợp cho chúng và điều chỉnh mã của người gọi. Điều này sẽ đơn giản hóa mã của người gọi và di chuyển tất cả logic bộ đệm đằng sau API

API SE mới cho DDL nguyên tử và crashsafe

Chúng tôi muốn cung cấp DDL nguyên tử và an toàn sự cố và điều này yêu cầu các thay đổi đối với mã DDL của máy chủ MySQL và mã InnoDB nơi lưu trữ các bảng từ điển. Mã máy chủ MySQL sẽ loại bỏ tất cả các cam kết ngầm định và triển khai ngữ nghĩa nguyên tử rõ ràng cho các câu lệnh DDL. Để kích hoạt tính năng này, các bảng phải được lưu trữ trong công cụ lưu trữ giao dịch và chúng tôi sẽ sử dụng InnoDB

Với API SE mới, chúng tôi có thể triển khai DDL an toàn khi lưu trữ từ điển dữ liệu là InnoDB vốn có hành vi chuyển đổi

Thông tin từ điển được tuần tự hóa và các thay đổi đối với câu lệnh IMPORT

Nhiều người dùng đã tỏ ra yêu thích khả năng sao chép dữ liệu bảng và tệp FRM vào THƯ MỤC DỮ LIỆU và máy chủ MySQL sẽ tự động chọn các bảng này. Khả năng này cũng đã được sử dụng để khắc phục thảm họa, nơi. FRM “đai đen” đã có thể tái tạo lại siêu dữ liệu trong. tập tin FRM. Trong Mysql 8. 0 chúng tôi cung cấp thông tin Từ điển nối tiếp cho các đối tượng từ điển. Đối với  không gian bảng InnoDB, thông tin này được thêm vào không gian bảng, vì vậy dữ liệu meta và dữ liệu được nhóm lại với nhau. Đối với các công cụ lưu trữ không hỗ trợ chức năng này, một. Tệp SDI sẽ được ghi

Lưu ý hướng một chiều của mũi tên chỉ ra rằng SDI là một bản sao

 

Đối với các không gian bảng InnoDB, một công cụ sẽ được cung cấp để đọc thông tin SDI. Thông tin SDI là định dạng JSON. Vì vậy, khả năng sửa đổi SDI giống như người dùng có với. Các tệp FRM để khắc phục thảm họa được cung cấp

Một “nguồn chân lý”

Chúng ta sẽ có một từ điển toàn cầu. Vì vậy, InnoDB sẽ điền vào bộ đệm từ điển InnoDB từ từ điển dữ liệu toàn cầu. Sau đó, chúng tôi sẽ loại bỏ lớp vấn đề mà trước đây được gọi là vấn đề “chia não”

E. g. thủ tục bộ đệm và, nếu chiến lược khóa trước quy định như vậy, hãy mở rộng tập hợp khóa trước với các bảng và thủ tục được sử dụng bởi nó

Tham số[in]thdThread bối cảnh. [in]prelocking_ctxBối cảnh khóa trước. [in]rtPhần tử khóa trước được thiết lập để xử lý. [in]prelocking_strategyStrategy chỉ định cách mở rộng bộ khóa trước khi một trong các phần tử của nó được xử lý. [in]has_prelocking_listCho biết rằng bộ/danh sách khóa sẵn cho câu lệnh này đã được tạo. [in]ot_ctxContext của open_table được sử dụng để khôi phục sau các lỗi khóa. [out]need_prelockingĐặt thành true nếu phát hiện thấy rằng câu lệnh này sẽ yêu cầu chế độ khóa sẵn để thực thi, nếu không thì không được chạm vào. [out]routine_modify_dataĐặt thành true nếu phát hiện thấy quy trình này sửa đổi dữ liệu bảng. Trả về giá trị falseSuccess. trueFailure [Xung đột khóa siêu dữ liệu, OOM, các lỗi khác]

Chúng tôi thêm các mục kích hoạt vào lex->sroutines_list, nhưng chúng tôi không tải chúng ở đây. Mục kích hoạt chỉ được sử dụng khi xây dựng một bao đóng chuyển tiếp của các đối tượng được sử dụng trong một câu lệnh, để tránh thêm vào bao đóng này các đối tượng được sử dụng nhiều hơn một lần trong trình kích hoạt. e. g. nếu trình kích hoạt trg đề cập đến bảng t2 và bảng kích hoạt t1 được sử dụng nhiều lần trong câu lệnh [giả sử vì nó được sử dụng trong hàm f1[] hai lần], chúng tôi sẽ chỉ thêm t2 một lần vào danh sách các bảng để khóa trước

Chúng tôi cũng không khóa siêu dữ liệu trên trình kích hoạt. chúng được bảo vệ bởi một khóa tương ứng trên bàn, trên đó xác định trình kích hoạt

Hai trường hợp duy nhất gây ra "sự cố" là câu lệnh SHOW CREATE TRIGGER và DROP TRIGGER. Đối với những điều này, cú pháp câu lệnh không chỉ định bảng mà trình kích hoạt này được xác định, vì vậy chúng tôi phải đọc "bẩn" trong từ điển dữ liệu để tìm ra tên bảng. Khi chúng tôi phát hiện ra tên bảng, chúng tôi sẽ khóa siêu dữ liệu trên đó và điều này bảo vệ tất cả các hoạt động kích hoạt. Tất nhiên, về mặt lý thuyết, bảng có thể biến mất giữa quá trình đọc bẩn và thu thập khóa siêu dữ liệu, nhưng trong trường hợp đó, chúng tôi chỉ trả về lỗi thời gian chạy

Ngữ pháp của các câu lệnh DDL trình kích hoạt khác [CREATE, DROP] yêu cầu bảng phải được chỉ định rõ ràng, vì vậy chúng tôi sử dụng khóa siêu dữ liệu bảng để bảo vệ siêu dữ liệu trình kích hoạt trong các câu lệnh này. Tương tự, trong DML, chúng tôi luôn sử dụng trình kích hoạt cùng với bảng của chúng và do đó không cần thực hiện khóa siêu dữ liệu riêng cho chúng

Các loại từ điển dữ liệu là gì?

Các kiểu dữ liệu MySQL là gì?

Làm cách nào để kiểm tra kiểu dữ liệu trong MySQL?

Định dạng từ điển dữ liệu là gì?