Thay đổi mật khẩu người dùng MySQL: Lệnh ALTER USER (MySQL 5.7 / 8.0) + Khôi phục Root

1. [Quick Answer] Danh sách lệnh thay đổi mật khẩu người dùng MySQL (Giải pháp nhanh nhất)

Lệnh cơ bản để thay đổi mật khẩu của người dùng trong MySQL là ALTER USER.
Phương pháp này được khuyến nghị trong MySQL 5.7 trở lên, và được sử dụng tương tự trong MySQL 8.0.

1.1 Cú pháp cơ bản (được sử dụng phổ biến nhất)

ALTER USER 'username'@'localhost' IDENTIFIED BY 'newpassword';

• username : tên người dùng mục tiêu cần cập nhật
• localhost : máy khách (một tài khoản MySQL được xác định bằng “tên người dùng + máy chủ”)
• newpassword : mật khẩu mới

Sau khi thực thi, thay đổi có hiệu lực ngay lập tức. Trong hầu hết các trường hợp, không cần FLUSH PRIVILEGES; (ALTER USER tự động cập nhật các bảng đặc quyền).

Những sai lầm thường gặp

• Ngay cả với cùng một tên người dùng, @'localhost' và @'%' được coi là các tài khoản khác nhau
• Các ký tự đặc biệt trong mật khẩu phải được bao quanh bằng dấu nháy đơn

1.2 Thay đổi người dùng truy cập từ xa (%)

ALTER USER 'username'@'%' IDENTIFIED BY 'newpassword';

% có nghĩa là “bất kỳ máy chủ nào”.
Nó thường được sử dụng trong môi trường đám mây hoặc cho những người dùng được phép kết nối từ bên ngoài.

Ghi chú

• An toàn hơn khi kiểm tra trước bằng câu lệnh SELECT User, Host FROM mysql.user;
• Nếu bạn thay đổi mật khẩu cho Host sai, bạn sẽ không thể đăng nhập được

1.3 Thay đổi mật khẩu đồng thời chỉ định plugin xác thực (quan trọng trong 8.0)

Trong MySQL 8.0, plugin xác thực mặc định là caching_sha2_password.
Nếu bạn không thể kết nối với các client cũ, hãy chỉ định rõ plugin.

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'newpassword';

• mysql_native_password : phương pháp cũ (ưu tiên tính tương thích)
• caching_sha2_password : tiêu chuẩn MySQL 8.0 (được khuyến nghị)

Những lỗi thường gặp

• Các phiên bản PHP hoặc client cũ có thể không hỗ trợ plugin mặc định của MySQL 8.0
• Kết luận “Tôi không thể đăng nhập” mà không kiểm tra plugin xác thực

1.4 Nếu bạn gặp lỗi quyền hạn

Ví dụ lỗi:

ERROR 1227 (42000): Access denied; you need (at least one of) the SYSTEM_USER privilege(s)

Trong trường hợp này, người dùng hiện đang đăng nhập không có quyền thực hiện thay đổi.

Kiểm tra:

SHOW GRANTS FOR CURRENT_USER();

Chạy lệnh với quyền root hoặc với một người dùng có đủ đặc quyền.

1.5 Cách xác minh sau khi thay đổi

SELECT User, Host, plugin FROM mysql.user WHERE User='username';

• Kiểm tra plugin xác thực qua cột plugin
• Kiểm tra đáng tin cậy nhất là thực sự đăng nhập và xác nhận kết nối

1.6 Điều gì xảy ra với các phiên hiện có

Sau khi thay đổi mật khẩu:

• Các kết nối mới phải sử dụng mật khẩu mới
• Các phiên hiện có có thể bị ngắt ngay tùy thuộc vào môi trường
• Trong môi trường production, nên thực hiện thay đổi ngoài giờ làm việc

2. Cơ bản về Người dùng và Máy chủ MySQL (Ngăn ngừa các vấn đề “bị kẹt” thường gặp)

Trong MySQL, một người dùng không chỉ được xác định bằng “tên người dùng”. Thay vào đó, nó được xác định bằng sự kết hợp của “tên người dùng + máy khách (Host)”.
Nếu bạn không hiểu điều này, bạn có thể gặp vấn đề cổ điển: “Tôi đã thay đổi mật khẩu nhưng vẫn không thể đăng nhập.”

2.1 Người dùng là cặp “user@host”

Ví dụ:

• 'appuser'@'localhost'
• 'appuser'@'%'
• 'appuser'@'192.168.1.%'

Đây là tất cả các tài khoản khác nhau.
Vì vậy ngay cả khi bạn thay đổi mật khẩu cho localhost, nó không ảnh hưởng đến tài khoản %.

Lệnh kiểm tra:

SELECT User, Host FROM mysql.user ORDER BY User, Host;

Những sai lầm thường gặp

• Không nhận ra có nhiều tài khoản cùng tên người dùng
• Bạn đã thay đổi mật khẩu cho localhost, nhưng thực tế bạn đang đăng nhập qua TCP (127.0.0.1)

2.2 localhost và 127.0.0.1 được xử lý khác nhau

Trong MySQL:

• localhost → kết nối socket UNIX (kết nối nội bộ cục bộ)
• 127.0.0.1 → kết nối TCP/IP

Tùy thuộc vào môi trường, một tài khoản khác có thể khớp.

Kiểm tra:

mysql -u username -p -h 127.0.0.1

Nếu bạn không thể đăng nhập với các thông tin trên, tài khoản @'127.0.0.1' có thể không tồn tại.

2.3 Kiểm tra người dùng hiện đang xác thực

Điều quan trọng là hiểu “tài khoản nào bạn đang được xác thực”.

SELECT CURRENT_USER();

Điều này hiển thị “user@host” thực tế đã được xác thực.

SELECT USER(); hiển thị thông tin yêu cầu kết nối, vì vậy có thể không khớp.

2.4 Kiểm tra quyền (SHOW GRANTS)

Nếu bạn không thể thay đổi mật khẩu, có thể do thiếu quyền.

SHOW GRANTS FOR 'username'@'host';

Hoặc cho người dùng hiện đang đăng nhập:

SHOW GRANTS FOR CURRENT_USER();

Quyền tối thiểu cần thiết

• ALTER USER
• Hoặc SYSTEM_USER (MySQL 8.0 trở lên)

2.5 Các mẫu lỗi thường gặp

1. Bạn đã thay đổi mật khẩu cho Host sai
2. Plugin xác thực khác nhau (rất phổ biến trong 8.0)
3. Tài khoản mục tiêu không tồn tại ngay từ đầu

Kiểm tra xem người dùng có tồn tại không:

SELECT User, Host FROM mysql.user WHERE User='username';

Khi bạn hiểu mô hình này, bạn có thể tránh hầu hết các vấn đề liên quan đến việc thay đổi mật khẩu.

3. Quy trình đề xuất: Thay đổi an toàn với ALTER USER (Áp dụng cho MySQL 8.0 / 5.7)

Trong MySQL 5.7 trở lên, việc thay đổi mật khẩu bằng ALTER USER là cách chuẩn và được khuyến nghị.
Các cập nhật trực tiếp như UPDATE mysql.user có thể hoạt động khác nhau tùy phiên bản và mang rủi ro không tương thích trong tương lai, vì vậy tốt nhất là tránh chúng.

3.1 Kiểm tra trước (Luôn xác nhận trước khi thay đổi)

Trước khi thay đổi mật khẩu, hãy xác nhận ba mục sau.

① Xác nhận người dùng và Host mục tiêu

SELECT User, Host FROM mysql.user WHERE User='username';

• Kiểm tra xem có nhiều tài khoản cùng tên người dùng hay không
• Đừng nhầm lẫn localhost với %

② Xác nhận plugin xác thực hiện tại (quan trọng trong 8.0)

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

• caching_sha2_password (tiêu chuẩn MySQL 8.0)
• mysql_native_password (plugin cũ)

Một số lỗi kết nối được gây ra bởi plugin xác thực.

③ Xác nhận người dùng hiện đang được xác thực

SELECT CURRENT_USER();

Để tránh lỗi quyền, hãy chạy các lệnh với tư cách root hoặc người dùng có quyền thích hợp.

3.2 Thực hiện ALTER USER (dạng chuẩn)

ALTER USER 'username'@'localhost'
IDENTIFIED BY 'NewStrongPassword123!';

Thay đổi có hiệu lực ngay lập tức.
Trong hầu hết các trường hợp, không cần FLUSH PRIVILEGES;.

Ghi chú

• Nếu vi phạm chính sách mật khẩu (validate_password), có thể xảy ra ERROR 1819
• Nếu mật khẩu chứa ký tự đặc biệt, luôn bao quanh nó bằng dấu nháy đơn

3.3 Thay đổi đồng thời chỉ định plugin xác thực (chỉ khi cần thiết)

Nếu bạn đang sử dụng các client cũ trong môi trường MySQL 8.0:

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'NewStrongPassword123!';

Các trường hợp bạn nên thay đổi:

• Không thể kết nối với PHP / MySQL client cũ
• Môi trường không hỗ trợ caching_sha2_password

Các trường hợp bạn không nên thay đổi:

• Nếu bạn đã có thể kết nối mà không gặp vấn đề trong môi trường hiện đại (plugin chuẩn an toàn hơn)

3.4 Kiểm tra sau khi thay đổi

① Xác minh plugin xác thực

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

② Xác minh bằng cách thực tế đăng nhập

mysql -u username -p

Luôn kiểm tra rằng bạn có thể đăng nhập.

3.5 Ảnh hưởng tới các phiên hiện có

Sau khi thay đổi mật khẩu:

• Kết nối mới → phải sử dụng mật khẩu mới
• Kết nối hiện có → có thể vẫn hoạt động tùy môi trường
• Production → có thể cần khởi động lại kết nối ứng dụng

Những lỗi thường gặp

• Không cập nhật thông tin đăng nhập của ứng dụng
• Mật khẩu cũ vẫn còn trong các tệp cấu hình

3.6 Mẹo vận hành an toàn cho môi trường production

• Thực hiện các thay đổi ngoài giờ làm việc
• Kiểm tra các tệp cấu hình ứng dụng trước
• Thực hiện công việc mà không ngắt kết nối phiên SSH của bạn
• Khi thay đổi root, đảm bảo bạn đã có phương pháp khôi phục sẵn

4. Sự khác nhau giữa MySQL 8.0 và 5.7

Nguyên nhân lớn nhất gây rắc rối khi thay đổi mật khẩu MySQL là sự khác biệt về phương thức xác thực giữa MySQL 8.0 và 5.7.
Cụ thể, nhiều trường hợp “Tôi đã thay đổi nhưng không thể đăng nhập” là do sự khác nhau trong plugin xác thực.

Sự khác biệt xác thực giữa MySQL 5.7 và MySQL 8.0

4.1 Sự khác biệt plugin xác thực mặc định

Trong MySQL 8.0, caching_sha2_password đã trở thành tiêu chuẩn để tăng cường bảo mật.
Tuy nhiên, các client cũ (phiên bản PHP cũ, các connector MySQL cũ, v.v.) có thể không hỗ trợ nó.

Cách kiểm tra:

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

Các vấn đề thường gặp

• Các client cũ không thể kết nối tới người dùng được tạo trên MySQL 8.0
• Ngay cả khi có lỗi, bạn cũng không nhận ra nguyên nhân gốc là plugin xác thực

4.2 Cách chuyển đổi plugin xác thực để tương thích

Chỉ khi bạn phải kết nối từ môi trường cũ, hãy thay đổi như sau:

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'NewStrongPassword123!';

Sau khi thay đổi, luôn thực hiện kiểm tra kết nối.

Lưu ý

• Về mặt bảo mật, caching_sha2_password an toàn hơn
• Không chuyển sang plugin legacy một cách không cần thiết
• Nếu có thể, việc cập nhật phía client là ưu tiên

4.3 Không khuyến khích sử dụng UPDATE trực tiếp

Trong MySQL 5.7 và các phiên bản trước, các phương pháp như sau đã được sử dụng:

UPDATE mysql.user
SET authentication_string=PASSWORD('newpassword')
WHERE User='username';
FLUSH PRIVILEGES;

Tuy nhiên, cách tiếp cận này là:

• Phụ thuộc mạnh vào phiên bản
• Có thể bị thay đổi theo đặc tả trong 8.0
• Có khả năng bị loại bỏ trong tương lai

Nguyên tắc chung: sử dụng ALTER USER

4.4 Sự khác biệt hành vi của plugin validate_password

Trong MySQL 5.7 và 8.0, tính năng chính sách mật khẩu (kiểm tra độ mạnh) được bật mặc định.

Kiểm tra:

SHOW VARIABLES LIKE 'validate_password%';

Nếu bạn vi phạm chính sách, bạn có thể nhận được:

ERROR 1819 (HY000)

.

Vì nhiều môi trường 8.0 áp dụng các tiêu chuẩn bảo mật nghiêm ngặt hơn,
sau khi nâng cấp từ 5.7, bạn có thể nhận thấy việc thay đổi mật khẩu không còn thành công do yêu cầu chính sách mạnh hơn.

4.5 Cách kiểm tra phiên bản của bạn

Nếu bạn không chắc phiên bản nào đang chạy:

SELECT VERSION();

Nếu bạn áp dụng các sửa chữa mà không xác nhận phiên bản, bạn có thể kết thúc bằng cách sử dụng phương pháp sai.

5. Khôi phục mật khẩu root bị quên (Quy trình tập trung bảo mật)

Nếu bạn quên mật khẩu của người dùng root MySQL (quản trị viên), bạn không thể đăng nhập bình thường.
Trong trường hợp này, bạn phải tạm thời vô hiệu hoá các bảng grant và đặt lại mật khẩu. Tuy nhiên, quy trình này có rủi ro bảo mật, vì vậy hãy thực hiện các bước một cách cẩn thận.

5.1 Xác nhận liệu bạn có thực sự cần mật khẩu root hay không

Đầu tiên, kiểm tra các mục sau:

• Bạn có quyền sudo ở mức hệ điều hành hay không
• Xác thực auth_socket có được bật không (thường trên các hệ thống dựa trên Ubuntu)

Ví dụ kiểm tra:

SELECT User, Host, plugin
FROM mysql.user
WHERE User='root';

Nếu plugin là auth_socket, bạn có thể đăng nhập dưới quyền root của hệ điều hành.

sudo mysql

Nếu cách này hoạt động, bạn chỉ cần đặt lại mật khẩu.

5.2 Quy trình khôi phục (thủ tục chung)

① Dừng máy chủ MySQL

sudo systemctl stop mysql

② Khởi động với các bảng grant bị vô hiệu hoá

sudo mysqld_safe --skip-grant-tables &

--skip-grant-tables vô hiệu hoá xác thực.
Trong trạng thái này, bất kỳ ai cũng có thể kết nối, vì vậy hãy hoàn thành quy trình nhanh chóng.

③ Kết nối tới MySQL

mysql -u root

Bạn có thể kết nối mà không cần mật khẩu.

④ Đặt lại mật khẩu root (phương pháp được khuyến nghị)

ALTER USER 'root'@'localhost'
IDENTIFIED BY 'NewStrongPassword123!';

Quan trọng

• Không được sử dụng trực tiếp UPDATE mysql.user
• Sử dụng ALTER USER (để tương thích phiên bản)

⑤ Kích hoạt lại các bảng grant

FLUSH PRIVILEGES;

⑥ Khởi động lại MySQL ở chế độ bình thường

sudo systemctl restart mysql

Sau đó xác minh đăng nhập bình thường:

mysql -u root -p

5.3 Những lỗi thường gặp

• Để --skip-grant-tables bật (rủi ro bảo mật nghiêm trọng)
• Nhầm lẫn thay đổi Host của root
• Thay đổi plugin xác thực không đúng và khóa tài khoản của mình

5.4 Lưu ý cho môi trường sản xuất

• Luôn thực hiện việc này trong thời gian bảo trì trên các máy chủ công cộng
• Giữ phiên SSH hoạt động trong khi làm việc
• Tạo bản sao lưu trước nếu có thể

Việc khôi phục mật khẩu root có thể thực hiện an toàn nếu thực hiện cẩn thận.

6. Các lỗi thường gặp và giải pháp (Ghi lại lưu lượng theo thông báo lỗi)

Một số lỗi thường gặp xảy ra khi thay đổi mật khẩu MySQL.
Dưới đây, chúng tôi sắp xếp các nguyên nhân và giải pháp phổ biến theo các mã lỗi thường được tìm kiếm.

6.1 LỖI 1819 (Mật khẩu không đáp ứng yêu cầu chính sách)

Ví dụ lỗi:

ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

Nguyên nhân

Mật khẩu không vượt qua kiểm tra độ mạnh do plugin validate_password áp dụng.

Kiểm tra chính sách hiện tại

SHOW VARIABLES LIKE 'validate_password%';

Các cài đặt quan trọng:

• validate_password.length
• validate_password.policy
• validate_password.mixed_case_count
• validate_password.number_count
• validate_password.special_char_count

Giải pháp ① (Đề xuất): Sử dụng mật khẩu mạnh hơn

• Ít nhất 12 ký tự
• Bao gồm chữ hoa, chữ thường, số và ký tự đặc biệt
• Tránh các từ trong từ điển

Giải pháp ② (Tạm thời nới lỏng chính sách)

SET GLOBAL validate_password.policy = LOW;

Sau khi hoàn thành nhiệm vụ, nên khôi phục lại cài đặt ban đầu.

Những lỗi thường gặp

• Để chính sách nới lỏng trong môi trường sản xuất
• Bỏ qua việc thay đổi cài đặt này yêu cầu quyền SUPER

6.2 LỖI 1227 (Thiếu quyền)

Ví dụ lỗi:

ERROR 1227 (42000): Access denied; you need (at least one of) the SYSTEM_USER privilege(s)

Nguyên nhân

Người dùng hiện tại thiếu quyền ALTER USER hoặc SYSTEM_USER.

Kiểm tra quyền

SHOW GRANTS FOR CURRENT_USER();

Giải pháp

Chạy lệnh với quyền root hoặc người dùng có đủ quyền.

Nếu cần:

GRANT ALTER USER ON *.* TO 'username'@'host';
FLUSH PRIVILEGES;

Lưu ý

• Trong MySQL 8.0, quyền SYSTEM_USER cũng có thể cần thiết
• Tuân thủ nguyên tắc quyền tối thiểu trong môi trường sản xuất

6.3 Không thể đăng nhập sau khi thay đổi mật khẩu

Nguyên nhân chính

1. Host sai
2. Plugin xác thực không khớp
3. Không tương thích client
4. Cấu hình ứng dụng chưa được cập nhật

① Kiểm tra Host

SELECT User, Host FROM mysql.user WHERE User='username';

② Kiểm tra plugin xác thực

SELECT plugin FROM mysql.user WHERE User='username';

③ Thay đổi plugin xác thực (nếu cần)

ALTER USER 'username'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'NewStrongPassword123!';

④ Kiểm tra cấu hình ứng dụng

• .env
• config.php
• Chuỗi kết nối (DSN)

Những lỗi thường gặp

• Thay đổi MySQL nhưng không cập nhật ứng dụng
• Không khởi động lại container trong môi trường Docker

6.4 Vẫn có thể đăng nhập bằng mật khẩu cũ sau khi thay đổi

Thông thường, các thay đổi bằng ALTER USER có hiệu lực ngay lập tức.

Nguyên nhân có thể:

• Bạn thực tế đã thay đổi tài khoản Host khác
• Kết nối đang trỏ tới máy chủ khác (replica)
• Bộ nhớ đệm phiên

Kiểm tra:

SELECT CURRENT_USER();

Việc xác nhận chính xác cả máy chủ kết nối và người dùng đã xác thực là rất quan trọng.

7. Hoạt động bảo mật: Chính sách mật khẩu và các thực tiễn tốt nhất

Thay đổi mật khẩu không phải là một nhiệm vụ một lần duy nhất.
Trong các hoạt động thực tế, bạn duy trì bảo mật bằng cách kết hợp việc thực thi độ mạnh, thiết kế quyền hạn và các quy tắc vận hành.

7.1 Sử dụng plugin validate_password

MySQL cung cấp chức năng tích hợp để thực thi độ mạnh của mật khẩu.

Kiểm tra cài đặt hiện tại

SHOW VARIABLES LIKE 'validate_password%';

Các tham số cấu hình chính

• validate_password.length (độ dài tối thiểu)
• validate_password.policy (LOW / MEDIUM / STRONG)
• validate_password.mixed_case_count
• validate_password.number_count
• validate_password.special_char_count

Cấu hình ví dụ (tối thiểu 12 ký tự, chính sách MEDIUM)

SET GLOBAL validate_password.length = 12;
SET GLOBAL validate_password.policy = MEDIUM;

Lưu ý

• Các thay đổi GLOBAL có thể bị đặt lại sau khi khởi động lại
• Để duy trì các cài đặt, cấu hình chúng trong tệp cấu hình ( my.cnf / my.ini )

7.2 Yêu cầu tối thiểu cho mật khẩu mạnh

Tiêu chuẩn được khuyến nghị trong thực tế:

• Ít nhất 12 ký tự
• Bao gồm chữ hoa, chữ thường, số và ký tự đặc biệt
• Tránh các từ trong từ điển
• Không tái sử dụng trên các dịch vụ khác

Ví dụ:

X9v!pQ4z#Lm2

Các ví dụ cần tránh

password123
mysql2025
companyname!

7.3 Quan trọng hơn việc thay đổi định kỳ

Quan trọng hơn “thay đổi mỗi sáu tháng” là thiết kế dựa trên giả định rò rỉ thông tin đăng nhập tiềm năng.

① Tách người dùng ứng dụng

• Không sử dụng root trong các ứng dụng
• Tạo người dùng có quyền tối thiểu

Ví dụ:

GRANT SELECT, INSERT, UPDATE ON dbname.* TO 'appuser'@'localhost';

② Giảm thiểu quyền (Nguyên tắc quyền tối thiểu)

Chỉ cho phép các thao tác cần thiết để hạn chế thiệt hại tiềm năng.

③ Sử dụng kiểm toán và nhật ký

Ví dụ kiểm tra nhật ký:

tail -f /var/log/mysql/mysql.log

MySQL Enterprise cũng hỗ trợ các plugin kiểm toán.

7.4 Mẹo vận hành cho môi trường sản xuất

• Kiểm tra trong môi trường staging trước khi thực hiện thay đổi trên production
• Theo dõi lịch sử thay đổi (Git hoặc tài liệu)
• Luôn chạy kiểm tra kết nối sau khi thay đổi
• Giữ phiên SSH của bạn hoạt động trong khi làm việc

7.5 Những việc bạn không bao giờ được làm

• Sử dụng tài khoản root trong các ứng dụng
• Mã cứng mật khẩu trong mã nguồn
• Vô hiệu hoá validate_password và để như vậy
• Để máy chủ chạy với --skip-grant-tables

Quản lý mật khẩu không phải là một nhiệm vụ một lần mà là một phần của thiết kế vận hành liên tục.

8. FAQ (Các câu hỏi thường gặp)

8.1 Q. Điều gì xảy ra với các phiên hoạt động sau khi thay đổi mật khẩu?

A. Về nguyên tắc, các kết nối mới yêu cầu mật khẩu mới.
Đối với các phiên hiện có, chúng có thể bị ngắt ngay lập tức hoặc vẫn hoạt động tùy thuộc vào môi trường và cấu hình.

Trong thực tế:

• Thực hiện thay đổi ngoài giờ làm việc trong môi trường production
• Khởi động lại ứng dụng để làm mới các kết nối

được khuyến nghị.

8.2 Q. Tôi đã thay đổi mật khẩu nhưng vẫn không thể đăng nhập

Ba nguyên nhân phổ biến nhất là:

1. Host sai ( localhost so với % , v.v.)
2. Không khớp plugin xác thực (rất phổ biến trong 8.0)
3. Cấu hình ứng dụng chưa được cập nhật

Kiểm tra với:

SELECT User, Host, plugin
FROM mysql.user
WHERE User='username';

Chú ý đặc biệt đến cột plugin.

8.3 Q. Tôi có thể cho phép chỉ một người dùng cụ thể thay đổi mật khẩu không?

Có.

GRANT ALTER USER ON *.* TO 'username'@'host';
FLUSH PRIVILEGES;

Trong MySQL 8.0, quyền SYSTEM_USER cũng có thể được yêu cầu.

SHOW GRANTS FOR 'username'@'host';

Sử dụng điều này để xác minh quyền.

8.4 Q. Phương pháp có giống trong MariaDB không?

Cơ bản, ALTER USER có sẵn, nhưng:

• Plugin xác thực
• Hành vi chính sách mật khẩu
• Sự khác biệt theo phiên bản

có thể khác nhau tùy thuộc vào môi trường.

Kiểm tra với:

SELECT VERSION();

MySQL Community Edition không cung cấp tính năng theo dõi lịch sử mật khẩu tích hợp theo mặc định.

8.5 Q. Tôi có thể kiểm tra lịch sử thay đổi mật khẩu không?

Các cách tiếp cận khả thi:

• Bật ghi nhật ký kiểm toán
• Sử dụng quản lý nhật ký bên ngoài
• Theo dõi lịch sử trong tài liệu vận hành

Ví dụ:

tail -f /var/log/mysql/mysql.log

8.6 Q. Tôi có thể khôi phục người dùng không phải root bằng –skip-grant-tables không?

Có, nhưng nó tạo ra một trạng thái cực kỳ nguy hiểm.
Luôn quay lại chế độ bình thường ngay sau khi hoàn thành quy trình.

9. Tóm tắt

Thay đổi mật khẩu MySQL có thể trông đơn giản, nhưng nếu không hiểu mô hình user@host, các plugin xác thực và thiết kế quyền, nó dễ dẫn đến các vấn đề.

Các điểm chính trong bài viết này là:

9.1 Sử dụng ALTER USER làm phương pháp chuẩn

ALTER USER 'username'@'localhost'
IDENTIFIED BY 'NewStrongPassword123!';

• Phương pháp chuẩn trong MySQL 5.7 trở lên
• Không khuyến nghị thực hiện UPDATE mysql.user trực tiếp
• Thông thường không cần FLUSH PRIVILEGES

9.2 Người dùng được quản lý dưới dạng “user@host”

• localhost và % là các tài khoản khác nhau
• Có thể tồn tại nhiều tài khoản cùng tên người dùng
• Kiểm tra bằng câu lệnh SELECT User, Host FROM mysql.user;

9.3 Chú ý đến các plugin xác thực trong 8.0

• Mặc định 8.0: caching_sha2_password
• Tương thích legacy: mysql_native_password
• Nếu không thể kết nối, kiểm tra cột plugin

  SELECT plugin FROM mysql.user WHERE User='username';
  

9.4 Cẩn thận khi khôi phục mật khẩu root

• --skip-grant-tables chỉ là biện pháp tạm thời
• Luôn quay lại chế độ bình thường sau khi hoàn thành
• Thực hiện trong thời gian bảo trì trong môi trường production

9.5 Hầu hết các lỗi đều có nguyên nhân rõ ràng

• ERROR 1819 → Vi phạm chính sách mật khẩu
• ERROR 1227 → Quyền không đủ
• Không thể đăng nhập → Không khớp host hoặc plugin xác thực không khớp

9.6 Trong thực tế, nguyên tắc tối thiểu quyền và thiết kế vận hành là quan trọng nhất

• Không sử dụng root trong các ứng dụng
• Tạo người dùng chuyên dụng
• Thực thi chính sách mật khẩu mạnh
• Luôn kiểm tra kết nối sau khi thay đổi

Quản lý mật khẩu MySQL không chỉ là thay đổi một giá trị—đó là nền tảng của các hoạt động cơ sở dữ liệu an toàn.
Chọn phương pháp phù hợp cho môi trường của bạn và thực hiện một cách cẩn thận.