一、查询优化基本思路：

单从数据库角度讲，遇到性能问题，一般有以下三个大方面分析入手：
操作系统、实例、SQL

1.1、操作系统方面：

top查看cpu使用率等信息：

iostat 查看IO使用情况：
device:磁盘名称
tps:每秒钟发送到的I/O请求数.
Blk_read/s:每秒读取的block数.
Blk_wrtn/s:每秒写入的block数.
Blk_read:读入的block总数.
Blk_wrtn:写入的block总数.
通常使用：iostat -d 2 3 、 iostat -m等

dstat查看跟更详细的IO使用情况：
dstat命令是一个用来替换vmstat、iostat、netstat、nfsstat和ifstat这些命令的工具，是一个全能系统信息统计工具。默认是-cdngy参数：

free查看内存使用情况：

nmon查看一段时间的系统使用情况：这里㤇将采集到的信息下载至本地进行excel表格分析：

注意：这里如果发现主机的CPU、IO、内存等使用率很高，说明数据库已经到了瓶颈，也有可能是硬件本身条件存在问题。

1.2、数据库架构优化：

达梦数据库产品覆盖面比较广，所以产品本身性能相对比较可观，客户选择性比较多，如果是高并发型业务建议使用读写分离集群，如果是海量数据分析型业务建议使用MPP集群产品。
对于参数dm.ini：
MEMORY_POOL
BUFFER_POOLS
BUFFER
MAX_BUFFER
RECYCLE
SORT_BUF_SIZE
CACHE_POOL_SIZE
DICT_BUF_SIZE
HJ_BUF_GLOBAL_SIZE
HJ_BUF_SIZE
HAGR_BUF_GLOBAL_SIZE
HAGR_BUF_SIZE
WORKER_THREADS
ENABLE_MONITOR
OLAP_FLAG
OPTIMIZER_MODE
等，参数调整涉及面广，慎用，建议修改前先备份，评估，以免对公司及个人造成不利影响。
会话监控：
–查询活动会话数

select count(*) from v$sessions where state='ACTIVE';

–已执行超过2秒的活动SQL

select * from (
SELECT sess_id,sql_text,datediff(ss,last_send_time,sysdate) Y_EXETIME,SF_GET_SESSION_SQL(SESS_ID) fullsql,clnt_ip
FROM V$SESSIONS WHERE STATE='ACTIVE')
where Y_EXETIME>=2;

–锁查询

select o.name,l.* from v$lock l,sysobjects o where l.table_id=o.id and blocked=1;

–阻塞查询

with locks as(
select o.name,l.*,s.sess_id,s.sql_text,s.clnt_ip,s.last_send_time  from v$lock l,sysobjects o,v$sessions s
where l.table_id=o.id and l.trx_id=s.trx_id ),lock_tr as (   select trx_id wt_trxid,row_idx blk_trxid from locks where blocked=1),
res as(    select sysdate stattime,t1.name,t1.sess_id wt_sessid,s.wt_trxid,t2.sess_id blk_sessid,s.blk_trxid,t2.clnt_ip,SF_GET_SESSION_SQL(t1.sess_id) fulsql,datediff(ss,t1.last_send_time,sysdate) ss,t1.sql_text wt_sql  from lock_tr s,locks t1,locks t2
where t1.ltype='OBJECT'  and t1.table_id<>0   and t2.ltype='OBJECT'  and t2.table_id<>0and s.wt_trxid=t1.trx_id  and s.blk_trxid=t2.trx_id)
select distinct wt_sql,clnt_ip,ss,wt_trxid,blk_trxid  from res;

1.3、SQL优化：

–设置SQL过滤规则，只记录必要的SQL，生产环境不要设成1
–2 只记录DML语句
–3 只记录DDL语句
–22 记录绑定参数的语句
–25 记录SQL语句和它的执行时间
–28 记录SQL语句绑定的参数信息
修改 sqllog.ini ASYNC_FLUSH= 2:3:22:25:28
CALL SP_REFRESH_SVR_LOG_CONFIG(); --调用此存储过程生效
同步日志会严重影响系统效率，生产环境必须设置为异步日志：
修改 sqllog.ini

ASYNC_FLUSH= 1
CALL SP_REFRESH_SVR_LOG_CONFIG();

下面这个语句设置只记录执行时间超过200ms的语句
修改sqllog.ini

MIN_EXEC_TIME= 200
CALL SP_REFRESH_SVR_LOG_CONFIG();   此存储过程生效

下面的语句查看设置是否生效

SELECT * FROM V$DM_INI where para_name='SVR_LOG_ASYNC_FLUSH';
SELECT * FROM V$DM_INI where para_name='SQL_TRACE_MASK';
SELECT * FROM V$DM_INI where para_name='SVR_LOG_MIN_EXEC_TIME';

开启SQL日志：

SP_SET_PARA_VALUE(1, 'SVR_LOG', 1);

关闭SQL日志：

SP_SET_PARA_VALUE(1, 'SVR_LOG', 0);

sqllog.ini 配置示例
[SLOG_ALL]
FILE_PATH = …\log
PART_STOR = 0
SWITCH_MODE = 2
SWITCH_LIMIT = 512
ASYNC_FLUSH = 1
FILE_NUM = 4
ITEMS = 0
SQL_TRACE_MASK = 2:3:22:25:28
MIN_EXEC_TIME = 100
USER_MODE = 0
SQL优化汇总：
并发高的优先处理：
通过普通索引、聚集索引、覆盖索引等；
一般SQL其次处理：
单列索引、组合索引等；
并发少但偶尔很慢的最后处理：
SQL分散节点执行、优化复杂逻辑SQL、结果集缓存；
改写SQL：
隐式转换、过滤条件、等价改写、分析函数替代等；
ET工具：DM数据库的分析工具（MySQL：mysqldumpslow，psercona ：pt-query-diagest其他分析工具等）
ENABLE_MONITOR=1
SP_SET_PARA_VALUE(1,‘MONITOR_SQL_EXEC’,1);
SP_SET_PARA_VALUE(1,‘MONITOR_TIME’,1);
注意：ENABLE_MONITOR 这个参数可以在mount状态下，动态修改
阻塞与死锁分析：
链接地址：https://blog.csdn.net/CSDNWangJ/article/details/125196113?spm=1001.2014.3001.5501

二、执行计划：

执行计划：一条SQL语句在DM数据库中执行过程或访问路径的描述。
如何查看执行计划：
explain + SQL；
管理工具上查看；
执行计划包括哪些重要信息：

一个执行计划由若干个计划节点组成，如上图中的1、2、3
每个计划节点中包含操作符(CSCN2)和它的代价([0, 1711, 396])等信息
代价由一个三元组组成[代价,记录行数,字节数]
代价的单位是毫秒，记录行数表示该计划节点输出的行数，字节数表示该计划节点输出的字节数
解读一下第三个计划节点：操作符是CSCN2即全表扫描，代价估算是0ms，扫描的记录行数是1711行，输出字节数是396个

测试表：
DROP TABLE T1;
DROP TABLE T2;
CREATE TABLE T1(C1 INT ,C2 CHAR(1),C3 VARCHAR(10) ,C4 VARCHAR(10) );
CREATE TABLE T2(C1 INT ,C2 CHAR(1),C3 VARCHAR(10) ,C4 VARCHAR(10) );
INSERT INTO T1
SELECT LEVEL C1,CHR(65+MOD(LEVEL,57)) C2,'TEST',NULL FROM DUAL
CONNECT BY LEVEL<=10000;
INSERT INTO T2
SELECT LEVEL C1,CHR(65+MOD(LEVEL,57)) C2,'TEST',NULL  FROM DUAL
CONNECT BY LEVEL<=10000;
CREATE INDEX IDX_C1_T1 ON T1(C1);
SP_INDEX_STAT_INIT(USER,'IDX_C1_T1');

收集结果集：NSET：用于结果集收集的操作符，一般是查询计划的顶层节点：

EXPLAIN SELECT * FROM T1;
1   #NSET2: [1, 10000, 156]
2     #PRJT2: [1, 10000, 156]; exp_num(5), is_atom(FALSE)
3       #CSCN2: [1, 10000, 156]; INDEX33556710(T1)

2.1、执行计划中常用操作符解读：

投影：PRJT：关系的“投影”(project)运算，用于选择表达式项的计算；广泛用于查询，排序，函数索引创建等

EXPLAIN SELECT * FROM T1;
1   #NSET2: [1, 10000, 156]
2     #PRJT2: [1, 10000, 156]; exp_num(5), is_atom(FALSE)
3       #CSCN2: [1, 10000, 156]; INDEX33556710(T1)

选择：SLCT：关系的“选择” 运算，用于查询条件的过滤。

EXPLAIN SELECT * FROM T1 WHERE C2='TEST';
1   #NSET2: [1, 250, 156]
2     #PRJT2: [1, 250, 156]; exp_num(5), is_atom(FALSE)
3       #SLCT2: [1, 250, 156]; T1.C2 = TEST
4         #CSCN2: [1, 10000, 156]; INDEX33556717(T1)

简单聚集：AAGR：用于没有group by的count sum age max min等聚集函数的计算

EXPLAIN SELECT COUNT(*) FROM T1 WHERE C1 = 10;
1   #NSET2: [0, 1, 4]
2     #PRJT2: [0, 1, 4]; exp_num(1), is_atom(FALSE)
3       #AAGR2: [0, 1, 4]; grp_num(0), sfun_num(1)
4         #SSEK2: [0, 1, 4]; scan_type(ASC), IDX_C1_T1(T1), scan_range[10,10]

快速聚集：FAGR：用于没有过滤条件时从表或索引快速获取MAX/MIN/COUNT值；DM数据库是世界上单表不带过滤条件下取COUNT值最快的数据库。

EXPLAIN  SELECT COUNT(*) FROM T1;
1   #NSET2: [1, 1, 0]
2     #PRJT2: [1, 1, 0]; exp_num(1), is_atom(FALSE)
3       #FAGR2: [1, 1, 0]; sfun_num(1), EXPLAIN  SELECT MAX(C1) FROM T1;
1   #NSET2: [1, 1, 0]
2     #PRJT2: [1, 1, 0]; exp_num(1), is_atom(FALSE) #FAGR2: [1, 1, 0]; sfun_num(1),

HASH分组聚集：HAGR：用于分组列没有索引只能走全表扫描的分组聚集，C2列没有创建索引

EXPLAIN SELECT COUNT(*) FROM T1 GROUP BY C2;
1   #NSET2: [1, 100, 48]
2     #PRJT2: [1, 100, 48]; exp_num(1), is_atom(FALSE)
3       #HAGR2: [1, 100, 48]; grp_num(1), sfun_num(1)
4         #CSCN2: [1, 10000, 48]; INDEX33556717(T1)

流分组聚集：SAGR：用于分组列是有序的情况下，可以使用流分组聚集，C1上已经创建了索引，SAGR2性能优于HAGR2

EXPLAIN SELECT COUNT(*) FROM T1 GROUP BY C1;
1   #NSET2: [1, 100, 4]
2     #PRJT2: [1, 100, 4]; exp_num(1), is_atom(FALSE)
3       #SAGR2: [1, 100, 4]; grp_num(1), sfun_num(1)
4         #SSCN: [1, 10000, 4]; IDX_C1_T1(T1)

二次扫描：BLKUP：先使用2级别索引定位，再根据表的主键、聚集索引、rowid等信息定位数据行。

EXPLAIN SELECT * FROM T1 WHERE C1=10;
1   #NSET2: [0, 1, 156]
2     #PRJT2: [0, 1, 156]; exp_num(5), is_atom(FALSE)
3       #BLKUP2: [0, 1, 156]; IDX_C1_T1(T1)
4         #SSEK2: [0, 1, 156]; scan_type(ASC), IDX_C1_T1(T1), scan_range[10,10]

全表扫描：CSCN：CSCN2是CLUSTER INDEX SCAN的缩写即通过聚集索引扫描全表，全表扫描是最简单的查询，如果没有选择谓词，或者没有索引可以利用，则系统一般只能做全表扫描。在一个高并发的系统中应尽量避免全表扫描

EXPLAIN SELECT * FROM T1;
1   #NSET2: [1, 10000, 156]
2     #PRJT2: [1, 10000, 156]; exp_num(5), is_atom(FALSE)
3       #CSCN2: [1, 10000, 156]; INDEX33556710(T1)

索引扫描：SSEK CSEK SSCN：SSEK2是二级索引扫描即先扫描索引，再通过主键、聚集索引、ROWID等信息去扫描表，CSEK2是聚集索引扫描只需要扫描索引，不需要扫描表 SSCN是索引全扫描，不需要扫描表。

EXPLAIN SELECT * FROM T1 WHERE C1=10;
1   #NSET2: [0, 1, 156]
2     #PRJT2: [0, 1, 156]; exp_num(5), is_atom(FALSE)
3       #BLKUP2: [0, 1, 156]; IDX_C1_T1(T1)#SSEK2: [0, 1, 156]; scan_type(ASC), IDX_C1_T1(T1), scan_range[10,10]CREATE CLUSTER INDEX IDX_C1_T2  ON T2(C1);
EXPLAIN SELECT * FROM T2 WHERE C1=10;
1   #NSET2: [0, 250, 156]
2     #PRJT2: [0, 250, 156]; exp_num(5), is_atom(FALSE)
#CSEK2: [0, 250, 156]; scan_type(ASC), IDX_C1_T2(T2), scan_range[10,10]CREATE  INDEX IDX_C1_C2_T1  ON T1(C1,C2);
EXPLAIN SELECT C1,C2 FROM T1;
1   #NSET2: [1, 10000, 60]
2     #PRJT2: [1, 10000, 60]; exp_num(3), is_atom(FALSE)
3       #SSCN: [1, 10000, 60]; IDX_C1_C2_T1(T1)

2.2、嵌套循环连接：

NEST LOOP原理：
两层嵌套循环结构，有驱动表和被驱动表之分。
选定一张表作为驱动表，遍历驱动表中的每一行，根据连接条件去匹配第二张表中的行。驱动表的行数就是循环的次数，这个很大程度影响了执行效率。
需注意的问题：
选择小表作为驱动表。统计信息尽量准确，保证优化器选对驱动表。
大量的随机读。如果没有索引，随机读很致命，每次循环只能读一块，不能读多块。使用索引可以解决这个问题。
使用场景：
驱动表有很好的过滤条件
表连接条件能使用索引
结果集比较小
过滤列和连接列都没有索引，也可以走nest loop，但是该计划很差。右边的计划代价很大。

select /*+use_nl(t1,t2)*/*
from t1 inner join t2 on t1.c1=t2.c1
where t1.c2='A';

优化：创建索引并搜集统计信息

create index idx_t1_c2 on t1(c2);
create index idx_t2_c1 on t2(c1);
dbms_stats.gather_index_stats(user,'IDX_T1_C2');
dbms_stats.gather_index_stats(user,'IDX_T2_C1');

2.3、HASH JOIN：

HASH JOIN的特点：
一般没索引或用不上索引时会使用该连接方式
选择小的表（或row source）做hash表
只适用等值连接中的情形
原理：
使用较小的Row source 作为Hash table和Bitmap. 而第二个row source被hashed，根据bitmap与第一个row source生成的hash table 相匹配，bitmap查找的速度极快。
Hash连接比较消耗内存，如果系统有很多这种连接时，需调整以下3个参数：

 HJ_BUF_GLOBAL_SIZE
HJ_BUF_SIZEHJ_BLK_SIZE

连接列没有索引

select * from t1 inner join t2 on t1.c1=t2.c1
where t1.c2='A';

不是等值连接，此时计划走nest loop

select *  from t1 inner join t2
on t1.c1 > t2.c1
where t1.c2='A';

2.4、归并排序连接：

MERGE SORT的特点：
无驱动表之分，随机读很少
两个表都需要按照连接列排序，需要消耗大量的cpu和额外的内存
应用场景：
通常情况下，merge sort join需要消耗大量的cpu和内存，效率都不会太高。如果存在相关索引可以消除sort，那么CBO可能会考虑该连接方式。

select /*+use_merge(t1 t2)*/t1.c1,t2.c1
from t1 inner join t2 on t1.c1=t2.c1
where t2.c2='b';

–创建如下索引，消除sort

create index idx_t1_c1c2 on t1(c1,c2);
create index idx_t2_c1 on t2(c1);

2.5、查询转换：

什么是查询转换：
查询转换是优化器自动做的，在生成执行计划之前，等价改写查询语句的形式，以便提升效率和产生更好的执行计划。它决定是否重写用户的查询，常见的转换有谓词传递、视图拆分、谓词推进、关联/非关联子查询改写等。
了解优化器查询转换的特性，会帮助我们更好的看懂执行计划，也会对我们优化sql起到指导的作用。优化器的查询转换有很多限制条件，我们可以根据类似的原理举一反三，进行手工的sql改写，从到得到更好的执行计划。
谓词传递：

--原始sql
select * from t1 inner join t2on t1.c2=t2.c2
where t1.c1=100
and t2.c1=t1.c1

–CBO转换后，等价于下面的sql

select * from t1 inner join t2on t1.c2=t2.c2
where t1.c1=100
and t2.c1=t1.c1
and t2.c1=100 –-谓词传递

视图拆分：
观察原始sql的执行计划，发现视图部分的子计划已经没有了。说明优化器进行等价改写，将视图的查询拆散了，和其他部分作为一个整体来生成计划。视图拆分有很多限制，如果视图查询中含有distinc、union、group by等操作，优化器就无法进行视图拆分。
Sql中使用过多的视图，会使sql变得复杂，优化器也难以生成最佳的执行计划，不能过度依赖优化器进行视图拆分。开发时应尽量减少视图的使用。

--视图定义
create or replace view v_t1 as
select t1.c1+t2.c1 as c11,t2.c2,t1.c1
from t1,t2
where t1.c2=t2.c2;--原始sql
select a.c11,b.c2
from v_t1 a,t1 b
where a.c1=b.c1
and a.c1=100;
--原始sql，子查询x相当于一个内联视图
select * from
(select c1,c2 from t1 where c2='C') x
where c1=100;

观察右边的执行计划，由于C2字段无索引，子查询X部分本应该走全表扫描，但是计划中却走了C1字段的索引。说明优化器对原始sql做了如下的等价改写，将条件c1=100推到子查询X中：
–查询转换

select * from
(select c1,c2 from t1 where c2='C'  and c1=100) x;

三、DM8统计信息和索引详情：

3.1、统计信息：

两种统计方式：
**频率直方图：**适用于取值范围比较少的列，例如有些字段的取值范围非常有限，比如人类的年龄，一般不可能超过120，因此无论表中有多少记录，年龄字段的唯一值个数都不会超过120，我们可以采样部分记录，统计出每个年龄（0-120）的记录数，可以使用120个（V, count）二元组作为元素的数组，来表示这个频率直方图。
**等高直方图：**频率直方图虽然精确，但是它只能处理取值范围较小的情况，如果字段的取值范围很大，那么就不可能为每一个值统计出它的出现次数，这个时候我们需要等高直方图。等高直方图是针对一个数据集合不同值个数很多的情况，把数据集合划分为若干个记录数相同或相近的不同区间，并记录区间的不同值个数。每个区间的记录数比较接近，这就是所谓等高的含义。

--构造测试环境
CREATE TABLE TEST_TJ(ID INT,AGE INT);
BEGIN    FOR I IN 1..100000 LOOPINSERT INTO TEST_TJ VALUES(MOD(I,9700),TRUNC(RAND * 120));END LOOP;COMMIT;
END;

–创建系统包

SP_CREATE_SYSTEM_PACKAGES(1);

–更新单列统计信息

DBMS_STATS.GATHER_TABLE_STATS(USER, 'TEST_TJ',null,100,false, 'FOR ALL COLUMNS SIZE AUTO'); --更新所有列
SP_COL_STAT_INIT_EX(USER,'TEST_TJ','ID',100); --更新单列

–查看统计信息：频率直方图

 DBMS_STATS.COLUMN_STATS_SHOW(USER, 'TEST_TJ','AGE');
--1.类型：频率直方图
--2.ENDPOINT_VALUE样本值： 1
--3.ENDPOINT_HEIGHT 样本值的个数:819
SELECT COUNT(*) FROM TEST_TJ WHERE AGE=1; --819

–查看统计信息：等高直方图
DBMS_STATS.COLUMN_STATS_SHOW(USER, ‘TEST_TJ’,‘ID’);
–解读统计信息
–1.类型：等高直方图
–2.ENDPOINT_VALUE样本值： 30
–3.ENDPOINT_HEIGHT小于样本值大于前一个样本值的个数:329
SELECT COUNT() FROM TEST_TJ WHERE ID<30; --329
–4.ENDPOINT_KEYGHT样本值的个数:11
SELECT COUNT() FROM TEST_TJ WHERE ID=30; --11
–5.ENDPOINT_DISTINCT小于样本值大于前一个样本值之间不同样本的个数: 30
SELECT COUNT(DISTINCT ID) FROM TEST_TJ WHERE ID<30; --30

3.2、索引存储结构：

最常见的索引结构为Btree索引，下图是一个B树索引存储结构图。
B*树相关概念：

根节点
内节点
叶子节点
树高度h
聚集索引：
叶子节点存储的是数据块
非聚集索引：

叶子节点存储的是主键值或聚集索引的值或rowid

从B树中访问每个叶子节点的成本都是h次IO，索引的访问效率只跟B树的高度有关系。

  创建表 插入100万条数据CREATE TABLE TEST_INDEX(ID INT,AGE INT);BEGINFOR I IN 1..1000000 LOOPINSERT INTO TEST_INDEX VALUES(MOD(I,9700),TRUNC(RAND * 120));
END LOOP;
COMMIT;END;

–创建索引
CREATE INDEX IDX_ID_TEST_INDEX ON TEST_INDEX(ID);
–更新索引统计信息
SP_INDEX_STAT_INIT(USER,‘IDX_ID_TEST_INDEX’);
–查看索引相关信息

SELECT B.NAME,A.T_TOTAL,    --表总行数A.BLEVEL+1 HEIGHT,   --索引高度A.N_LEAF_USED_PAGES, --叶子节点数INDEX_USED_PAGES(B.ID)-A.N_LEAF_USED_PAGES-1 BRANCH_PAGES –内节点数
FROM SYSSTATS A,SYSOBJECTS B
WHERE  A.ID=B.ID
AND B.NAME IN('IDX_ID_TEST_INDEX');

在什么情况下使用B*树索引？
仅当要通过索引访问表中很少的一部分行（1%~20%）
索引用于访问表中的行（只占一个很小的百分比）
如果要处理表中的多行，而且可以使用索引而不用表
索引用于回答一个查询：索引提供了足够的信息来回答整个查询，不需要去访问表
索引可以作为一个“较瘦”版本的表
原则1：根据索引查询只返回很少一部分行
原则2：索引作为一个较瘦版本的表
组合索引列的顺序：
最优先把等值匹配的列放最前面，范围匹配的放后面
其次把过滤性好的列放前面，过滤性差的放后面
查询时组合索引只能利用一个非等值字段
不走索引的情况：
条件列不是索引的首列
条件列上有函数或计算
存在隐式类型转换
如果走索引会更慢
没有更新统计信息
注意：索引能提高查询性能，也能拖慢DML的效率。
更多达梦技术分享尽在：https://eco.dameng.com/

达梦数据库基础优化分享相关推荐

java获取达梦数据库_记一次对达梦数据库的优化过程
某年某月某日的一个下午,接收到监控服务器的一条告警短信: 尊敬的运维工程师 XX,你好: "192.168.136.200"数据库服务器 CPU 异常,CPU 使用率 98.7%, ...
C#连接达梦数据库基础功公共类
c#程序访问达梦数据库 1.准备数据库驱动达梦数据库安装完成后路径一般为:C:\dmdbms 找到 C:\dmdbms\drivers\dotNet\DmProvider: 我选择为.net 4. ...
达梦数据库基础2-数据库实例(Linux)
目录创建实例查看进程管理工具编辑启动和停止图形界面工具命令工具前面完成数据库完成后,接下来我们需要创建数据库实例.我们继续使用图形工具来操作,和上一文章类似. xhost + ech ...
达梦数据库基础知识（十一）管理分区表和分区索引
在大型的企业应用或企业级的数据库应用中,要处理的数据量通常达到TB级,对于这样的大型表执行全表扫描或者DML操作时,效率是非常低的. 为了提高数据库在大数据量读写操作和查询时的效率,达梦数据库提供了对 ...
达梦数据库DCA培训分享
写这篇文章的目的是为了把学到的新知识做个总结梳理,同时我也希望在学习的过程中把一些需要注意的细节和大家分享.在接触达梦数据库之前,我从来没有用过国产数据库,以往用的都是oracle,mysql等数据库 ...
达梦数据库基础学习记录及DCA考试注意点
达梦数据库介绍面对国外数据库厂商垄断中国市场的局面, 达梦怀揣着自主研发中国数据库的梦想, 致力开发具有自主版权的数据库软件.从第一代数据库产品DM1到第七代DM7, 在长达十余年的市场推广中, 达 ...
达梦数据库基础知识（四）管理DM线程
达梦数据库使用"对称服务器构架"的单进程.多线程结构.这种对称服务器构架在有效地利用了系统资源的同时又提供了较高的可伸缩性能,这里所指的线程即为操作系统的线程.服务器在运行时由各种 ...
零基础小白浅谈达梦数据库DCA考级分享
背景介绍: 本人计算机相关专业毕业,有虚拟机操作经验,未接触过linux系统,有SQL语言基础,属于培训能听懂,实际应用灵活度欠缺类型.此次考试对我而言,挑战很大. 考级是线上培训三天,因培训是正常上 ...
达梦数据库-SQL优化之HINT-平坦化处理
1.HINT之OUTER_JOIN_FLATING_FLAG (1).解释: Flag of indicating whether outer join will be flattened. 对左外连 ...
达梦数据库基础知识（五）安全用户管理之“三权分立”
为了保证数据库系统的安全性,DM数据库采用"三权分立"或"四权分立"的安全机制,"三权分立"时系统内置三种系统管理员,包括数据库管理员.数据 ...

达梦数据库基础优化分享