Loading...
MySQL 9.5 Reference Manual 9.5의 8.2.3 Grant Tables의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
mysql system database에는 사용자 계정과 그들이 보유한 권한에 대한 정보를 포함하는 여러 grant table이 있습니다. 이 절에서는 이러한 table에 대해 설명합니다. system database의 다른 table에 대한 정보는 Section 7.3, “The mysql System Schema”를 참조하십시오.
여기서의 설명은 grant table의 기본 구조와, 서버가 client와 상호 작용할 때 그 내용물을 어떻게 사용하는지에 대해 설명합니다. 그러나 일반적으로는 grant table을 직접 수정하지 않습니다. CREATE USER, GRANT, REVOKE와 같은 계정 관리 구문을 사용하여 계정을 설정하고 각 계정에 사용 가능한 권한을 제어할 때, 수정이 간접적으로 발생합니다. Section 15.7.1, “Account Management Statements”를 참조하십시오. 이러한 구문을 사용하여 계정 조작을 수행하면, 서버는 사용자를 대신하여 grant table을 수정합니다.
참고
INSERT,
UPDATE,
DELETE와 같은 구문을 사용하여 grant table을 직접 수정하는 것은 권장되지 않으며, 사용자의 책임하에 수행됩니다. 이러한 수정의 결과로 row가 잘못된 형식이 되면, 서버는 그 row를 무시할 수 있습니다.
grant table을 수정하는 어떠한 작업에 대해서도, 서버는 table이 기대하는 구조를 가지고 있는지 확인하고 그렇지 않으면 오류를 발생시킵니다. table을 기대하는 구조로 업데이트하려면, MySQL 업그레이드 절차를 수행하십시오. Chapter 3, Upgrading MySQL을 참조하십시오.
다음 mysql database table에는 grant 정보가 포함됩니다:
user:
User 계정, 정적 글로벌 권한, 기타 비권한 컬럼.
global_grants:
동적 글로벌 권한.
db:
데이터베이스 수준 권한.
tables_priv:
테이블 수준 권한.
columns_priv:
컬럼 수준 권한.
procs_priv:
저장 프로시저 및 함수 권한.
proxies_priv:
프록시 사용자 권한.
default_roles:
기본 사용자 역할.
role_edges:
역할 서브그래프에 대한 엣지.
password_history:
비밀번호 변경 이력.
정적 글로벌 권한과 동적 글로벌 권한의 차이에 대한 정보는 Static Versus Dynamic Privileges를 참조하십시오.)
grant table은 InnoDB 스토리지 엔진을 사용하며 트랜잭션을 지원합니다. 각 구문은 명시된 모든 사용자에 대해 성공하거나, 오류가 발생하면 롤백되어 아무런 영향도 주지 않습니다.
각 grant table에는 범위 컬럼과 권한 컬럼이 포함됩니다:
범위 컬럼은 table의 각 row의 범위, 즉 row가 적용되는 컨텍스트를 결정합니다. 예를 들어, Host 및 User 값이 'h1.example.net' 및 'bob'인 user table row는, client가 사용자 이름으로 bob을 지정하여 host h1.example.net에서 서버로 수행하는 연결을 인증할 때 적용됩니다. 마찬가지로, Host, User, Db 컬럼 값이 'h1.example.net', 'bob', 'reports'인 db table row는, bob이 host h1.example.net에서 reports database에 접근하기 위해 연결할 때 적용됩니다. tables_priv 및 columns_priv table에는 각 row가 적용되는 table 또는 table/컬럼 조합을 나타내는 범위 컬럼이 포함됩니다. procs_priv 범위 컬럼은 각 row가 적용되는 저장 루틴을 나타냅니다.
권한 컬럼은 table row가 부여하는 권한, 즉 수행이 허용되는 작업을 나타냅니다. 서버는 다양한 grant table에 있는 정보를 결합하여 한 사용자의 권한에 대한 완전한 설명을 형성합니다. Section 8.2.7, “Access Control, Stage 2: Request Verification”에서 이에 대한 규칙을 설명합니다.
또한, grant table에는 범위나 권한 평가 이외의 목적으로 사용되는 컬럼이 포함될 수 있습니다.
서버는 grant table을 다음과 같은 방식으로 사용합니다:
user table 범위 컬럼은 들어오는 연결을 거부하거나 허용할지를 결정합니다. 허용된 연결에 대해서는, user table에서 부여된 권한이 사용자의 정적 글로벌 권한을 나타냅니다. 이 table에서 부여된 권한은 서버의 모든 database에 적용됩니다.주의
어떠한 정적 글로벌 권한이라도 모든 database에 대한 권한으로 간주되므로, 정적 글로벌 권한을 가진 사용자는, database 수준에서 부분 취소로 제한된 database를 제외하고, SHOW DATABASES 또는 INFORMATION_SCHEMA의 SCHEMATA table을 검사함으로써 모든 database 이름을 볼 수 있습니다.
global_grants table에는 사용자 계정에 대한 동적 글로벌 권한의 현재 할당이 나열됩니다. 각 row에 대해 범위 컬럼은 권한 컬럼에 명시된 권한을 보유한 사용자를 결정합니다.
db table 범위 컬럼은 어떤 사용자가 어떤 host에서 어떤 database에 접근할 수 있는지를 결정합니다. 권한 컬럼은 허용되는 작업을 결정합니다. 데이터베이스 수준에서 부여된 권한은 데이터베이스와, table 및 저장 프로그램과 같이 데이터베이스 내의 모든 객체에 적용됩니다.
tables_priv 및 columns_priv table은 db table과 유사하지만 더 세분화되어 있습니다. 데이터베이스 수준이 아니라 테이블 및 컬럼 수준에 적용됩니다. 테이블 수준에서 부여된 권한은 그 테이블과 그 테이블의 모든 컬럼에 적용됩니다. 컬럼 수준에서 부여된 권한은 특정 컬럼에만 적용됩니다.
procs_priv table은 저장 루틴(저장 프로시저 및 함수)에 적용됩니다. 루틴 수준에서 부여된 권한은 단일 프로시저 또는 함수에만 적용됩니다.
proxies_priv table은 어떤 사용자가 다른 사용자의 프록시로서 동작할 수 있는지, 그리고 사용자가 다른 사용자에게 PROXY 권한을 부여할 수 있는지를 나타냅니다.
default_roles 및 role_edges table에는 역할 관계에 대한 정보가 포함됩니다.
password_history table은 기존에 선택된 비밀번호를 보존하여 비밀번호 재사용에 대한 제한을 가능하게 합니다. Section 8.2.15, “Password Management”를 참조하십시오.
서버는 시작 시 grant table의 내용을 메모리로 읽어들입니다. FLUSH PRIVILEGES 구문을 실행하거나 mysqladmin flush-privileges 또는 mysqladmin reload 명령을 실행하여 table을 다시 로드하도록 서버에 지시할 수 있습니다. grant table에 대한 변경 사항이 언제 적용되는지에 대해서는 Section 8.2.13, “When Privilege Changes Take Effect”를 참조하십시오.
계정을 수정할 때, 변경 사항이 의도한 효과를 가지는지 확인하는 것이 좋습니다. 주어진 계정의 권한을 확인하려면 SHOW GRANTS 구문을 사용하십시오. 예를 들어, 사용자 이름과 host 이름 값이 bob 및 pc84.example.com인 계정에 부여된 권한을 확인하려면 다음과 같이 합니다:
1SHOW GRANTS FOR 'bob'@'pc84.example.com';
계정의 비권한 속성을 표시하려면 SHOW CREATE USER를 사용하십시오:
1SHOW CREATE USER 'bob'@'pc84.example.com';
서버는 접근 제어의 1단계와 2단계 모두에서 mysql database의 user 및 db table을 사용합니다(Section 8.2, “Access Control and Account Management” 참조). user 및 db table의 컬럼은 다음과 같습니다.
Table 8.4 user and db Table Columns
| Table Name | user | db |
|---|---|---|
| Scope columns | Host | Host |
User | Db | |
User | ||
| Privilege columns | Select_priv | Select_priv |
Insert_priv | Insert_priv | |
Update_priv | Update_priv | |
Delete_priv | Delete_priv | |
Index_priv | Index_priv | |
Alter_priv | Alter_priv | |
Create_priv | Create_priv | |
Drop_priv | Drop_priv | |
Grant_priv | Grant_priv | |
Create_view_priv | Create_view_priv | |
Show_view_priv | Show_view_priv | |
Create_routine_priv | Create_routine_priv | |
Alter_routine_priv | Alter_routine_priv | |
Execute_priv | Execute_priv | |
Trigger_priv | Trigger_priv | |
Event_priv | Event_priv | |
Create_tmp_table_priv | Create_tmp_table_priv | |
Lock_tables_priv | Lock_tables_priv | |
References_priv | References_priv | |
Reload_priv | ||
Shutdown_priv | ||
Process_priv | ||
File_priv | ||
Show_db_priv | ||
Super_priv | ||
Repl_slave_priv | ||
Repl_client_priv | ||
Create_user_priv | ||
Create_tablespace_priv | ||
Create_role_priv | ||
Drop_role_priv | ||
| Security columns | ssl_type | |
ssl_cipher | ||
x509_issuer | ||
x509_subject | ||
plugin | ||
authentication_string | ||
password_expired | ||
password_last_changed | ||
password_lifetime | ||
account_locked | ||
Password_reuse_history | ||
Password_reuse_time | ||
Password_require_current | ||
User_attributes | ||
| Resource control columns | max_questions | |
max_updates | ||
max_connections | ||
max_user_connections |
| Table Name | user | db |
|---|
user table의 plugin 및 authentication_string 컬럼에는 인증 플러그인 및 자격 증명 정보가 저장됩니다.
서버는 계정 row의 plugin 컬럼에 명시된 플러그인을 사용하여 해당 계정에 대한 연결 시도를 인증합니다.
plugin 컬럼은 비어 있지 않아야 합니다. 시작 시와, FLUSH PRIVILEGES가 실행될 때 런타임에서, 서버는 user table row를 검사합니다. plugin 컬럼이 비어 있는 row에 대해 서버는 다음 형식의 경고를 오류 로그에 기록합니다:
1[Warning] User entry 'user_name'@'host_name' has an empty plugin 2value. The user will be ignored and no one can login with this user 3anymore.
플러그인이 없는 계정에 플러그인을 할당하려면 ALTER USER 구문을 사용하십시오.
password_expired 컬럼을 사용하면 DBA가 계정 비밀번호를 만료시키고 사용자가 비밀번호를 재설정하도록 요구할 수 있습니다. 기본 password_expired 값은 'N'이지만, ALTER USER 구문을 사용하여 'Y'로 설정할 수 있습니다. 계정의 비밀번호가 만료된 후, 해당 계정이 서버에 이후 연결에서 수행하는 모든 작업은 사용자가 새로운 계정 비밀번호를 설정하기 위해 ALTER USER 구문을 실행할 때까지 오류를 발생시킵니다.
참고
만료된 비밀번호를 현재 값으로 설정하여 “재설정”하는 것은 가능하지만, 정책상으로는 다른 비밀번호를 선택하는 것이 바람직합니다. DBA는 적절한 비밀번호 재사용 정책을 설정하여 재사용을 방지할 수 있습니다. Password Reuse Policy를 참조하십시오.
password_last_changed는 비밀번호가 마지막으로 변경된 시점을 나타내는 TIMESTAMP 컬럼입니다. 이 값은 MySQL 내장 인증 플러그인(sha256_password 또는 caching_sha2_password)을 사용하는 계정에 대해서만 NULL이 아닙니다. 외부 인증 시스템을 사용하는 계정과 같이 다른 계정의 경우에는 값이 NULL입니다.
password_last_changed는 CREATE USER,
ALTER USER,
SET PASSWORD 구문과, 계정을 생성하거나 계정 비밀번호를 변경하는 GRANT 구문에 의해 업데이트됩니다.
password_lifetime은 계정 비밀번호 수명을 일 단위로 나타냅니다. 비밀번호가 수명을 초과한 경우(password_last_changed 컬럼을 사용하여 평가), 서버는 client가 해당 계정을 사용하여 연결할 때 비밀번호가 만료된 것으로 간주합니다. 0보다 큰 N 값은 비밀번호를 매 _N_일마다 변경해야 함을 의미합니다. 값이 0이면 자동 비밀번호 만료가 비활성화됩니다. 값이 NULL인 경우(기본값), default_password_lifetime 시스템 변수를 통해 정의된 글로벌 만료 정책이 적용됩니다.
account_locked는 계정이 잠금 상태인지 여부를 나타냅니다(Section 8.2.20, “Account Locking” 참조).
Password_reuse_history는 계정에 대한 PASSWORD HISTORY 옵션의 값 또는 기본 이력인 경우 NULL입니다.
Password_reuse_time은 계정에 대한 PASSWORD REUSE INTERVAL 옵션의 값 또는 기본 간격인 경우 NULL입니다.
Password_require_current는 계정에 대한 PASSWORD REQUIRE 옵션의 값에 해당하며, 다음 table에 나타나 있습니다.
Table 8.5 Permitted Password_require_current Values
| Password_require_current Value | Corresponding PASSWORD REQUIRE Option |
|---|---|
'Y' | PASSWORD REQUIRE CURRENT |
'N' | PASSWORD REQUIRE CURRENT OPTIONAL |
NULL | PASSWORD REQUIRE CURRENT DEFAULT |
User_attributes는 다른 컬럼에 저장되지 않는 계정 속성을 저장하는 JSON 형식 컬럼입니다. INFORMATION_SCHEMA는 USER_ATTRIBUTES table을 통해 이러한 속성을 노출합니다.
User_attributes 컬럼에는 다음과 같은 속성이 포함될 수 있습니다:
additional_password: 보조 비밀번호(있는 경우). Dual Password Support를 참조하십시오.
Restrictions: 제한 목록(있는 경우). 제한은 부분 취소 작업에 의해 추가됩니다. 속성 값은 각 요소가 제한된 database 이름과 해당 database에 적용되는 제한을 나타내는 Database 및 Restrictions 키를 갖는 요소의 배열입니다(Section 8.2.12, “Privilege Restriction Using Partial Revokes” 참조).
Password_locking: 로그인 실패 추적 및 임시 계정 잠금에 대한 조건(있는 경우)(Failed-Login Tracking and Temporary Account Locking 참조). Password_locking 속성은 CREATE USER 및 ALTER USER 구문의 FAILED_LOGIN_ATTEMPTS 및 PASSWORD_LOCK_TIME 옵션에 따라 업데이트됩니다. 속성 값은 계정에 대해 지정된 옵션 값들을 나타내는 failed_login_attempts 및 password_lock_time_days 키를 가진 해시입니다. 키가 없으면 해당 값은 암묵적으로 0입니다. 키 값이 암묵적 또는 명시적으로 0이면, 대응되는 기능은 비활성화됩니다.
multi_factor_authentication: mysql.user 시스템 table의 row에는 인증 플러그인을 나타내는 plugin 컬럼이 있습니다. 단일 요소 인증의 경우, 해당 플러그인이 유일한 인증 요소입니다. 2요소 또는 3요소 형태의 다중 요소 인증의 경우, 해당 플러그인은 첫 번째 인증 요소에 대응되지만 두 번째 및 세 번째 요소에 대한 추가 정보가 저장되어야 합니다. multi_factor_authentication 속성은 이 정보를 보유합니다.
multi_factor_authentication 값은 배열이며, 각 배열 요소는 다음 속성을 사용하여 인증 요소를 설명하는 해시입니다:
plugin: 인증 플러그인의 이름.
authentication_string: 인증 문자열 값.
passwordless: 사용자가 비밀번호 없이(보안 토큰만을 인증 방식으로 사용하여) 사용되도록 의도되었는지를 나타내는 플래그.
requires_registration: 사용자 계정이 보안 토큰을 등록했는지를 정의하는 플래그.
첫 번째 및 두 번째 배열 요소는 다중 요소 인증 요소 2 및 3을 설명합니다.
적용 가능한 속성이 없으면, User_attributes는 NULL입니다.
예: 보조 비밀번호를 가지고 있고 database 권한이 부분적으로 취소된 계정은 컬럼 값에 additional_password 및 Restrictions 속성을 가집니다:
1mysql> SELECT User_attributes FROM mysql.User WHERE User = 'u'\G 2*************************** 1. row *************************** 3User_attributes: {"Restrictions": 4 [{"Database": "mysql", "Privileges": ["SELECT"]}], 5 "additional_password": "hashed_credentials"}
어떤 속성이 존재하는지 확인하려면 JSON_KEYS() 함수를 사용하십시오:
1SELECT User, Host, JSON_KEYS(User_attributes) 2FROM mysql.user WHERE User_attributes IS NOT NULL;
Restrictions와 같은 특정 속성을 추출하려면 다음과 같이 합니다:
1SELECT User, Host, User_attributes->>'$.Restrictions' 2FROM mysql.user WHERE User_attributes->>'$.Restrictions' <> '';
다음은 multi_factor_authentication에 대해 저장되는 정보 유형의 예입니다:
1{ 2 "multi_factor_authentication": [ 3 { 4 "plugin": "authentication_ldap_simple", 5 "passwordless": 0, 6 "authentication_string": "ldap auth string", 7 "requires_registration": 0 8 }, 9 { 10 "plugin": "authentication_webauthn", 11 "passwordless": 0, 12 "authentication_string": "", 13 "requires_registration": 1 14 } 15 ] 16}
접근 제어의 두 번째 단계 동안, 서버는 각 client가 발행하는 각 요청에 대해 충분한 권한을 가지고 있는지 확인하기 위해 요청 검증을 수행합니다. user 및 db grant table 외에도, 서버는 table이 관련된 요청에 대해 tables_priv 및 columns_priv table을 참조할 수 있습니다. 후자의 table은 table 및 컬럼 수준에서 더 세밀한 권한 제어를 제공합니다. 이들 table에는 다음 table에 나타난 컬럼이 있습니다.
Table 8.6 tables_priv and columns_priv Table Columns
| Table Name | tables_priv | columns_priv |
|---|---|---|
| Scope columns | Host | Host |
Db | Db | |
User | User | |
Table_name | Table_name | |
Column_name | ||
| Privilege columns | Table_priv | Column_priv |
Column_priv | ||
| Other columns | Timestamp | Timestamp |
Grantor |
Timestamp 및 Grantor 컬럼은 각각 현재 타임스탬프와 CURRENT_USER 값으로 설정되지만, 그 외에는 사용되지 않습니다.
저장 루틴이 관련된 요청을 검증하기 위해, 서버는 procs_priv table을 참조할 수 있으며, 이 table에는 다음 table에 나타난 컬럼이 있습니다.
Table 8.7 procs_priv Table Columns
| Table Name | procs_priv |
|---|---|
| Scope columns | Host |
Db | |
User | |
Routine_name | |
Routine_type | |
| Privilege columns | Proc_priv |
| Other columns | Timestamp |
Grantor |
Routine_type 컬럼은 row가 참조하는 루틴 유형을 나타내기 위해 값이 'FUNCTION' 또는 'PROCEDURE'인 ENUM 컬럼입니다. 이 컬럼을 통해 동일한 이름을 가진 함수와 프로시저에 대해 권한을 별도로 부여할 수 있습니다.
Timestamp 및 Grantor 컬럼은 사용되지 않습니다.
proxies_priv table은 프록시 계정에 대한 정보를 기록합니다. 이 table에는 다음과 같은 컬럼이 있습니다:
Host, User: 프록시 계정; 즉, 프록시 대상 계정에 대해 PROXY 권한을 가진 계정입니다.
Proxied_host,
Proxied_user: 프록시 대상 계정.
Grantor, Timestamp:
사용되지 않습니다.
With_grant: 프록시 계정이 다른 계정에 PROXY 권한을 부여할 수 있는지 여부입니다.
계정이 다른 계정에 PROXY 권한을 부여할 수 있으려면, proxies_priv table에 With_grant가 1로 설정되어 있고, 권한을 부여할 수 있는 계정을 나타내도록 Proxied_host 및 Proxied_user가 설정된 row가 있어야 합니다. 예를 들어, MySQL 설치 중에 생성된 'root'@'localhost' 계정에는 proxies_priv table에 ''@'', 즉 모든 사용자와 모든 host에 대해 PROXY 권한을 부여할 수 있도록 하는 row가 있습니다. 이를 통해 root는 프록시 사용자를 설정할 수 있을 뿐 아니라, 다른 계정에 프록시 사용자를 설정할 수 있는 권한을 위임할 수 있습니다. Section 8.2.19, “Proxy Users”를 참조하십시오.
global_grants table에는 사용자 계정에 대한 동적 글로벌 권한의 현재 할당이 나열되어 있습니다. 이 table에는 다음과 같은 컬럼이 있습니다:
USER, HOST: 권한이 부여된 계정의 사용자 이름 및 host 이름.
PRIV: 권한 이름.
WITH_GRANT_OPTION: 계정이 권한을 다른 계정에 부여할 수 있는지 여부입니다.
default_roles table에는 기본 사용자 역할이 나열됩니다. 이 table에는 다음과 같은 컬럼이 있습니다:
HOST, USER: 기본 역할이 적용되는 계정 또는 역할.
DEFAULT_ROLE_HOST,
DEFAULT_ROLE_USER: 기본 역할.
role_edges table에는 역할 서브그래프에 대한 엣지가 나열됩니다. 이 table에는 다음과 같은 컬럼이 있습니다:
FROM_HOST, FROM_USER:
역할이 부여된 계정.
TO_HOST, TO_USER: 계정에 부여된 역할.
WITH_ADMIN_OPTION: 계정이 WITH ADMIN OPTION을 사용하여 역할을 다른 계정에 부여하고 다른 계정으로부터 취소할 수 있는지 여부입니다.
password_history table에는 비밀번호 변경에 대한 정보가 포함됩니다. 이 table에는 다음과 같은 컬럼이 있습니다:
Host, User: 비밀번호 변경이 발생한 계정.
Password_timestamp: 비밀번호 변경이 발생한 시각.
Password: 새 비밀번호 해시 값.
password_history table은 계정 비밀번호 이력 길이와 재사용 간격 모두에 대해 검사를 수행할 수 있도록, 계정별로 충분한 수의 비어 있지 않은 비밀번호를 누적합니다. 비밀번호 변경 시도가 발생할 때, 두 한계 밖에 있는 엔트리는 자동으로 정리됩니다.
참고
빈 비밀번호는 비밀번호 이력에 포함되지 않으며, 언제든지 재사용할 수 있습니다.
계정 이름이 변경되면, 그 엔트리도 일치하도록 이름이 변경됩니다. 계정이 삭제되거나 인증 플러그인이 변경되면, 그 엔트리는 제거됩니다.
grant table의 범위 컬럼에는 문자열이 포함됩니다. 각 컬럼의 기본값은 빈 문자열입니다. 다음 table은 각 컬럼에 허용되는 문자 수를 보여줍니다.
Table 8.8 Grant Table Scope Column Lengths
| Column Name | Maximum Permitted Characters |
|---|---|
Host, Proxied_host | 255 |
User, Proxied_user | 32 |
Db | 64 |
Table_name | 64 |
Column_name | 64 |
Routine_name | 64 |
Host 및 Proxied_host 값은 grant table에 저장되기 전에 소문자로 변환됩니다.
접근 검사 목적을 위해, User, Proxied_user, authentication_string, Db, Table_name 값의 비교는 대소문자를 구분합니다. Host, Proxied_host, Column_name, Routine_name 값의 비교는 대소문자를 구분하지 않습니다.
user 및 db table은 각 권한을 ENUM('N','Y') DEFAULT 'N'으로 선언된 개별 컬럼에 나열합니다. 다시 말해, 각 권한은 비활성 또는 활성 상태가 될 수 있으며, 기본값은 비활성입니다.
tables_priv,
columns_priv,
procs_priv table은 권한 컬럼을 SET 컬럼으로 선언합니다. 이들 컬럼의 값에는 해당 table이 제어하는 권한의 임의 조합이 포함될 수 있습니다. 컬럼 값에 나열된 권한만 활성화됩니다.
Table 8.9 Set-Type Privilege Column Values
| Table Name | Column Name | Possible Set Elements |
|---|---|---|
tables_priv | Table_priv | 'Select', 'Insert', 'Update', 'Delete', 'Create', 'Drop',<br> 'Grant', 'References', 'Index', 'Alter', 'Create View',<br> 'Show view', 'Trigger' |
tables_priv | Column_priv | 'Select', 'Insert', 'Update', 'References' |
columns_priv | Column_priv | 'Select', 'Insert', 'Update', 'References' |
procs_priv | Proc_priv | 'Execute', 'Alter Routine', 'Grant' |
관리 권한(예: RELOAD,
SHUTDOWN,
SYSTEM_VARIABLES_ADMIN)은 user 및 global_grants table에만 지정됩니다. 관리 작업은 서버 자체에 대한 작업이며 데이터베이스별이 아니므로, 이러한 권한을 다른 grant table에 나열할 이유가 없습니다. 따라서, 사용자가 관리 작업을 수행할 수 있는지 확인하기 위해 서버는 user 및 global_grants table만 참조하면 됩니다.
FILE 권한 또한 user table에만 지정됩니다. 이 권한은 자체적으로 관리 권한은 아니지만, 서버 host에서 파일을 읽거나 쓸 수 있는 사용자의 능력은 접근 중인 database와는 무관합니다.
MySQL grant table에 대한 동시 DML 및 DDL 작업을 허용하기 위해, 이전에 MySQL grant table에서 row 잠금을 획득하던 읽기 작업은 잠금 없는 읽기로 실행됩니다. MySQL grant table에서 잠금 없는 읽기로 수행되는 작업에는 다음이 포함됩니다:
grant table에서 조인 목록 및 서브쿼리를 통해 데이터를 읽는 SELECT 구문 및 기타 읽기 전용 구문(모든 트랜잭션 격리 수준에서), SELECT ... FOR SHARE 구문을 포함합니다.
grant table에서 데이터를 읽지만(조인 목록 또는 서브쿼리 통해) grant table을 수정하지 않는 DML 작업(모든 트랜잭션 격리 수준에서).
grant table에서 데이터를 읽을 때 더 이상 row 잠금을 획득하지 않는 구문은 구문 기반 복제를 사용하는 동안 실행되면 경고를 보고합니다.
binlog_format=mixed를 사용할 때, grant table에서 데이터를 읽는 DML 작업은 믹스드 모드 복제에 대해 작업을 안전하게 만들기 위해 binary log에 row 이벤트로 기록됩니다.
grant table에서 데이터를 읽는 SELECT ... FOR SHARE 구문은 경고를 보고합니다. FOR SHARE 절에서는, grant table에 대해 읽기 잠금이 지원되지 않습니다.
grant table에서 데이터를 읽고 SERIALIZABLE 격리 수준을 사용하여 실행되는 DML 작업은 경고를 보고합니다. SERIALIZABLE 격리 수준을 사용할 때 일반적으로 획득되는 읽기 잠금은 grant table에서 지원되지 않습니다.
8.2.2 Privileges Provided by MySQL
8.2.4 Specifying Account Names