文章目录
数据字典
参考：《ClickHouse原理解析与应用实践》第5章、第8章8.4.2节
数据字典是clickhouse提供的一种简单 实用的存储媒介，以键值和属性映射的形式定义数据。字典中的数据会主动或被动加载到内存之中，并支持动态更新。由于字典数据常驻内存特特性，比较适合保存常量或者经常使用的维度表数据，以避免不必要的JOIN数据。
数据字典分为内置和扩展两种形式，内置数据字典是以clickhouse默认自带的字典；外部字典是通过用户自定义配置实现的字典。
在正常情况下，字典中的数据只能通过字典函数访问。但是也有一种例外，那就是使用特殊的字典表引擎。在字典表 引擎的帮助下，可以将数据字典挂载到一张代理的数据表下，从而实 现数据表与字典数据的JOIN查询。
内置字典
ClickHouse目前只有一种内置字典——Yandex.Metrica字典。（ClickHouse目前的内 置字典，只是提供了字典的定义机制和取数函数，需要遵照它的字典规范自 行导入数据。）
1、开启内置字典
内置字典在默认的情况下是禁用状态，需要开启后才能使用
将config.xml文件中path_to_regions_hierarchy_file和 path_to_regions_names_files两项配置打开。
<path_to_regions_hierarchy_file>/opt/geo/regions_hierarchy.txt</path_to_regions_hierarchy_file>
<path_to_regions_names_files>/opt/geo/</path_to_regions_names_files>
2、导入数据
将下列用于测试的数据 文件复制到刚才已经建好的/opt/geo目录下
[machine@hadoop104 geo]$ pwd
/opt/geo
[machine@hadoop104 geo]$ ll
总用量 36
-rw-rw-r-- 1 machine machine 3096 11月 12 18:04 regions_hierarchy_ru.txt
-rw-rw-r-- 1 machine machine 3096 11月 12 18:04 regions_hierarchy.txt
-rw-rw-r-- 1 machine machine 3957 11月 12 18:04 regions_names_ar.txt
-rw-rw-r-- 1 machine machine 3957 11月 12 18:04 regions_names_by.txt
-rw-rw-r-- 1 machine machine 3957 11月 12 18:04 regions_names_en.txt
-rw-rw-r-- 1 machine machine 3957 11月 12 18:04 regions_names_kz.txt
-rw-rw-r-- 1 machine machine 3957 11月 12 18:04 regions_names_ru.txt
-rw-rw-r-- 1 machine machine 3957 11月 12 18:04 regions_names_tr.txt
-rw-rw-r-- 1 machine machine 3957 11月 12 18:04 regions_names_ua.txt
3、重启clickhouse-server
4、访问字典中的数据
hadoop104 :) SELECT regionToName(toUInt32(20009));
SELECT regionToName(toUInt32(20009))
Query id: abf6714b-843e-4741-807d-46e27b3cdf0e
┌─regionToName(toUInt32(20009))─┐
│ Buenos Aires Province │
└───────────────────────────────┘
类似regionToName这样的函数，在ClickHouse中它们被称为Yandex.Metrica函数。
外部扩展字典-准备数据
外部扩展字典是以插件形式注册到ClickHouse中的，由用户自行定义数据模式及数据来源。目前扩展字典支持7种类型的内存布局和4 类数据来源。相比内容十分有限的内置字典，扩展字典才是更加常用 的功能。
[machine@hadoop104 testdata]$ pwd
/opt/module/datas/testdata
[machine@hadoop104 testdata]$ ll
总用量 12
-rw-rw-r-- 1 machine machine 164 11月 12 22:39 asn.csv
-rw-rw-r-- 1 machine machine 162 11月 12 22:39 organization.csv
-rw-rw-r-- 1 machine machine 233 11月 12 22:39 sales.csv
[machine@hadoop104 testdata]$ cat asn.csv
"82.118.230.0/24","AS42831","GB"
"148.163.0.0/17","AS53755","US"
"178.93.0.0/18","AS6849","UA"
"200.69.95.0/24","AS262186","CO"
"154.9.160.0/20","AS174","US"
[machine@hadoop104 testdata]$ cat organization.csv
1,"a0001","研发部"
2,"a0002","产品部"
3,"a0003","数据部"
4,"a0004","测试部"
5,"a0005","运维部"
6,"a0006","规划部"
7,"a0007","市场部"
[machine@hadoop104 testdata]$ cat sales.csv
1,2016-01-01,2017-01-10,100
2,2016-05-01,2017-07-01,200
3,2014-03-05,2018-01-20,300
4,2018-08-01,2019-10-01,400
5,2017-03-01,2017-06-01,500
6,2017-04-09,2018-05-30,600
7,2018-06-01,2019-01-25,700
8,2019-08-01,2019-12-12,800
扩展字典配置文件的元素组成
扩展字典的配置文件由config.xml文件中的dictionaries_config 配置项指定:
<dictionaries_config>*_dictionary.xml</dictionaries_config>
在默认的情况下，ClickHouse会自动识别并加 载/etc/clickhouse-server目录下所有以_dictionary.xml结尾的配置 文件。同时ClickHouse也能够动态感知到此目录下配置文件的各种变 化，并支持不停机在线更新配置文件。
它们完整的配置结构如下所示
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>
dict_name
</name>
<structure>
<!—字典的数据结构 -->
</structure>
<layout>
<!—在内存中的数据格式类型 -->
</layout>
<source>
<!—数据源配置 -->
</source>
<lifetime>
<!—字典的自动更新频率 -->
</lifetime>
</dictionary>
</dictionaries>
7种扩展字典类型的配置方法
扩展字典的类型使用layout元素定义，目前共有7种类型。一个字典的 类型，既决定了其数据在内存中的存储结构，也决定了该字典支持的key键 类型。根据key键类型的不同，可以将它们划分为两类:
- 单数值key类型（flat、 hashed、range_hashed和cache）
- 复合key类型（complex_key_hashed、complex_key_cache和 ip_trie）。
1.flat
flat字典是所有类型中性能最高的字典类型，它只能使用UInt64数值型 key。顾名思义，flat字典的数据在内存中使用数组结构保存，数组的初始 大小为1024，上限为500 000，这意味着它最多只能保存500 000行数据。如 果在创建字典时数据量超出其上限，那么字典会创建失败。
/etc/clickhouse- server/test_flat_dictionary.xml
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_flat_dict</name>
<source>
<!-- 准备好的测试数据 -->
<file>
<path>/opt/module/datas/testdata/organization.csv</path>
<format>CSV</format>
</file>
</source>
<layout>
<flat/>
</layout>
<!-- 与测试数据的结构对应 -->
<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>code</name>
<type>String</type>
<null_value/>
</attribute>
<attribute>
<name>name</name>
<type>String</type>
<null_value/>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
查验system.dictionaries 系统表后，能够看到flat字典已经创建成功
hadoop104 :) SELECT name, type, key, attribute.names, attribute.types FROM system.dictionaries;
SELECT
name,
type,
key,
attribute.names,
attribute.types
FROM system.dictionaries
Query id: 24e3570b-cc74-486a-bf1c-529900ad6e7e
┌─name───────────┬─type─┬─key────┬─attribute.names─┬─attribute.types─────┐
│ test_flat_dict │ │ UInt64 │ ['code','name'] │ ['String','String'] │
└────────────────┴──────┴────────┴─────────────────┴─────────────────────┘
2.hashed
hashed字典同样只能够使用UInt64数值型key，但与flat字典不同的 是，hashed字典的数据在内存中通过散列结构保存，且没有存储上限的制约。
test_hashed_dictionary.xml
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_hashed_dict</name>
<source>
<file>
<path>/opt/module/datas/testdata/organization.csv</path>
<format>CSV</format>
</file>
</source>
<layout>
<hashed/>
</layout>
<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>code</name>
<type>String</type>
<null_value/>
</attribute>
<attribute>
<name>name</name>
<type>String</type>
<null_value/>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
3.range_hashed
range_hashed字典可以看作hashed字典的变种，它在原有功能的基础上 增加了指定时间区间的特性，数据会以散列结构存储并按照时间排序。时间区间通过range_min和range_max元素指定，所指定的字段必须是Date或者 DateTime类型。
test_range_hashed_dictionary.xml
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_range_hashed_dict</name>
<source>
<file>
<path>/opt/module/datas/testdata/sales.csv</path>
<format>CSV</format>
</file>
</source>
<layout>
<range_hashed/>
</layout>
<structure>
<id>
<name>id</name>
</id>
<range_min>
<name>start</name>
</range_min>
<range_max>
<name>end</name>
</range_max>
<attribute>
<name>price</name>
<type>Float32</type>
<null_value/>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
4.cache
cache字典只能够使用UInt64数值型key，它的字典数据在内存中会通过 固定长度的向量数组保存。定长的向量数组又称cells，它的数组长度由 size_in_cells指定。而size_in_cells的取值大小必须是2的整数倍，如若 不是，则会自动向上取为2的倍数的整数。
cache字典的取数逻辑与其他字典有所不同，它并不会一次性将所有数 据载入内存。当从cache字典中获取数据的时候，它首先会在cells数组中检 查该数据是否已被缓存。如果数据没有被缓存，它才会从源头加载数据并缓 存到cells中。
所以cache字典是性能最不稳定的字典，因为它的性能优劣完 全取决于缓存的命中率(缓存命中率=命中次数/查询次数)，如果无法做到 99%或者更高的缓存命中率，则最好不要使用此类型。
test_cache_dictionary.xml
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_cache_dict</name>
<source>
<!-- 本地文件需要通过 executable形式 -->
<executable>
<command>cat /opt/module/datas/testdata/organization.csv</command>
<format>CSV</format>
</executable>
</source>
<layout>
<cache>
<!-- 缓存大小 -->
<size_in_cells>10000</size_in_cells>
</cache>
</layout>
<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>code</name>
<type>String</type>
<null_value/>
</attribute>
<attribute>
<name>name</name>
<type>String</type>
<null_value/>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
关于cells的取值可以根据实际情况考虑，在内存宽裕的情况下设 置成1000000000也是可行的。还有一点需要注意，如果cache字典使用本地 文件作为数据源，则必须使用executable的形式设置。
5.complex_key_hashed
complex_key_hashed字典在功能方面与hashed字典完全相同，只是将单 个数值型key替换成了复合型。
test_complex_key_hashed_dictionary.xml
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_complex_key_hashed_dict</name>
<source>
<file>
<path>/opt/module/datas/testdata/organization.csv</path>
<format>CSV</format>
</file>
</source>
<layout>
<complex_key_hashed/>
</layout>
<structure>
<!-- 复合型key -->
<key>
<attribute>
<name>id</name>
<type>UInt64</type>
</attribute>
<attribute>
<name>code</name>
<type>String</type>
</attribute>
</key>
<attribute>
<name>name</name>
<type>String</type>
<null_value/>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
6.complex_key_cache
test_complex_key_cache_dictionary.xml
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_complex_key_cache_dict</name>
<source>
<executable>
<command>cat /opt/module/datas/testdata/organization.csv</command>
<format>CSV</format>
</executable>
</source>
<layout>
<complex_key_cache>
<size_in_cells>10000</size_in_cells>
</complex_key_cache>
</layout>
<structure>
<!-- 复合型Key -->
<key>
<attribute>
<name>id</name>
<type>UInt64</type>
</attribute>
<attribute>
<name>code</name>
<type>String</type>
</attribute>
</key>
<attribute>
<name>name</name>
<type>String</type>
<null_value/>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
7.ip_trie
虽然同为复合型key的字典，但ip_trie字典却较为特殊，因为它只能指定单个String类型的字段，用于指代IP前缀。ip_trie字典的数据在内存中使用trie树结构保存，且专门用于IP前缀查询的场景，例如通过IP前缀查询对应的ASN信息。
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_ip_trie_dict</name>
<source>
<file>
<path>/opt/module/datas/testdata/asn.csv</path>
<format>CSV</format>
</file>
</source>
<layout>
<ip_trie/>
</layout>
<structure>
<!-- 虽然是复合类型,但是只能设置单个String类型的字段 -->
<key>
<attribute>
<name>prefix</name>
<type>String</type>
</attribute>
</key>
<attribute>
<name>asn</name>
<type>String</type>
<null_value/>
</attribute>
<attribute>
<name>country</name>
<type>String</type>
<null_value/>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
在这些字典中，flat、hashed和range_hashed依次拥有最高的性能，而cache性能最不稳定。
总结一下这些字典各自的特点:
扩展字典的数据源
文件类型
1)本地文件
<source>
<file>
<path>/data/dictionaries/organization.csv</path>
<format>CSV</format>
</file>
</source>
2)可执行文件
可执行文件数据源属于本地文件的变种，它需要通过cat命令访问数据文件。对于cache和 complex_key_cache类型的字典，必须使用此类型的文件数据源。
<source>
<executable>
<command>cat /data/dictionaries/organization.csv</command>
<format>CSV</format>
</executable>
</source>
3)远程文件
远程文件与可执行文件类似，只是它将cat命令替换成了post请求，支持HTTP与HTTPS协议。远程文件 使用http元素定义。
<source>
<http>
<url>http://10.211.55.18/organization.csv</url>
<format>CSV</format>
</http>
</source>
数据库类型
相比文件类型，数据库类型的数据源更适合在正式的生产环境中使用。目前扩展字典支持MySQL、 ClickHouse本身及MongoDB三种数据库。
1)MySQL
test_mysql_dictionary.xml
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_mysql_dict</name>
<source>
<mysql>
<port>3306</port>
<user>root</user>
<password/>
<replica>
<host>10.37.129.2</host>
<priority>1</priority>
</replica>
<db>test</db>
<table>t_organization</table>
<!--
<where>id=1</where>-->
<invalidate_query>select updatetime from t_organization where id = 8</invalidate_query>
</mysql>
</source>
<layout>
<flat/>
</layout>
<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>code</name>
<type>String</type>
<null_value/>
</attribute>
<attribute>
<name>name</name>
<type>String</type>
<null_value/>
</attribute>
<attribute>
<name>updatetime</name>
<type>DateTime</type>
<null_value/>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
2)ClickHouse
创建测试表并写入测试数据
CREATE TABLE t_organization (
ID UInt64,
Code String,
Name String,
UpdateTime DateTime
) ENGINE = TinyLog;
--写入测试数据
INSERT INTO t_organization VALUES
(1,'a0001','研发部',NOW()),
(2,'a0002','产品部' ,NOW()),
(3,'a0003','数据部',NOW());
test_ch_dictionary.xml
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_ch_dict</name>
<source>
<clickhouse>
<host>hadoop104</host>
<port>9000</port>
<user>default</user>
<password/>
<db>default</db>
<table>t_organization</table>
<!--
<where>id=10</where>-->
<!-- 指定一条SQL语句，用于在数据更新时判断是否需要更新，非必填项 -->
<invalidate_query>SELECT UpdateTime FROM t_organization WHERE ID = 1</invalidate_query>
</clickhouse>
</source>
<layout>
<flat/>
</layout>
<!--大小写敏感,需要与数据表字段对应-->
<structure>
<id>
<name>ID</name>
</id>
<attribute>
<name>Code</name>
<type>String</type>
<null_value/>
</attribute>
<attribute>
<name>Name</name>
<type>String</type>
<null_value/>
</attribute>
<attribute>
<name>UpdateTime</name>
<type>DateTime</type>
<null_value/>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
3)MongoDB
test_mongodb_dictionary.xml
<?xml version="1.0"?>
<dictionaries>
<dictionary>
<name>test_mongodb_dict</name>
<source>
<mongodb>
<host>10.37.129.2</host>
<port>27017</port>
<user/>
<password/>
<db>test</db>
<collection>t_organization</collection>
</mongodb>
</source>
<layout>
<flat/>
</layout>
<structure>
<id>
<name>id</name>
</id>
<attribute>
<name>code</name>
<type>String</type>
<null_value/>
</attribute>
<attribute>
<name>name</name>
<type>String</type>
<null_value/>
</attribute>
</structure>
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
</dictionary>
</dictionaries>
其他类型
除了上述已经介绍过的两类数据源之外，扩展字典还支持通过ODBC的方式连接PostgreSQL和MS SQL Server数据库作为数据源。它们的配置方式与数据库类型数据源大同小异。
扩展字典的基本操作
元数据查询
SELECT
name,
type,
key,
attribute.names,
attribute.types,
source
FROM system.dictionaries
Query id: 4625f579-ea04-4203-a21f-b939a4fb0b92
Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 21.7.3 revision 54449.
┌─name─────────────────────────┬─type─┬─key──────────────┬─attribute.names───┬─attribute.types─────┬─source─┐
│ test_ip_trie_dict │ │ (String) │ ['asn','country'] │ ['String','String'] │ │
│ test_hashed_dict │ │ UInt64 │ ['code','name'] │ ['String','String'] │ │
│ test_complex_key_hashed_dict │ │ (UInt64, String) │ ['name'] │ ['String'] │ │
│ test_flat_dict │ │ UInt64 │ ['code','name'] │ ['String','String'] │ │
│ test_cache_dict │ │ UInt64 │ ['code','name'] │ ['String','String'] │ │
│ test_complex_key_cache_dict │ │ (UInt64, String) │ ['name'] │ ['String'] │ │
│ test_range_hashed_dict │ │ UInt64 │ ['price'] │ ['Float32'] │ │
└──────────────────────────────┴──────┴──────────────────┴───────────────────┴─────────────────────┴────────┘
数据查询
在正常情况下，字典数据只能通过字典函数获取，例如下面的语句就使用到了 dictGet('dict_name','attr_name',key)函数。
SELECT dictGet('test_flat_dict', 'name', toUInt64(1))
Query id: 3f8577a3-ac60-4919-8222-3856bd1854c7
┌─dictGet('test_flat_dict', 'name', toUInt64(1))─┐
│ 研发部 │
└────────────────────────────────────────────────┘
如果字典使用了复合型key，则需要使用元组作为参数传入:
SELECT dictGet('test_ip_trie_dict', 'asn', tuple(IPv4StringToNum('82.118.230.0')))
Query id: 812e5e7d-3f5c-42fb-942b-0fbff7d83ba5
┌─dictGet('test_ip_trie_dict', 'asn', tuple(IPv4StringToNum('82.118.230.0')))─┐
│ AS42831 │
└─────────────────────────────────────────────────────────────────────────────┘
除了dictGet函数之外，ClickHouse还提供了一系列以dictGet为前缀的字典函 数，具体如下所示。
- 获取整型数据的函数:
dictGetUInt8、dictGetUInt16、dictGetUInt32、 dictGetUInt64、dictGetInt8、dictGetInt16、dictGetInt32、dictGetInt64。 - 获取浮点数据的函数:
dictGetFloat32、dictGetFloat64。 - 获取日期数据的函数:
dictGetDate、dictGetDateTime。 - 获取字符串数据的函数:
dictGetString、dictGetUUID。
字典表
除了通过字典函数读取数据之外，ClickHouse还提供了另外一种借助字典表的形式来读取数据。字典表是使用Dictionary表引擎的数据表。
CREATE TABLE tb_test_flat_dict (
id UInt64,
code String,
name String
) ENGINE = Dictionary(test_flat_dict);
通过这张表，就能查询到字典中的数据。
SELECT *
FROM tb_test_flat_dict
Query id: 88bc9249-df97-482d-8e3d-c7fed0428751
┌─id─┬─code──┬─name───┐
│ 1 │ a0001 │ 研发部 │
│ 2 │ a0002 │ 产品部 │
│ 3 │ a0003 │ 数据部 │
│ 4 │ a0004 │ 测试部 │
│ 5 │ a0005 │ 运维部 │
│ 6 │ a0006 │ 规划部 │
│ 7 │ a0007 │ 市场部 │
└────┴───────┴────────┘
使用DDL查询创建字典
CREATE DICTIONARY test_dict(
id UInt64,
value String
)
PRIMARY KEY id
LAYOUT(FLAT())
SOURCE(FILE(PATH '/usr/bin/cat' FORMAT TabSeparated))
LIFETIME(1)
字典引擎 Dictionary
Dictionary表引擎是数据字典的一层代理封装，它可以取代字典函数，让用户通过数据表查询字典。字典内的数据被加载后，会全部保存到内存中，所以使用 Dictionary表对字典性能不会有任何影响。
tb_test_flat_dict等同于数据字典test_flat_dict的代理表，现在对它使用 SELECT语句进行查询
hadoop104 :) SELECT * FROM tb_test_flat_dict;
SELECT *
FROM tb_test_flat_dict
Query id: 6461b580-f14a-4db2-a151-0a171d19a84e
┌─id─┬─code──┬─name───┐
│ 1 │ a0001 │ 研发部 │
│ 2 │ a0002 │ 产品部 │
│ 3 │ a0003 │ 数据部 │
│ 4 │ a0004 │ 测试部 │
│ 5 │ a0005 │ 运维部 │
│ 6 │ a0006 │ 规划部 │
│ 7 │ a0007 │ 市场部 │
└────┴───────┴────────┘
如果字典的数量很多，逐一为它们创建各自的Dictionary表未免过于烦琐。这 时候可以使用Dictionary引擎类型的数据库来解决这个问题，例如:
CREATE DATABASE test_dictionaries ENGINE = Dictionary
上述语句创建了一个名为test_dictionaries的数据库，它使用了Dictionary 类型的引擎。在这个数据库中，ClickHouse会自动为每个字典分别创建它们的 Dictionary表:
hadoop104 :) SELECT database,name,engine_full FROM system.tables WHERE database = 'test_dictionaries';
SELECT
database,
name,
engine_full
FROM system.tables
WHERE database = 'test_dictionaries'
Query id: 4480377e-7207-45d9-992d-045668329645
┌─database──────────┬─name─────────────────────────────────┬─engine_full────────────────────────────────────────┐
│ test_dictionaries │ 042846e5-de89-42ff-8428-46e5de8922ff │ Dictionary(`042846e5-de89-42ff-8428-46e5de8922ff`) │
│ test_dictionaries │ test_cache_dict │ Dictionary(test_cache_dict) │
│ test_dictionaries │ test_complex_key_cache_dict │ Dictionary(test_complex_key_cache_dict) │
│ test_dictionaries │ test_complex_key_hashed_dict │ Dictionary(test_complex_key_hashed_dict) │
│ test_dictionaries │ test_flat_dict │ Dictionary(test_flat_dict) │
│ test_dictionaries │ test_hashed_dict │ Dictionary(test_hashed_dict) │
│ test_dictionaries │ test_ip_trie_dict │ Dictionary(test_ip_trie_dict) │
│ test_dictionaries │ test_range_hashed_dict │ Dictionary(test_range_hashed_dict) │
└───────────────────┴──────────────────────────────────────┴────────────────────────────────────────────────────┘
由上可以看到，当前系统中所有已加载的数据字典都在这个数据库下创建了各自的Dictionary表。
5118
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
