CREATE USER

CREATE USER

user accounts을 생성합니다.

Syntax:

CREATE USER [IF NOT EXISTS | OR REPLACE] name1 [, name2 [,...]] [ON CLUSTER cluster_name]
    [{VALID UNTIL datetime | VALID FOR interval}]
    [NOT IDENTIFIED | IDENTIFIED {[WITH {plaintext_password | sha256_password | sha256_hash | double_sha1_password | double_sha1_hash}] BY {'password' | 'hash'}} | WITH NO_PASSWORD | {WITH ldap SERVER 'server_name'} | {WITH kerberos [REALM 'realm']} | {WITH ssl_certificate CN 'common_name' | SAN 'TYPE:subject_alt_name'} | {WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa|...'} | {WITH http SERVER 'server_name' [SCHEME 'Basic']} [{VALID UNTIL datetime | VALID FOR interval}] [GRANTS (privilege ON object [,...])]
    [, {[{plaintext_password | sha256_password | sha256_hash | ...}] BY {'password' | 'hash'}} | {ldap SERVER 'server_name'} | {...} | ... [,...]]]
    [HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE]
    [IN access_storage_type]
    [ROLE role [,...]]
    [DEFAULT ROLE role [,...]]
    [DEFAULT DATABASE database | NONE]
    [GRANTEES {user | role | ANY | NONE} [,...] [EXCEPT {user | role} [,...]]]
    [SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY | WRITABLE] | PROFILE 'profile_name'] [,...]

ON CLUSTER 절은 클러스터에서 사용자를 생성할 수 있게 해줍니다, Distributed DDL 참고.

CREATE USER는 CREATE USER 권한이 필요합니다. OR REPLACE는 같은 이름의 기존 사용자를 덮어씁니다(그 인증 방법, 부여된 역할, 설정), 따라서 DROP USER 권한도 추가로 필요합니다. DROP USER 권한은 그 사용자가 이미 존재하는지 여부와 무관하게 문에 나열된 모든 이름에 필요하므로, 이 문으로 어떤 사용자가 존재하는지 알아낼 수 없습니다.

Identification

사용자 식별에는 여러 방법이 있습니다:

• IDENTIFIED WITH no_password
• IDENTIFIED WITH plaintext_password BY 'qwerty'
• IDENTIFIED WITH sha256_password BY 'qwerty' 또는 IDENTIFIED BY 'password'
• IDENTIFIED WITH sha256_hash BY 'hash' 또는 IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'
• IDENTIFIED WITH double_sha1_password BY 'qwerty'
• IDENTIFIED WITH double_sha1_hash BY 'hash'
• IDENTIFIED WITH bcrypt_password BY 'qwerty'
• IDENTIFIED WITH bcrypt_hash BY 'hash'
• IDENTIFIED WITH ldap SERVER 'server_name'
• IDENTIFIED WITH kerberos 또는 IDENTIFIED WITH kerberos REALM 'realm'
• IDENTIFIED WITH ssl_certificate CN 'mysite.com:user'
• IDENTIFIED WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa', KEY 'another_public_key' TYPE 'ssh-ed25519'
• IDENTIFIED WITH http SERVER 'http_server' 또는 IDENTIFIED WITH http SERVER 'http_server' SCHEME 'basic'
• IDENTIFIED BY 'qwerty'

비밀번호 복잡성 요구 사항은 config.xml에서 편집할 수 있습니다. 아래는 비밀번호가 최소 12자 이상이고 숫자 1개를 포함하도록 요구하는 예시 구성입니다. 각 비밀번호 복잡성 규칙은 비밀번호와 대조할 정규식과 규칙 설명이 필요합니다.

<clickhouse>
    <password_complexity>
        <rule>
            <pattern>.{12}</pattern>
            <message>be at least 12 characters long</message>
        </rule>
        <rule>
            <pattern>\p{N}</pattern>
            <message>contain at least 1 numeric character</message>
        </rule>
    </password_complexity>
</clickhouse>

ClickHouse Cloud에서 기본적으로 비밀번호는 다음 복잡성 요구 사항을 충족해야 합니다:

• 최소 12자 이상
• 숫자 문자 최소 1개 포함
• 대문자 최소 1개 포함
• 소문자 최소 1개 포함
• 특수 문자 최소 1개 포함

Examples

1. 다음 사용자 이름은 name1이며 비밀번호가 필요하지 않습니다. 물론 보안을 별로 제공하지 못합니다:

CREATE USER name1 NOT IDENTIFIED

2. 평문 비밀번호를 지정하려면:

CREATE USER name2 IDENTIFIED WITH plaintext_password BY 'my_password'

비밀번호는 /var/lib/clickhouse/access의 SQL 텍스트 파일에 저장되므로 plaintext_password를 사용하는 것은 좋은 생각이 아닙니다. 다음에 시연하듯이 sha256_password를 대신 시도해 보세요…

1. 가장 일반적인 옵션은 SHA-256으로 해시된 비밀번호를 사용하는 것입니다. IDENTIFIED WITH sha256_password를 지정하면 ClickHouse가 비밀번호를 해시해 줍니다. 예를 들어:

CREATE USER name3 IDENTIFIED WITH sha256_password BY 'my_password'

name3 사용자는 이제 my_password로 로그인할 수 있지만, 비밀번호는 위의 해시 값으로 저장됩니다. /var/lib/clickhouse/access에 생성되어 서버 시작 시 실행되는 다음 SQL 파일이 만들어집니다:

/var/lib/clickhouse/access $ cat 3843f510-6ebd-a52d-72ac-e021686d8a93.sql
ATTACH USER name3 IDENTIFIED WITH sha256_hash BY '0C268556C1680BEF0640AAC1E7187566704208398DA31F03D18C74F5C5BE5053' SALT '4FB16307F5E10048196966DD7E6876AE53DE6A1D1F625488482C75F14A5097C7';

사용자 이름에 대한 해시 값과 해당 salt 값을 이미 만들었다면 IDENTIFIED WITH sha256_hash BY 'hash' 또는 IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'를 사용할 수 있습니다. SALT를 사용한 sha256_hash 식별의 경우 - 해시는 'password'와 'salt'의 연결에서 계산되어야 합니다.

1. double_sha1_password는 보통 필요하지 않지만, 그것을 요구하는 클라이언트(MySQL 인터페이스처럼)와 작업할 때 유용합니다:

CREATE USER name4 IDENTIFIED WITH double_sha1_password BY 'my_password'

ClickHouse는 다음 쿼리를 생성하고 실행합니다:

CREATE USER name4 IDENTIFIED WITH double_sha1_hash BY 'CCD3A959D6A004B9C3807B728BC2E55B67E10518'

2. bcrypt_password는 비밀번호 저장에 가장 안전한 옵션입니다. 비밀번호 해시가 손상되어도 무차별 대입 공격에 강한 bcrypt 알고리즘을 사용합니다.

CREATE USER name5 IDENTIFIED WITH bcrypt_password BY 'my_password'

이 방법으로 비밀번호 길이는 72자로 제한됩니다. 해시 계산과 비밀번호 검증에 필요한 계산량과 시간을 정의하는 bcrypt work factor 매개변수는 서버 구성에서 수정할 수 있습니다:

<bcrypt_workfactor>12</bcrypt_workfactor>

work factor는 4에서 31 사이여야 하며 기본값은 12입니다.

높은 주파수의 인증을 사용하는 애플리케이션의 경우, 높은 work factor에서 bcrypt의 계산 오버헤드 때문에 대체 인증 방법을 고려하세요.

1. 비밀번호 타입은 생략할 수도 있습니다:

CREATE USER name6 IDENTIFIED BY 'my_password'

이 경우 ClickHouse는 서버 구성에 지정된 기본 비밀번호 타입을 사용합니다:

<default_password_type>sha256_password</default_password_type>

사용 가능한 비밀번호 타입은: plaintext_password, sha256_password, double_sha1_password입니다. 2. 여러 인증 방법을 지정할 수 있습니다:

CREATE USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'

Notes:

1. 더 오래된 ClickHouse 버전은 여러 인증 방법의 문법을 지원하지 않을 수 있습니다. 따라서 ClickHouse 서버에 그런 사용자가 있고 그것을 지원하지 않는 버전으로 다운그레이드되면, 그런 사용자는 사용할 수 없게 되고 일부 사용자 관련 연산이 깨집니다. 다운그레이드를 원활하게 하려면 다운그레이드 전에 모든 사용자가 단일 인증 방법만 포함하도록 설정해야 합니다. 또는 서버가 적절한 절차 없이 다운그레이드되었다면 잘못된 사용자를 삭제해야 합니다.
2. 보안상의 이유로 no_password는 다른 인증 방법과 공존할 수 없습니다. 따라서 no_password는 쿼리에서 유일한 인증 방법일 때만 지정할 수 있습니다.

User Host

User host는 ClickHouse 서버에 대한 연결이 설정될 수 있는 호스트입니다. 호스트는 HOST 쿼리 섹션에서 다음 방식으로 지정할 수 있습니다:

• HOST IP 'ip_address_or_subnetwork' — 사용자는 지정된 IP 주소 또는 subnetwork에서만 ClickHouse 서버에 연결할 수 있습니다. 예: HOST IP '192.168.0.0/16', HOST IP '2001:DB8::/32'. 프로덕션에서 사용하려면 host와 host_regexp를 사용하면 추가 지연이 발생할 수 있으므로 HOST IP 요소(IP 주소와 그 마스크)만 지정하세요.
• HOST ANY — 사용자는 어디에서나 연결할 수 있습니다. 이것이 기본 옵션입니다.
• HOST LOCAL — 사용자는 로컬로만 연결할 수 있습니다.
• HOST NAME 'fqdn' — 사용자 호스트는 FQDN으로 지정할 수 있습니다. 예: HOST NAME 'mysite.com'.
• HOST REGEXP 'regexp' — 사용자 호스트를 지정할 때 pcre 정규 표현식을 사용할 수 있습니다. 예: HOST REGEXP '.*\.mysite\.com'.
• HOST LIKE 'template' — LIKE 연산자를 사용해 사용자 호스트를 필터링할 수 있게 해줍니다. 예: HOST LIKE '%'는 HOST ANY와 동등하고, HOST LIKE '%.mysite.com'은 mysite.com 도메인의 모든 호스트를 필터링합니다.

호스트를 지정하는 또 다른 방법은 사용자 이름 뒤에 @ 문법을 사용하는 것입니다. 예:

• CREATE USER mira@'127.0.0.1' — HOST IP 문법과 동등합니다.
• CREATE USER mira@'localhost' — HOST LOCAL 문법과 동등합니다.
• CREATE USER mira@'192.168.%.%' — HOST LIKE 문법과 동등합니다.

ClickHouse는 user_name@'address'를 전체로서 하나의 사용자 이름으로 취급합니다. 따라서 기술적으로 같은 user_name과 @ 뒤의 다른 구성을 가진 여러 사용자를 만들 수 있습니다. 그러나 그렇게 하는 것을 권장하지 않습니다.

VALID UNTIL Clause

인증 방법의 만료 날짜와 선택적으로 시간을 지정할 수 있게 해줍니다. 문자열을 매개변수로 받습니다. datetime에 YYYY-MM-DD [hh:mm:ss] [timezone] 형식을 사용하는 것이 권장됩니다. 여기서 [timezone]은 +09:00 같은 숫자 오프셋이거나 UTC, GMT, Z, MSK, MSD 중 하나여야 합니다; Asia/Tokyo 같은 명명된 IANA 존은 인식되지 않습니다(아래 참고 참조). 기본적으로 이 매개변수는 'infinity'와 같습니다. 허용되는 마감 범위는 1900-01-01 00:00:00 UTC부터 9999-12-31 09:59:59 UTC까지입니다 — 모든 시간대에서 9999년 안에 머무르는 가장 최근 순간으로, 저장된 순간이 렌더링될 때 결코 잘리지 않습니다. 과거의 마감은 자격 증명이 이미 만료되었음을 의미합니다. 1970-01-01 00:00:01 UTC 이전의 마감은 "이미 만료됨" 표시로만 허용됩니다: 이는 가장 작은 만료 순간, 유닉스 epoch 후 1초(1970-01-01 00:00:01 UTC)로 정규화되므로 SHOW CREATE USER가 작성한 마감 대신 그 순간을 보고합니다. 그 순간부터의 마감은 정확히 저장됩니다.

마감은 절대 순간으로 저장되지만, SHOW CREATE USER와 system.users는 서버 또는 세션 시간대에 렌더링하므로, 같은 저장 순간이 다르게 구성된 서버에서 다른 벽시계 텍스트로 나타납니다: 위의 정규화된 만료 순간은 예를 들어 UTC 서버에서 1970-01-01 00:00:01로, Pacific/Kiritimati 서버에서 1970-01-01 14:00:01로 렌더링됩니다. 강제는 항상 저장된 순간을 사용하며, 그 렌더링을 사용하지 않습니다.

절의 배치가 적용되는 인증 방법을 결정합니다:

• IDENTIFIED 절 앞(또는 쿼리가 아무 인증 방법도 지정하지 않을 때): 마감은 사용자의 모든 인증 방법에 적용되는 사용자 수준 마감입니다.
• 인증 방법 뒤: 마감은 그 방법에만 적용됩니다. 따라서 전체 IDENTIFIED 목록 뒤에 작성된 절은 마지막 방법에만 바인딩되어, 앞선 방법은 만료되지 않게 둡니다.

Examples:

• CREATE USER name1 VALID UNTIL '2025-01-01'
• CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 UTC'
• CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 +09:00'
• CREATE USER name1 VALID UNTIL 'infinity'
• CREATE USER name1 VALID UNTIL '2025-01-01' IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2' — 사용자 수준 마감이 두 방법 모두에 적용됩니다.
• CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01' — 마감은 bcrypt_password 방법에만 적용됩니다; plaintext_password는 결코 만료되지 않습니다.

datetime 문자열은 parseDateTimeBestEffort로 파싱되며, 이는 시간대 토큰 UTC, GMT, Z, MSK, MSD와 +09:00 또는 -05:00 같은 숫자 오프셋만 인식합니다. Asia/Tokyo나 Europe/London 같은 명명된 IANA 시간대는 지원되지 않으며, 고정 오프셋은 일광 절약 시간을 준수하는 지역의 IANA 존과 동등하지 않으므로, 인코딩하는 특정 날짜에 대한 올바른 오프셋을 계산해야 합니다.

VALID FOR Clause

VALID FOR 절은 VALID UNTIL의 편의 축약입니다. 절대 날짜와 시간 대신 interval을 받고, 만료 마감은 쿼리가 실행되는 순간의 현재 시간 더하기 그 간격으로 계산됩니다. 결과는 VALID UNTIL 형식으로 저장되므로 SHOW CREATE USER는 항상 해결된 절대 마감을 표시합니다. VALID UNTIL을 사용할 수 있는 모든 곳에서 사용할 수 있고, 같은 배치 규칙을 따릅니다: IDENTIFIED 앞(또는 인증 방법 없이)이면 모든 방법에 적용되는 사용자 수준 마감이고, 인증 방법 뒤이면 그 방법에만 적용됩니다. 마감은 초 정밀도로 저장되고 강제되므로, 초 미만 간격(NANOSECOND, MICROSECOND, MILLISECOND)은 거부됩니다; 허용되는 가장 작은 단위는 SECOND입니다. 음수 간격은 자격 증명을 이미 만료된 것으로 표시하는 방법으로 허용됩니다; 결과 마감이 1970-01-01 00:00:01 UTC 이전이면 그 가장 작은 만료 순간으로 정규화되며, 이는 SHOW CREATE USER가 그때 보고하는 값입니다 — 서버 또는 세션 시간대에 렌더링되며, VALID UNTIL에 대해 설명한 대로입니다.

Examples:

• CREATE USER name1 VALID FOR INTERVAL 1 DAY
• CREATE USER name1 VALID FOR INTERVAL 3 MONTH
• CREATE USER name1 VALID FOR INTERVAL 1 DAY + INTERVAL 12 HOUR
• CREATE USER name1 VALID FOR INTERVAL 30 DAY IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2' — 사용자 수준 마감이 두 방법 모두에 적용됩니다.
• CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID FOR INTERVAL 30 DAY — 마감은 bcrypt_password 방법에만 적용됩니다; plaintext_password는 결코 만료되지 않습니다.

GRANTS Clause

특정 인증 방법으로 인증된 세션에서 사용할 수 있는 접근 권한을 제한할 수 있게 해줍니다. GRANT 문과 같은 형태의 권한 목록을 괄호 안에 받습니다. 이 절은 인증 방법 뒤(있으면 그 VALID UNTIL 절 뒤)에 지정되며 그 방법에만 적용됩니다.

사용자가 그러한 인증 방법으로 로그인하면, 세션의 접근 권한은 사용자의 접근 권한(부여된 역할의 권한 포함)과 절에 나열된 권한의 교집합입니다. 이 절은 접근 권한을 추가하지 않습니다: 나열된 권한이 사용자에게 부여되지 않으면 세션은 그것을 가지지 않습니다. 그러한 방법으로 인증된 세션은 권한을 부여할 수도 없고(GRANT OPTION은 교집합에서 결코 살아남지 못함) 역할을 관리할 수도 없습니다. 역할 관리는 역할 생성, 변경, 삭제, 부여, 회수뿐만 아니라 사용자에 대해 기본으로 활성화되는 역할 변경(SET DEFAULT ROLE 및 ALTER USER ... DEFAULT ROLE)도 포함하며, 이것도 거부됩니다.

EXECUTE AS는 세션의 주체를 전환하므로, 모방(impersonation) 하에 실행되는 문은 대상 사용자의 접근 권한과 나열된 권한의 교집합에 의해 제한되며, 로그인한 사용자의 권한에 의해서는 제한되지 않습니다. 제한 자체는 결코 벗겨지지 않으며, 모방에는 IMPERSONATE ON target이 사용자에게 부여되어 있고 절에 나열되어 있어야 하므로, 제한된 자격 증명은 같은 사용자의 무제한 자격 증명보다 결코 더 멀리 도달할 수 없습니다.

이는 애플리케이션용 토큰을 만드는 편리한 방법을 제공합니다: 만료 날짜와 제한된 권한 집합이 있는 추가 자격 증명으로, 사용자에 묶입니다 — system.query_log와 system.processes에서 사용자로 표시되고, 사용자가 삭제되면 작동을 멈추며, 사용자가 권한을 잃으면 접근 권한도 잃습니다.

강제는 initiator 전용입니다. 인증 방법 GRANTS 제한과 그 VALID UNTIL 만료는 쿼리를 받는 노드(initiator)에서만 강제됩니다. 클러스터의 다른 노드로는 전파되지 않으므로, 클러스터 전체에 제한을 가하기 위해 이 절에 의존하지 마세요. 원격 노드는 평소 역할 스코핑을 유지합니다. 이 절은 users.xml에서도 사용할 수 없습니다. query result cache는 사용자의 모든 인증 방법이 공유합니다: 항목을 사용자와 역할별로 격리하며, 캐시 히트는 세션이 로그인한 방법의 GRANTS에 대해 다시 확인되지 않습니다.

Examples:

• CREATE USER name1 IDENTIFIED BY 'qwerty' GRANTS (SELECT ON db.*)
• ALTER USER name1 ADD IDENTIFIED WITH plaintext_password BY 'app_token' VALID UNTIL '2026-12-31' GRANTS (SELECT ON db.table, INSERT ON db.table)

제한은 인증 방법의 속성이며 로그인 순간에 포착됨을 주의하세요: ALTER USER로 절을 변경하면 이미 설정된 세션이 아니라 새 세션에 영향을 줍니다.

READ ON S3('s3://bucket/.*') 같은 필터링된 소스 grant는 아직 절에서 지원되지 않습니다: 교집합은 소스 필터를 불투명 문자열로 비교하며 한 필터를 다른 필터로 좁힐 수 없으므로, 그러한 grant는 조용히 아무 접근도 부여하지 않는 대신 거부됩니다.

이 절은 자격 증명이 서버에서 순수하게 로컬로 검증되는 인증 방법에 대해서만 지원됩니다. 검증이 외부 시스템(ldap, kerberos, http, jwt)에 접촉하는(또는 jwt의 경우 서명 키를 가져오기 위해 접촉할 수 있는) 방법에 대해서는 절이 거부됩니다: 여러 인증 방법이 같은 자격 증명을 받아들일 때, 제한은 자격 증명을 다른 방법에 대해 다시 확인함으로써 강제되며, 외부 시스템에 대한 추가 프로브는 안전하지 않으므로, 같은 자격 증명을 받아들이는 다른 방법이 제한을 우회할 수 있습니다.

같은 유효 자격 증명이 둘 이상의 인증 방법으로 받아들여질 때, 로그인은 그것들 모두에 의해 fail-close로 제한됩니다: 세션은 모든 일치하는 방법의 GRANTS의 교집합을 얻고 가장 이른 VALID UNTIL에 만료됩니다. 가장 이른 VALID UNTIL은 이미 지났더라도 이깁니다 — 로그인은 거부되며, 단일 일치 방법이 만료된 것과 정확히 같습니다. 따라서 토큰의 만료는 결코 공유 자격 증명에 더 넓은 방법의 권리나 수명을 조용히 넘겨주지 않습니다.

이 조합은 위에서 외부 검증 방법에 대해 절 자체가 거부되는 것과 같은 이유로, 서버에서 로컬로 검증되는 인증 방법 사이에서만 확인됩니다: 거기서 자격 증명을 다시 확인하려면 외부 시스템에 대한 안전하지 않은 추가 프로브가 필요하기 때문입니다. 따라서 같은 자격 증명이 우연히 같은 사용자의 외부 검증 방법(ldap, kerberos, http, jwt)에 의해 받아들여져도, 그 방법 자체의 VALID UNTIL은 그 조합의 일부가 아니며, 그것에 구성된 이른 만료가 로컬 검증 방법을 통해 얻은 세션을 줄이지 않습니다.

GRANTEES Clause

이 사용자가 GRANT OPTION으로 필요한 모든 접근을 부여받았다는 조건하에, 이 사용자로부터 privileges을 받을 수 있는 사용자 또는 역할을 지정합니다. GRANTEES 절의 옵션:

• user — 이 사용자가 권한을 부여할 수 있는 사용자를 지정합니다.
• role — 이 사용자가 권한을 부여할 수 있는 역할을 지정합니다.
• ANY — 이 사용자는 누구에게나 권한을 부여할 수 있습니다. 기본 설정입니다.
• NONE — 이 사용자는 누구에게도 권한을 부여할 수 없습니다.

EXCEPT 표현식으로 어떤 사용자나 역할을 제외할 수 있습니다. 예: CREATE USER user1 GRANTEES ANY EXCEPT user2. 이는 user1이 GRANT OPTION으로 부여받은 권한이 있으면 user2를 제외한 누구에게나 그 권한을 부여할 수 있음을 의미합니다.

Examples

비밀번호 qwerty로 보호된 mira 사용자 계정 생성:

CREATE USER mira HOST IP '127.0.0.1' IDENTIFIED WITH sha256_password BY 'qwerty';

mira는 ClickHouse 서버가 실행되는 호스트에서 클라이언트 앱을 시작해야 합니다.

john 사용자 계정 생성 및 역할 할당:

CREATE USER john ROLE role1, role2;

john 사용자 계정 생성, 역할 할당 및 일부를 기본으로 지정:

CREATE USER john ROLE role1, role2 DEFAULT ROLE role1;

또는

CREATE USER john ROLE role1, role2 DEFAULT ROLE ALL EXCEPT role2;

john 사용자 계정 생성 및 jack 계정을 가진 사용자에게 자신의 권한을 부여할 수 있도록 허용:

CREATE USER john GRANTEES jack;

기본 데이터베이스가 있는 john 사용자 계정 생성:

CREATE USER john DEFAULT DATABASE database1

DEFAULT DATABASE NONE은 기본 데이터베이스를 설정하지 않은 채 둡니다. NONE이라는 이름의 데이터베이스를 사용하려면 이름을 백틱으로 인용하세요:

DEFAULT DATABASE `NONE`

쿼리 매개변수로 john 사용자 계정 생성:

SET param_user=john;
CREATE USER {user:Identifier};

더 알아보기 (Learn more)

• GRANT
• Access rights and account management