clickhouse user.xml

config.xml文件可以使用用戶設置，配置文件和配額指定單獨的配置。 此配置的相對路徑在users_config元素中設置。 默認情況下，它是users.xml。 如果省略users_config，則直接在config.xml中指定用戶設置，配置文件和配額。

可以將用戶配置分爲與config.xml和config.d /類似的單獨文件。
目錄名稱定義爲users.config設置，不帶.xml後綴與.d串聯。
默認情況下使用目錄users.d，因爲users_config默認爲users.xml。

注意一點，修改了user.xml的參數之後是即時生效的，如有問題可以查看其錯誤日誌。

users.xml有三大塊進行說明，分別爲：profiles，quotas，users

profile

profile的作用類似於用戶角色，可以在user.xml中定義多組profile，並可以爲每組profile定義不同的配置項，類限制資源的使用。多個profile的配置可以複用。

模板：

<profiles> --配置profile
        <default>  -- 自定義profile
            <max_memory_usage>10000000000</max_memory_usage>
            <use_uncompressed_cache>0</use_uncompressed_cache>
            <load_balancing>random</load_balancing>
        </default>
        <readonly>  -- 自定義profile
            <readonly>1</readonly>
　　　　　　　<max_memory_usage>100000000</max_memory_usage>
        </readonly>
    </profiles>

說明：

<default>：自定義profile，可以在它下面設置相關參數，如：最大內存使用、只讀等等。更多的配置參數後續會介紹，也而已看官網文檔，可以設置多個profile。
該示例指定了兩個profile：default和readonly。 默認<default>有一個特殊用途：必須始終存在並且在啓動服務器時應用。profile文件可以相互繼承，只需要在配置文件中列出即可，如定義一個test的profile：

        <test>
            <profile>readonly</profile>
            <max_memory_usage>10000</max_memory_usage>
        </test> 

test的profile繼承了readonly的profile，包含了其所有的配置，並且使用新參數來覆蓋其原有的配置。設置了之後如何使用呢？有二種方法，第1是直接在終端命令行裏進行設置，第2個是在users.xml中的users選項組裏進行指定（後面會說明）。

[root@dba clickhouse-server]# clickhouse-client
ClickHouse client version 20.3.5.21 (official build).
Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 20.3.5 revision 54433.

dba :) set profile = 'test'

SET profile = 'test'

Ok.
rows in set. Elapsed: 0.002 sec. 

dba :) set max_memory_usage = 123123

SET max_memory_usage = 123123

Received exception from server (version 20.3.5):
Code: 164. DB::Exception: Received from localhost:9000. DB::Exception: Cannot modify 'max_memory_usage' setting in readonly mode. 
rows in set. Elapsed: 0.005 sec. 

dba :) Bye.

測試說明已經把readonly的profile的參數（readonly）繼承過來了。 

profile中的設定項-查詢權限設置

ClickHouse中的查詢可以分爲幾種類型：

• 讀取數據查詢：SELECT，SHOW，DESCRIBE，EXISTS。
• 寫入數據查詢：INSERT，OPTIMIZE。
• 更改設置查詢：SET，USE。
• DDL查詢：CREATE，ALTER，RENAME，ATTACH，DETACH，DROP TRUNCATE。
• KILL QUERY。
• 其中KILL QUERY查詢可以在任何設置下生效。

<readonly>

只讀限制，設置讀取數據，寫入數據和更改設置查詢的權限（並不設置ddl查詢權限）。

可能的值：

• 0-允許所有查詢。
• 1-僅允許讀取數據查詢。
• 2-允許讀取數據和更改設置查詢。

  	讀取數據	寫入數據	更改設置
  0	YES	YES	YES
  1	YES	NO	NO
  2	YES	NO	YES

  默認值：0

  <allow_ddl>

DDL限制，設置是否可以進行DDL操作

可能的值：

• 0-不允許DDL查詢。
• 1-允許DDL查詢。

默認值：1

profile中的設定項-查詢複雜度的設置

對查詢複雜度的限制是設置的一部分。它們用於從用戶界面提供更安全的執行。
幾乎所有限制僅適用於SELECT。對於分佈式查詢處理，限制分別應用於每個服務器（就是說對於最大內存這種設置來說是對每臺服務器單獨算的，不是對集羣整體設置最大內存）。

ClickHouse會檢查對於整體數據部分的限制條件，而不是對每一行進行限制。這意味着您可以超出數據部分大小的限制值。（It means that you can exceed the value of restriction with the size of the data part.）

對“什麼東西的最大數量”的限制可以取值爲0，表示“不受限制”。

大多數限制還具有“ overflow_mode”設置，表示超出限制時該怎麼做，通常有以下兩個值：

• throw –拋出異常（默認）。
• break –停止執行查詢並返回部分結果。

對於聚合限制（group_by_overflow_mode），還有另一個值any，表示繼續聚合進入集合的key值，但不要向集合中添加新key值。

<max_memory_usage>

用於在單個服務器上運行查詢的最大RAM量，在默認配置文件中，最大爲10 GB（10000000000byte，大約9.3個g）。

該設置不考慮可用內存量或計算機上的總內存量，適用於單個服務器內的單個查詢。

可以使用 SHOW PROCESSLIST 來查看每個查詢的當前內存消耗。此外，每個查詢的峯值內存消耗也會被跟蹤並寫入日誌。但是不監視某些聚合功能狀態的內存使用情況。

Memory usage is not fully tracked for states of the aggregate functions min, max, any, anyLast, argMin, argMax from String and Array arguments.

內存消耗也受參數max_memory_usage_for_user和max_server_memory_usage限制。

<max_memory_usage_for_user>

用於在單個服務器上運行用戶查詢的最大RAM量。

默認值在Settings.h中定義。默認情況下max_memory_usage_for_user = 0，不受限制。

<max_rows_to_read>

在每個塊（而不是每一行）上檢查以下限制。也就是說，限制可以打破一點。

運行查詢時可以從表中讀取的最大行數。

<max_rows_to_read_leaf>

在每個塊（而不是每一行）上檢查以下限制。也就是說，限制可以打破一點。

運行分佈式查詢時，可以從葉子節點上的本地表讀取的最大行數。僅在葉節點上的讀取階段檢查此限制，而在根節點上的結果合併階段將忽略此限制。

例如，集羣由2個分片組成，每個分片包含一個包含100行的表，現在查詢想要返回所有數據。

假設設置max_rows_to_read=150，那麼查詢失敗，因爲總共有200行數據。
假設設置max_rows_to_read_leaf=150，那麼查詢成功，因爲每個節點只有100行。

<max_bytes_to_read>

運行查詢時可以從表中讀取的最大字節數（未壓縮數據）。

<max_bytes_to_read_leaf>

運行分佈式查詢時，可以從葉節點上的本地表讀取的最大字節數（未壓縮的數據）。僅在葉節點上的讀取階段檢查此限制，而在根節點上的結果合併階段將忽略此限制。

例如，集羣由2個分片組成，每個分片包含一個包含100字節的表，現在查詢想要返回所有數據。

假設設置max_bytes_to_read=150，那麼查詢失敗，因爲總共有200字節數據。
假設設置max_bytes_to_read_leaf=150，那麼查詢成功，因爲每個節點只有100字節。

<read_overflow_mode>

讀取的數據量超過其中一個限制時該怎麼辦: ‘throw’ 或 ‘break’. 默認情況下是throw，拋出異常

<read_overflow_mode_leaf>

讀取的數據量超過葉節點其中一個限制時該怎麼辦: ‘throw’ 或 ‘break’. 默認情況下是throw，拋出異常

<max_rows_to_group_by>

從聚合接收的唯一密鑰的最大數量。 此設置允許您在聚合時限制內存消耗。

<group_by_overflow_mode>

當聚合的唯一鍵數超過限制時該怎麼辦:‘throw’ 或 ‘break’或‘any’,默認情況下是throw，拋出異常

使用“ any”值，您可以近似計算GROUP BY。這種近似的質量取決於數據的統計性質。

<max_bytes_before_external_group_by>

啓用或禁用GROUP BY外部存儲器中子句的執行。請參閱外部存儲器中的GROUP BY。

可能的值：

• 單個GROUP BY操作可以使用的最大RAM量（以字節爲單位）。
• 0-GROUP BY禁用外部存儲器。

默認值：0。

<max_rows_to_sort>

排序前允許的最大行數。這樣可以限制排序時的內存消耗。

<max_bytes_to_sort>

排序前允許的最大字節數。

<sort_overflow_mode>

如果排序前收到的行數超過限制之一該怎麼辦: ‘throw’ 或 ‘break’. 默認情況下是throw，拋出異常

<max_result_rows>

限制結果中的行數。運行部分分佈式查詢時，還檢查在遠程服務器上的子查詢。

<max_result_bytes>

限制結果中的字節數。運行部分分佈式查詢時，還檢查在遠程服務器上的子查詢。

<result_overflow_mode>

如果返回結果量超過限制該怎麼辦: ‘throw’ 或 ‘break’. 默認情況下是throw，拋出異常

使用“ break”類似於使用LIMIT。Break僅在塊級別中斷執行。這意味着返回的行數會大於max_result_rows、max_block_size（不在本章，在config.xml）的倍數，並取決於max_threads（不在本章，在config.xml）

舉例和結果：

SET max_threads = 3, max_block_size = 3333;
SET max_result_rows = 3334, result_overflow_mode = 'break';
 
SELECT *
FROM numbers_mt(100000)
FORMAT Null;
 
 
6666 rows in set. ...

<max_execution_time>

最大查詢執行時間，以秒爲單位。

目前，不檢查排序階段、合併和最終確定集合函數。

<timeout_overflow_mode>

如果查詢運行時間超過'max_execution_time'：‘throw’ 或 ‘break’. 默認情況下是throw，拋出異常

<min_execution_speed>

最小執行速度（每秒行數）。當'timeout_before_checking_execution_speed'到期時，檢查每個數據塊。如果執行速度較低，則會引發異常。

<min_execution_speed_bytes>

每秒最小執行字節數。當'timeout_before_checking_execution_speed'到期時，檢查每個數據塊。如果執行速度較低，則會引發異常。

<max_execution_speed>

每秒最大執行行數。當'timeout_before_checking_execution_speed'到期時，檢查每個數據塊。如果執行速度很高，執行速度將降低。

<max_execution_speed_bytes>

每秒最大執行字節數。當'timeout_before_checking_execution_speed'到期時，檢查每個數據塊。如果執行速度很高，執行速度將降低。

<timeout_before_checking_execution_speed>

在以秒爲單位的指定時間到期後，檢查執行速度

<max_columns_to_read>

單個查詢中可以從表中讀取的最大列數。如果查詢需要讀取更多的列，則會引發異常。

<max_temporary_columns>

運行查詢時必須同時在RAM中保留的臨時列的最大數量，包括常量列。如果臨時列多於此，則會引發異常。

<max_temporary_non_const_columns>

與“ max_temporary_columns”相同，但不計算常量列。請注意，運行查詢時經常會形成常數列，但它們需要大約零計算資源。

<max_subquery_depth>

子查詢的最大嵌套深度。如果子查詢更深，則會引發異常。默認情況下爲100。

<max_pipeline_depth>

最大管道深度。對應於每個數據塊在查詢處理期間經歷的轉換次數。計入單個服務器的限制內。如果管道深度更大，則會引發異常。默認情況下爲1000。

<max_ast_depth>

查詢語法樹的最大嵌套深度。如果超過，則會引發異常。

目前，在解析期間不會對其進行檢查，而只會在解析查詢之後進行檢查。也就是說，在解析過程中可能會創建過深的語法樹。默認情況下爲1000。

<max_ast_elements>

查詢語法樹中的最大元素數。如果超過，則會引發異常。
與以前的設置相同，僅在解析查詢後纔對其進行檢查。默認情況下爲50,000。

<max_rows_in_set>

從子查詢創建的IN子句中的數據集的最大行數。

<max_bytes_in_set>

從子查詢創建的IN子句中的集合使用的最大字節數（未壓縮的數據）。

<set_overflow_mode>

IN子句中的集合數據量超過以下限制之一時該怎麼辦：‘throw’ 或 ‘break’. 默認情況下是throw，拋出異常

<max_rows_in_distinct>

使用DISTINCT時的最大不同行數。

<max_bytes_in_distinct>

使用DISTINCT時，哈希表使用的最大字節數。

<distinct_overflow_mode>

使用DISTINCT時的數據量超過限制之一時該怎麼辦：‘throw’ 或 ‘break’. 默認情況下是throw，拋出異常

<max_rows_to_transfer>

使用GLOBAL IN時可以傳遞到遠程服務器或保存在臨時表中的最大行數。

<max_bytes_to_transfer>

使用GLOBAL IN時，可以傳遞到遠程服務器或保存在臨時表中的最大字節數（未壓縮的數據）。

<transfer_overflow_mode>

當數據量超過以下限制之一時該怎麼辦：‘throw’ 或 ‘break’. 默認情況下是throw，拋出異常

<max_rows_in_join>

限制聯接表時使用的哈希表中的行數。

此設置適用於SELECT…JOIN操作和Join表引擎。

如果查詢包含多個聯接，ClickHouse將爲每個中間結果檢查此設置。

可能的值：

• 正整數。
• 0-無限行。

默認值：0。

<max_bytes_in_join>

限制聯接表時使用的哈希表的大小（以字節爲單位）。

此設置適用於SELECT…JOIN操作和Join表引擎。

如果查詢包含聯接，ClickHouse將爲每個中間結果檢查此設置。

可能的值：

• 正整數。
• 0-禁用內存控制。

默認值：0。

<join_overflow_mode>

當每個中間結果超過以下限制之一時該怎麼辦：‘throw’ 或 ‘break’. 默認情況下是throw，拋出異常

<max_partitions_per_insert_block>

限制單個插入塊中的最大分區數。

• 正整數。
• 0-無限數量的分區。

默認值：100。

插入數據時，ClickHouse計算插入的塊中的分區數。如果分區數大於max_partitions_per_insert_block，則ClickHouse會引發帶有以下文本的異常：

“Too many partitions for single INSERT block (more than” + toString(max_parts) + “). The limit is controlled by ‘max_partitions_per_insert_block’ setting. A large number of partitions is a common misconception. It will lead to severe negative performance impact, including slow server startup, slow INSERT queries and slow SELECT queries. Recommended total number of partitions for a table is under 1000..10000. Please note, that partitioning is not intended to speed up SELECT queries (ORDER BY key is sufficient to make range queries fast). Partitions are intended for data manipulation (DROP PARTITION, etc).”
profile中的設定項——設置約束（Constraints on Settings）

profile中的設定項-constraints

在user.xml配置文件的profile選項組下constraints選項組裏定義對設置的約束，並禁止用戶使用SET查詢更改某些設置。constraints標籤可以設置一組約束條件，以限制profile內的參數值被隨意修改，約束條件有如下三種規則：

• min：最小值約束，在設置相應參數的時候，取值不能小於該閾值；
• max：最大值約束，在設置相應參數的時候，取值不能大於該閾值；
• readonly：只讀約束，該參數值不允許被修改。

需要在profile選項組裏設置constraints，模板：

<profiles>
  <user_name>
    <constraints>
      <setting_name_1>
        <min>lower_boundary</min>
      </setting_name_1>
      <setting_name_2>
        <max>upper_boundary</max>
      </setting_name_2>
      <setting_name_3>
        <min>lower_boundary</min>
        <max>upper_boundary</max>
      </setting_name_3>
      <setting_name_4>
        <readonly/>
      </setting_name_4>
    </constraints>
  </user_name>
</profiles>

說明：如果違反約束，則會引發異常，並且設置實際上不會更改。支持三種約束類型：最小，最大，只讀。

最小和最大約束爲數字設置指定上限和下限，並且可以組合使用。

只讀約束指定用戶完全不能更改相應的設置。如：

<profiles>
  <default>
    <max_memory_usage>10000000000</max_memory_usage>
    <force_index_by_date>0</force_index_by_date>
    ...
    <constraints>
      <max_memory_usage>
        <min>5000000000</min>
        <max>20000000000</max>
      </max_memory_usage>
      <force_index_by_date>
        <readonly/>
      </force_index_by_date>
    </constraints>
  </default>
</profiles>

以下查詢均引發異常：

SET max_memory_usage=20000000001;
SET max_memory_usage=4999999999;
SET force_index_by_date=1;

Code: 452, e.displayText() = DB::Exception: Setting max_memory_usage should not be greater than 20000000000.
Code: 452, e.displayText() = DB::Exception: Setting max_memory_usage should not be less than 5000000000.
Code: 452, e.displayText() = DB::Exception: Setting force_index_by_date should not be changed.

說明：在default默認profile中定義的constraints約束，將作爲默認的全局約束，自動被其他profile繼承。例子中約束了參數max_memory_usage的最大最小值和參數force_index_by_date的只讀屬性，不能修改。如果違反約束則會報錯。

quotas

配額，限制使用資源，限制有二種類型：一是在固定週期裏的執行次數(quotas)，二是限制用戶或則查詢的使用資源（profiles）

在user.xml配置文件的選項組quotas裏設置，限制該用戶一段時間內的資源使用，即對一段時間內運行的一組查詢施加限制，而不是限制單個查詢。

還具有限制單個查詢的複雜性(上面提到的“profile中的設定項——對查詢複雜度的設置”)的功能。

與查詢複雜度限制相反，配額：

• 對可以在一段時間內運行的一組查詢施加限制，而不是限制單個查詢。
• 計入在所有遠程服務器上用於分佈式查詢處理的資源。

模板：
 

<!-- Quotas. -->
    <quotas>
        <!-- Name of quota. -->
        <default> --指定quotas名
            <!-- Limits for time interval. You could specify many intervals with different limits. -->
            <interval> --時間間隔
                <!-- Length of interval. -->
                <duration>3600</duration> --週期
                <!-- No limits. Just calculate resource usage for time interval. -->
                <queries>0</queries>
                <errors>0</errors>
                <result_rows>0</result_rows>
                <read_rows>0</read_rows>
                <execution_time>0</execution_time>
            </interval>
        </default>
    </quotas>

說明：

• <default>：配額規則名。
• <interval>：配置時間間隔，每個時間內的資源消耗限制。
• <duration>：時間週期，單位秒。
• <queries>：時間週期內允許的請求總數，0表示不限制。
• <errors>：時間週期內允許的異常總數，0表示不限制。
• <result_rows>：時間週期內允許返回的行數，0表示不限制。
• <read_rows>：時間週期內允許在分佈式查詢中，遠端節點讀取的數據行數，0表示不限制。
• <execution_time>：時間週期內允許執行的查詢時間，單位是秒，0表示不限制。

默認情況下，配額跟蹤每小時的資源消耗，而不限制使用量。
在每個請求之後，針對每個時間間隔計算的資源消耗將輸出到服務器日誌。

下面是非默認情況的另一組配額：

//以下內容是在<quotas>中定義的
<statbox>
    <!-- Restrictions for a time period. You can set many intervals with different restrictions. -->
    <interval>
        <!-- Length of the interval. -->
        <duration>3600</duration>
 
        <queries>1000</queries>
        <errors>100</errors>
        <result_rows>1000000000</result_rows>
        <read_rows>100000000000</read_rows>
        <execution_time>900</execution_time>
    </interval>
 
    <interval>
        <duration>86400</duration>
 
        <queries>10000</queries>
        <errors>1000</errors>
        <result_rows>5000000000</result_rows>
        <read_rows>500000000000</read_rows>
        <execution_time>7200</execution_time>
    </interval>
</statbox>

如果在至少一個時間間隔內超過了限制，則將引發一個異常，並顯示一條文本：是對於哪一個間隔的，何時新間隔可以開始（何時可以再次發送查詢）。

Code: 201. DB::Exception: Received from localhost:9000. DB::Exception: Quota for user `default` for 10s has been exceeded: queries = 4/3. Interval will end at 2020-04-02 11:29:40. Name of quota template: `default`.

從實施定義的固定時刻開始計算時間間隔。間隔結束時，將清除所有收集的值。 接下來的一個小時，配額計算將重新開始。對於分佈式查詢處理，累積量存儲在請求者服務器上。 因此，如果用戶轉到另一臺服務器，則那裏的配額將重新開始。重新啓動服務器後，配額將重置。

如果不是根據時間週期而是根據查詢的資源消耗來進行限制，則在user.xml裏的profile裏進行設置，如上面提到的max_memory_usage、max_rows_to_group_by之類。

此外，配額可以使用“配額鍵（quota key）”功能獨立報告多個鍵的資源。舉例：
 

<!-- For the global reports designer. -->
<web_global>
    <!-- keyed – The quota_key "key" is passed in the query parameter,
            and the quota is tracked separately for each key value.
        For example, you can pass a Yandex.Metrica username as the key,
            so the quota will be counted separately for each username.
        Using keys makes sense only if quota_key is transmitted by the program, not by a user.
        You can also write <keyed_by_ip />, so the IP address is used as the quota key.
        (But keep in mind that users can change the IPv6 address fairly easily.)
    -->
    <keyed />

users

在user.xml配置文件的users選項組是配置自定義用戶，定義一個新用戶，必須包含以下幾項屬性：用戶名、密碼、訪問ip、數據庫、表等等。它還可以應用上面的profile、quota。

<users>
    <!-- If user name was not specified, 'default' user is used. -->
    <user_name>
        <password></password>
        <!-- Or -->
        <password_sha256_hex></password_sha256_hex>
 
        <access_management>0|1</access_management>
 
        <networks incl="networks" replace="replace">
        </networks>
 
        <profile>profile_name</profile>
 
        <quota>default</quota>
 
        <databases>
            <database_name>
                <table_name>
                    <filter>expression</filter>
                <table_name>
            </database_name>
        </databases>
    </user_name>
    <!-- Other users settings -->
</users>

• <user_name>：自定義用戶
• <password>：用戶密碼，密碼可以以純文本、SHA256（十六進制格式）、password_double_sha1_hex（和MySQL兼容）指定，設置方法如下：

1.     以純文本形式分配密碼（不建議使用），將其放在一個password元素中。例如，<password>qwerty</password>。密碼可以留空。       
2.  使用SHA256哈希值分配密碼，將其放在一個password_sha256_hex元素中。例如，<password_sha256_hex>65e84be33532fb784c48129675f9eff3a682b27168c0ea744b2cf58ee02337c5</password_sha256_hex>。如何從shell生成密碼的示例：    PASSWORD=$(base64 < /dev/urandom | head -c8); echo "$PASSWORD"; echo -n "$PASSWORD" | sha256sum | tr -d '-'。結果的第一行是密碼。第二行是對應的SHA256哈希。
3. 爲了與MySQL客戶端兼容，可以在雙SHA1哈希中指定密碼。將其放在password_double_sha1_hex元素中。例如，<password_double_sha1_hex>08b4a0f1de6ad37da17359e592c8d74788a83eb0</password_double_sha1_hex>。如何從shell生成密碼的示例：  PASSWORD=$(base64 < /dev/urandom | head -c8); echo "$PASSWORD"; echo -n "$PASSWORD" | sha1sum | tr -d '-' | xxd -r -p | sha1sum | tr -d '-'。結果的第一行是密碼。第二行是對應的雙SHA1哈希。

 

• <access_management>：此設置爲用戶啓用或禁用SQL驅動的訪問控制和帳戶管理。

可能的值：0-禁用。1-啓用。默認爲0

• <networks>：用戶可以從中連接到ClickHouse服務器的網絡列表。列表的每個元素可以具有以下形式之一：

1. <ip> — IP地址或網絡掩碼。例如：213.180.204.3，10.0.0.1/8，10.0.0.1/255.255.255.0，2a02:6b8::3，2a02:6b8::3/64，2a02:6b8::3/ffff:ffff:ffff:ffff::。
2. <host> - 主機名。範例：example01.host.ru。爲了檢查訪問，將執行DNS查詢，並將所有返回的IP地址與對等地址進行比較。
3. <host_regexp> —主機名的正則表達式。範例：^example\d\d-\d\d-\d\.host\.ru$。爲了檢查訪問，對同一個地址執行DNS PTR查詢，然後應用指定的正則表達式。然後，對PTR查詢的結果執行另一個DNS查詢，並將所有接收到的地址與對等地址進行比較。我們強烈建議regexp以$結尾。

要爲來自任何網絡的用戶打開訪問權限，請指定：
<ip>::/0</ip>
 
 
要僅打開來自本地主機的訪問，請指定：
<ip>::1</ip>
<ip>127.0.0.1</ip>

• <profile>：指定用戶的profile，上面有詳細介紹。
• <quota>：指定用戶的quota，限制用戶使用資源，上面有詳細介紹。
• <database_name>：指定用戶訪問的數據庫

    可以限制ClickHouse返回的行以供SELECT當前用戶進行的查詢，從而實現基本的行級安全性。
    例如。以下配置強制用戶user1只能看到table1作爲SELECT查詢結果的id字段，其中字段的值爲1000。

<user1>
    <databases>
        <database_name>
            <table1>
                <filter>id = 1000</filter>
            </table1>
        </database_name>
    </databases>
</user1>

• <table_name>：指定用戶訪問的表
• <filter>：指定用戶訪問的過濾器，該 filter 可以是導致任何表達式 UInt8-鍵入值。 它通常包含比較和邏輯運算符。 

    如：id = 1 ，即查詢表只返回id=1的行
    如：id >= 500，即查詢表只返回id>=500的行

自定義設置

除了通用設置，用戶還可以定義自定義設置。

定義設置名稱必須以預定義前綴之一開頭。這些前綴的列表必須在服務器配置文件的custom_settings_prefixes參數中聲明。 

<custom_settings_prefixes>custom_</custom_settings_prefixes>

要定義自定義設置，請使用SET命令：

SET custom_a = 123;

要獲取自定義設置的當前值，請使用getSetting()函數：

SELECT getSetting('custom_a');