Với hầu hết, nếu không phải là tất cả năm 2018 ở phía sau chúng ta (tùy thuộc vào thời điểm bạn đọc bài đăng này), chắc chắn rằng đó là một năm tuyệt vời đối với cơ sở dữ liệu SQL mã nguồn mở.
PostgreSQL 11 và MySQL 8 đều được phát hành, cung cấp cho cả hai cộng đồng nhiều điều để ' nói về '. Sự thật mà nói, cả hai nhà cung cấp đều đã giới thiệu nhiều thay đổi và bổ sung đáng kể trong các bản phát hành tương ứng của họ và xứng đáng nhận được sự khen ngợi và tán thưởng của họ.
Tôi thường đăng bài của khách về cái cũ ở đây trên blog Somenines (Rất cám ơn một tổ chức tuyệt vời!) Nhưng tôi cũng quan tâm đến cái sau. Với nhiều bài đăng blog trên trang web của riêng tôi (liên kết trong phần tiểu sử của tôi), chủ yếu nhắm mục tiêu MySQL phiên bản 5.7, nó (MySQL) luôn ở trong thiết bị ngoại vi của tôi.
Vậy MySQL 8 có gì mà phiên bản 5.7 không có? Những cải tiến là gì? Chà, có rất nhiều. Trên thực tế, có quá nhiều thứ để chỉ trong một bài đăng trên blog.
Gần đây, tôi đã nâng cấp lên phiên bản 8 trong môi trường học tập / phát triển Linux hiện tại của mình, vì vậy tôi nghĩ hãy thử chỉ ra một số trong số chúng.
Tôi không thể đảm bảo cho bạn một cuộc thảo luận chuyên sâu về ' yêu thích của bạn ' Các tính năng mới). Mặt khác, tôi sẽ ghé thăm những người đã thu hút sự chú ý của tôi thông qua sở thích cá nhân hoặc qua nhiều bài đăng blog tuyệt vời được xuất bản trong suốt cả năm trên phiên bản 8.
MySQL ngày càng tốt hơn ... Những cải tiến đáng kể trong phiên bản 8!
Vai trò
Với Vai trò, DBA có thể giảm thiểu tình trạng dư thừa, trong đó nhiều người dùng sẽ chia sẻ cùng một đặc quyền hoặc một tập hợp các đặc quyền.
Vai trò là một phần của tiêu chuẩn SQL.
Sau khi tạo một vai trò cụ thể với (các) đặc quyền mong muốn / bắt buộc, bạn có thể chỉ định cho người dùng vai trò cụ thể đó thông qua lệnh GRANT hoặc tương tự như vậy, ' taketh away 'với REVOKE.
Vai trò đi kèm với nhiều lợi ích và để làm cho cuộc sống dễ dàng hơn một chút, có một số bảng giúp bạn theo dõi chúng:
-
mysql.role_edges - Tại đây bạn tìm thấy những vai trò đó và những người dùng mà họ được chỉ định.
mysql> DESC mysql.role_edges; +-------------------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+---------------+------+-----+---------+-------+ | FROM_HOST | char(60) | NO | PRI | | | | FROM_USER | char(32) | NO | PRI | | | | TO_HOST | char(60) | NO | PRI | | | | TO_USER | char(32) | NO | PRI | | | | WITH_ADMIN_OPTION | enum('N','Y') | NO | | N | | +-------------------+---------------+------+-----+---------+-------+ 5 rows in set (0.01 sec) -
mysql.default_roles - Lưu trữ mọi vai trò mặc định và những người dùng được chỉ định.
mysql> DESC mysql.default_roles; +-------------------+----------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+----------+------+-----+---------+-------+ | HOST | char(60) | NO | PRI | | | | USER | char(32) | NO | PRI | | | | DEFAULT_ROLE_HOST | char(60) | NO | PRI | % | | | DEFAULT_ROLE_USER | char(32) | NO | PRI | | | +-------------------+----------+------+-----+---------+-------+ 4 rows in set (0.00 sec)
Sự kết hợp của cả hai bảng (không theo nghĩa SQL JOIN) về cơ bản cung cấp một ' vị trí tập trung 'nơi bạn có thể:biết, giám sát và đánh giá tất cả các mối quan hệ và nhiệm vụ đặc quyền vai trò người dùng đã triển khai của bạn.
Có thể tình huống sử dụng vai trò mẫu đơn giản nhất sẽ là:
Bạn có một số người dùng cần ' quyền truy cập chỉ đọc 'trên một bảng cụ thể, do đó, yêu cầu ít nhất đặc quyền SELECT. Thay vì cấp nó (CHỌN) riêng lẻ cho từng người dùng, bạn có thể thiết lập (tạo) một vai trò có đặc quyền đó, sau đó chỉ định vai trò đó cho những người dùng đó.
Tuy nhiên, các vai trò đi kèm với một ' bắt nhỏ' '. Sau khi được tạo và gán cho người dùng, người dùng nhận phải có vai trò mặc định hoạt động được đặt trong quá trình xác thực khi đăng nhập.
Trong khi về chủ đề vai trò và người dùng, tôi cảm thấy điều quan trọng là phải đề cập đến thay đổi được triển khai trong MySQL 8 liên quan đến thành phần validate_password, là một biến thể của plugin validate_password được sử dụng trong phiên bản 5.7.
Thành phần này cung cấp nhiều ' danh mục khác nhau 'kiểm tra mật khẩu:thấp, trung bình (mặc định) và mạnh. Hãy truy cập vào tài liệu thành phần validate_password để biết thông tin tóm tắt đầy đủ về thông số kỹ thuật xác thực của từng cấp độ.
NoSQL Mingling với SQL - Kho tài liệu
Tính năng này là một tính năng mà tôi vẫn đang tìm hiểu, mặc dù có sự quan tâm thoáng qua đến MongoDB vào đầu năm 2016. Đến nay, mối quan tâm, nghiên cứu và tìm hiểu của tôi chỉ tập trung vào 'SQL'. Tuy nhiên, tôi biết (thông qua việc đọc nhiều trên web) rằng nhiều người hào hứng với kiểu cấu trúc này (hướng tài liệu) đan xen với 'SQL quan hệ' hiện đã có trong kho tài liệu MySQL 8.
Dưới đây là nhiều lợi ích có được khi sử dụng kho tài liệu. Hãy chắc chắn và đề cập đến mục yêu thích của bạn mà tôi có thể đã bỏ qua trong phần nhận xét:
- Kiểu dữ liệu JSON đã được hỗ trợ kể từ phiên bản MySQL 5.7.8, phiên bản 8 đã giới thiệu những cải tiến đáng kể để làm việc với JSON. Các chức năng cụ thể mới của JSON cùng với ' tốc ký 'các toán tử có thể được sử dụng thay cho nhiều lệnh gọi hàm - với kết quả / đầu ra như nhau.
- Có lẽ một trong những lợi ích quan trọng nhất là bạn không cần phải triển khai và làm việc với nhiều giải pháp cơ sở dữ liệu nữa vì NoSQL, SQL hoặc kết hợp cả hai đều được hỗ trợ trong kho tài liệu.
- "DevAPI", cung cấp khả năng quy trình làm việc liền mạch trong ngữ cảnh dữ liệu NoSQL (bộ sưu tập và tài liệu). (Truy cập tài liệu hướng dẫn sử dụng DevAPI chính thức để biết thêm thông tin).
- Các phiên dòng lệnh mạnh mẽ sử dụng Python, SQL hoặc Javascript làm ngôn ngữ 'shell'.
- Tuân thủ ACID.
- Nhanh chóng khám phá và khám phá dữ liệu của bạn mà không cần xác định lược đồ như cách bạn làm trong mô hình quan hệ.
Biểu thức bảng phổ biến (CTE hoặc mệnh đề WITH)
Bạn có thể nói gì khác về CTE's? Những điều này là một thay đổi cuộc chơi! Đối với những người mới bắt đầu, chính xác thì biểu thức bảng chung là gì?
Từ Wikipedia:
"Biểu thức bảng thông thường, hoặc CTE, (trong SQL) là một tập kết quả được đặt tên tạm thời, bắt nguồn từ một truy vấn đơn giản và được xác định trong phạm vi thực thi của câu lệnh SELECT, INSERT, UPDATE hoặc DELETE."
Tôi sẽ cung cấp một ví dụ đơn giản, minh họa CTE. Tuy nhiên, toàn bộ sức mạnh của chúng không được khai thác trong phần này, vì có nhiều ví dụ trường hợp sử dụng phức tạp hơn những ví dụ này.
Tôi có một bảng tên đơn giản với mô tả và dữ liệu này:
mysql> DESC name;
+--------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| f_name | varchar(20) | YES | | NULL | |
| l_name | varchar(20) | YES | | NULL | |
+--------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)mysql> SELECT * FROM name;
+--------+------------+
| f_name | l_name |
+--------+------------+
| Jim | Dandy |
| Johhny | Applesauce |
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+------------+
5 rows in set (0.00 sec)Hãy cùng tìm hiểu xem có bao nhiêu họ bắt đầu bằng 'Z':
mysql> SELECT *
-> FROM name
-> WHERE l_name LIKE 'Z%';
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+--------+
3 rows in set (0.00 sec)Đủ dễ dàng.
Tuy nhiên, bằng cách sử dụng mệnh đề WITH, bạn có thể ' truy cập 'cùng một bộ kết quả truy vấn này (có thể được coi là một bảng dẫn xuất) và tham chiếu đến nó sau này trong cùng một câu lệnh - hoặc' phạm vi ':
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%')
SELECT * FROM last_Z;
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+--------+
3 rows in set (0.00 sec)Về cơ bản, tôi chỉ định tên cho truy vấn, đặt nó trong dấu ngoặc đơn. Sau đó, chỉ cần chọn dữ liệu tôi muốn từ dữ liệu bây giờ là last_Z CTE.
CTE last_Z cung cấp một tập hợp kết quả hoàn chỉnh, vì vậy bạn có thể lọc tập hợp kết quả đó hơn nữa trong cùng một câu lệnh:
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%')
SELECT f_name, l_name FROM last_Z WHERE l_name LIKE '%a';
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashton | Zerra |
+--------+--------+
1 row in set (0.00 sec)Một số tính năng mạnh mẽ hơn là ' chuỗi 'nhiều CTE cùng nhau và tham chiếu đến các CTE khác trong CTE.
Đây là một ví dụ để cung cấp cho bạn một ý tưởng (mặc dù không hữu ích lắm):
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%'),
best_friend AS (
SELECT f_name, l_name
FROM last_Z
WHERE l_name LIKE '%a')
SELECT * from best_friend;
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashton | Zerra |
+--------+--------+
1 row in set (0.00 sec)Trong truy vấn trên, bạn có thể thấy nơi tôi đã tách CTE last_Z khỏi CTE best_friend bằng dấu phẩy, sau đó gói truy vấn đó trong dấu ngoặc đơn sau từ khóa AS.
Lưu ý rằng sau đó tôi có thể tham khảo (và sử dụng) CTE last_Z để xác định về cơ bản CTE best_friend.
Dưới đây là một vài lý do tại sao CTE lại là một cải tiến đáng kể trong phiên bản 8:
- Các nhà cung cấp SQL khác đã hỗ trợ CTE (nhiều nhà cung cấp kể từ các phiên bản trước đó trong hệ sinh thái cá nhân của họ) và bây giờ là MySQL 8, đã thu hẹp khoảng cách trong lĩnh vực này.
- Bao gồm SQL tiêu chuẩn.
- Trong một số trường hợp (nếu thích hợp), CTE là một lựa chọn tốt hơn so với Bảng tạm thời, Chế độ xem, Bảng dẫn xuất (hoặc Chế độ xem nội tuyến) và một số truy vấn con.
- CTE's có thể cung cấp ' on-the-fly 'bộ kết quả tính toán mà bạn có thể truy vấn.
- Một CTE có thể tự tham chiếu - được gọi là CTE đệ quy (không được trình bày ở đây).
- CTE có thể đặt tên và sử dụng CTE khác
Chức năng cửa sổ
Các truy vấn phân tích hiện có thể thực hiện được trong MySQL 8. Vì các hàm Window không phải là điểm mạnh của tôi, nên tôi tập trung vào nghiên cứu sâu hơn và hiểu rõ hơn về chúng, nói chung, tiến về phía trước. (Các) ví dụ tiếp theo này chủ yếu là sơ cấp theo sự hiểu biết của tôi. Độc giả hoan nghênh các đề xuất, lời khuyên và phương pháp hay nhất.
Tôi có CHẾ ĐỘ XEM này cung cấp tập kết quả dữ liệu ống hư cấu (điều gì đó tôi phần nào hiểu được):
mysql> SELECT * FROM pipe_vw;
+---------+-------------+-----------+-------+-------------+------------+----------------+
| pipe_id | pipe_name | joint_num | heat | pipe_length | has_degree | wall_thickness |
+---------+-------------+-----------+-------+-------------+------------+----------------+
| 181 | Joint-278 | 39393A | 9111 | 17.40 | 1 | 0.393 |
| 182 | Joint-8819 | 19393Y | 9011 | 16.60 | 0 | 0.427 |
| 183 | Joint-9844 | 39393V | 8171 | 10.40 | 0 | 0.393 |
| 184 | Joint-2528 | 34493U | 9100 | 11.50 | 1 | 0.427 |
| 185 | Joint-889 | 18393z | 9159 | 13.00 | 0 | 0.893 |
| 186 | Joint-98434 | 19293Q | 8174 | 9.13 | 0 | 0.893 |
| 187 | Joint-78344 | 17QTT | 179 | 44.40 | 1 | 0.893 |
| 188 | Joint-171C | 34493U | 17122 | 9.45 | 1 | 0.893 |
| 189 | Joint-68444 | 17297Q | 6114 | 11.34 | 0 | 0.893 |
| 190 | Joint-4841R | 19395Q | 5144 | 25.55 | 0 | 0.115 |
| 191 | Joint-1224C | 34493U | 8575B | 15.22 | 1 | 0.893 |
| 192 | Joint-2138 | 34493C | 91 | 13.55 | 1 | 0.893 |
| 193 | Joint-122B | 34493U | 9100B | 7.78 | 1 | 0.893 |
+---------+-------------+-----------+-------+-------------+------------+----------------+
13 rows in set (0.00 sec)Hãy tưởng tượng, tôi cần các bản ghi tài sản đường ống được trình bày theo một số loại xếp hạng hàng tùy thuộc vào độ dài của mỗi đường ống riêng lẻ. (Ví dụ:độ dài dài nhất được 'gắn nhãn' vị trí số 1, độ dài dài nhất thứ hai được 'gắn nhãn' vị trí số 2, v.v.)
Dựa trên mô tả Hàm cửa sổ RANK () trong tài liệu:
"Trả về thứ hạng của hàng hiện tại trong phân vùng của nó, với khoảng trống. Các hàng ngang hàng được coi là quan hệ và nhận cùng một thứ hạng. Hàm này không chỉ định các thứ hạng liên tiếp cho các nhóm ngang hàng nếu tồn tại các nhóm có kích thước lớn hơn một; kết quả là các số thứ hạng không liền nhau . "
Nó có vẻ rất phù hợp cho yêu cầu này.
mysql> SELECT pipe_name, pipe_length,
-> RANK() OVER(ORDER BY pipe_length DESC) AS long_to_short
-> FROM pipe_vw;
+-------------+-------------+---------------+
| pipe_name | pipe_length | long_to_short |
+-------------+-------------+---------------+
| Joint-78344 | 44.40 | 1 |
| Joint-4841R | 25.55 | 2 |
| Joint-278 | 17.40 | 3 |
| Joint-8819 | 16.60 | 4 |
| Joint-1224C | 15.22 | 5 |
| Joint-2138 | 13.55 | 6 |
| Joint-889 | 13.00 | 7 |
| Joint-2528 | 11.50 | 8 |
| Joint-68444 | 11.34 | 9 |
| Joint-9844 | 10.40 | 10 |
| Joint-171C | 9.45 | 11 |
| Joint-98434 | 9.13 | 12 |
| Joint-122B | 7.78 | 13 |
+-------------+-------------+---------------+
13 rows in set (0.01 sec)Trong tình huống tiếp theo, tôi muốn xây dựng thêm trên ví dụ trước bằng cách xếp hạng các bản ghi có độ dài từ dài nhất đến ngắn nhất, nhưng, trên mỗi nhóm riêng lẻ các giá trị wall_thickness riêng biệt.
Có lẽ truy vấn và kết quả dưới đây sẽ giải thích rõ hơn những chỗ mà bài văn xuôi của tôi có thể không có:
mysql> SELECT pipe_name, pipe_length, wall_thickness,
-> RANK() OVER(PARTITION BY wall_thickness ORDER BY pipe_length DESC) AS long_to_short
-> FROM pipe_vw;
+-------------+-------------+----------------+---------------+
| pipe_name | pipe_length | wall_thickness | long_to_short |
+-------------+-------------+----------------+---------------+
| Joint-4841R | 25.55 | 0.115 | 1 |
| Joint-278 | 17.40 | 0.393 | 1 |
| Joint-9844 | 10.40 | 0.393 | 2 |
| Joint-8819 | 16.60 | 0.427 | 1 |
| Joint-2528 | 11.50 | 0.427 | 2 |
| Joint-78344 | 44.40 | 0.893 | 1 |
| Joint-1224C | 15.22 | 0.893 | 2 |
| Joint-2138 | 13.55 | 0.893 | 3 |
| Joint-889 | 13.00 | 0.893 | 4 |
| Joint-68444 | 11.34 | 0.893 | 5 |
| Joint-171C | 9.45 | 0.893 | 6 |
| Joint-98434 | 9.13 | 0.893 | 7 |
| Joint-122B | 7.78 | 0.893 | 8 |
+-------------+-------------+----------------+---------------+
13 rows in set (0.00 sec)Truy vấn này sử dụng mệnh đề PARTITION BY trên cột wall_thickness vì chúng tôi muốn xếp hạng (ORDER BY pipe_length DESC cung cấp) tuy nhiên, chúng tôi cần nó trong ngữ cảnh của từng nhóm wall_thickness.
Mỗi xếp hạng cột long_to_short đặt lại thành 1 khi bạn gặp (hoặc thay đổi) thành một giá trị cột wall_thickness khác.
Hãy tập trung vào kết quả của một nhóm duy nhất.
Nhắm mục tiêu các bản ghi có giá trị wall_thickness 0,893, hàng có pipe_length 44,40 có 'xếp hạng' long_to_short tương ứng là 1 (hàng dài nhất), trong khi hàng có pipe_length 7,78 có 'xếp hạng' long_to_short tương ứng là 8 (ngắn nhất) tất cả trong phạm vi đó nhóm cụ thể (0,893) giá trị wall_thickness.
Các chức năng của cửa sổ khá mạnh mẽ và toàn bộ phạm vi và độ rộng của chúng không thể chỉ trong một phần. Hãy chắc chắn và truy cập Các chức năng cửa sổ được hỗ trợ trong tài liệu MySQL 8 để biết thêm thông tin về các chức năng hiện có sẵn.
Cải thiện khả năng và hỗ trợ không gian
Đây là một tập hợp lớn các tính năng có trong MySQL 8. Sự hỗ trợ của các phiên bản trước hoặc thiếu nó, đơn giản là không thể so sánh với (các) triển khai của nhà cung cấp khác (hãy nghĩ đến PostGIS cho PostgreSQL).
Trong hơn 10 năm qua, tôi đã làm việc trong lĩnh vực này với tư cách là Nhân viên khảo sát đường ống, thu thập dữ liệu GPS và tài sản, vì vậy nhóm thay đổi này chắc chắn thu hút sự chú ý của tôi.
Chuyên môn về dữ liệu không gian là một chủ đề toàn diện theo đúng nghĩa của nó và hãy yên tâm, tôi không phải là chuyên gia về nó. Tuy nhiên, tôi hy vọng sẽ tóm tắt những thay đổi đáng kể giữa phiên bản 5.7 và 8 và truyền đạt chúng một cách rõ ràng và ngắn gọn.
Hãy tự làm quen với 2 thuật ngữ (và khái niệm) chính cho mục đích của phần này.
-
Hệ thống tham chiếu không gian hoặc SRS - Đây là định nghĩa một phần từ Wikipedia:
"Hệ quy chiếu không gian (SRS) hoặc hệ quy chiếu tọa độ (CRS) là hệ thống địa phương, khu vực hoặc toàn cầu dựa trên tọa độ được sử dụng để định vị các thực thể địa lý. Hệ quy chiếu không gian xác định phép chiếu bản đồ cụ thể, cũng như các phép biến đổi giữa các tham chiếu không gian khác nhau hệ thống. "
-
Mã định danh hệ thống tham chiếu không gian hoặc SRID - Ngoài ra, Wikipedia có SRID được định nghĩa như sau:
"Số phân định hệ thống tham chiếu không gian (SRID) là một giá trị duy nhất được sử dụng để xác định rõ ràng các định nghĩa về hệ tọa độ không gian được dự báo, chưa được dự án và cục bộ. Các hệ tọa độ này là trung tâm của tất cả các ứng dụng GIS."
MySQL hỗ trợ nhiều kiểu dữ liệu không gian. Một trong những cái phổ biến hơn là ĐIỂM. Nếu bạn sử dụng GPS để điều hướng đến nhà hàng yêu thích của mình, thì vị trí đó là ĐIỂM trên bản đồ.
MySQL 5.7 xử lý khá nhiều ' đối tượng không gian 'như có SRID bằng 0, điều này rất quan trọng đối với các phép tính. Các phép tính đó được tính theo kiểu hệ tọa độ Descartes. Tuy nhiên, tất cả chúng ta đều biết rằng địa cầu của chúng ta là một hình cầu và không bằng phẳng. Do đó, trong phiên bản 8, bạn có thể coi nó là phẳng hoặc hình cầu trong tính toán.
Quay lại hai thuật ngữ đó, chúng tôi đã định nghĩa trước đây.
Mặc dù 0 là SRID mặc định trong MySQL phiên bản 8, nhiều (khoảng hơn 5.000) SRID khác được hỗ trợ.
Nhưng tại sao điều đó lại quan trọng?
Lời giải thích tuyệt vời này qua bài đăng trên blog, Hệ thống tham chiếu không gian trong MySQL 8.0, tóm gọn nó một cách độc đáo:
"Theo mặc định, nếu chúng tôi không chỉ định SRID, MySQL sẽ tạo các hình học trong SRID 0. SRID 0 là khái niệm của MySQL về một mặt phẳng Catesian trừu tượng, không đơn vị, vô hạn. Trong khi tất cả các SRS khác đều tham chiếu đến một số bề mặt và xác định các đơn vị cho trục, SRID 0 thì không. "
Về cơ bản, khi thực hiện các phép tính với SRID của ngoài SRID 0 , sau đó hình dạng của Trái đất của chúng ta phát huy tác dụng, được xem xét và ảnh hưởng đến những tính toán đó. Điều này rất quan trọng đối với bất kỳ tính toán có ý nghĩa / chính xác nào. Để có bản tóm tắt chuyên sâu và cách ngoại suy tốt hơn, hãy xem bài đăng blog này về địa lý trong MySQL 8.
Tôi cũng thực sự giới thiệu bài đăng trên blog của Nhóm Máy chủ MySQL, Hệ thống Tham chiếu Không gian Địa lý trong MySQL 8.0, để rõ ràng hơn về SRS. Hãy chắc chắn và đọc nó!
Cuối cùng, đối với các mối quan tâm về nâng cấp dữ liệu không gian từ phiên bản 5.7 lên 8, hãy truy cập một số thay đổi không tương thích được liệt kê tại đây để biết thêm thông tin.
Các quan sát đáng chú ý khác
Dưới đây là các cải tiến phát hành khác mà tôi phải thừa nhận, mặc dù chúng không được đề cập sâu trong bài đăng blog này:
- utf8mb4 hiện là bộ ký tự mặc định (trước đây là latin1) - Hỗ trợ tốt hơn cho những người phải có biểu tượng cảm xúc ngoài một số ngôn ngữ ...
- Từ điển dữ liệu giao dịch - Siêu dữ liệu MySQL hiện được đặt trong các bảng InnoDB.
- Chỉ mục ẩn - Đặt khả năng hiển thị của chỉ mục cho trình tối ưu hóa, cuối cùng xác định xem việc thêm hoặc xóa chỉ mục đó (chỉ mục) là điều tốt hay xấu. Việc thêm một chỉ mục vào một bảng lớn hiện có có thể ' tốn kém 'về khóa và tài nguyên.
- Chỉ mục giảm dần - Hiệu suất tốt hơn trên các giá trị đã lập chỉ mục được lưu trữ theo thứ tự giảm dần.
- Thêm Cột Tức thì - Đối với các thay đổi giản đồ, hãy chỉ định ALGORITHM =INSTANT trong các câu lệnh ALTER TABLE và (nếu khả thi cho hoạt động) tránh khóa siêu dữ liệu. (Để biết thêm thông tin, hãy xem bài đăng tuyệt vời này của Nhóm máy chủ MySQL và phần ALTER TABLE từ các tài liệu chính thức.)
Phần tiền thưởng:Điều gì đó tôi đã hy vọng được thấy ...
Các tài nguyên liên quan ClusterControl cho MySQL Trở thành loạt blog MySQL DBA - Các thao tác phổ biến - Thay đổi cấu trúc liên kết Nhân bản Trở thành loạt blog MySQL DBA - Nâng cấp cơ sở dữ liệuCác ràng buộc kiểm tra vẫn chưa được đưa vào sản phẩm MySQL.
Như với các phiên bản MySQL trước, cú pháp ràng buộc kiểm tra được phép trong các lệnh CREATE TABLE của bạn nhưng nó bị bỏ qua. Theo hiểu biết của tôi, hầu hết các nhà cung cấp SQL khác đều hỗ trợ các ràng buộc kiểm tra. Hãy tham gia bữa tiệc MySQL!
MySQL đã ' tăng cường đáng kể 'cung cấp của nó trong phiên bản 8. Hỗ trợ các khả năng không gian mạnh mẽ, các tùy chọn vai trò quản lý người dùng thuận tiện, các giải pháp dữ liệu SQL / NoSQL' kết hợp 'và các chức năng phân tích trong số nhiều cải tiến bổ sung, thực sự đáng chú ý.
Theo ý kiến của tôi, với phiên bản 8, MySQL tiếp tục cung cấp một lựa chọn vững chắc trong hệ sinh thái SQL nguồn mở cạnh tranh ngày càng phát triển, với đầy đủ các giải pháp có liên quan và giàu tính năng.
Cảm ơn bạn đã đọc.
