【产品名称】
【产品版本】
【问题描述】为什么session级别修改变量是DML？
没理解什么意思，可以详细描述下问题吗
1 个赞
罗列SQL吧，问问题还是说清楚一点，大家才能回答
1 个赞
哪里说的session级别修改变量是DML呢吗，有链接可以参考下吗
不管是session 级别 还global级别 既不是DML操作 也不是DDL操作 ，他们都属于DCL操作
1 个赞
没理解什么意思，可以详细描述下问题吗
1 个赞
这是考试的题目么？
2 个赞
哈哈，肯定不是考试题目，不过确实是一个有意思的问题。
用户的问题是说为什么修改 session 级别的系统变量是 DML，而修改 global 级别的系统变量却属于 DDL？其他数据库，例如 Oracle 啥的好像也是这样判定的。
例如：
-- 这条 SQL 是 DML
set ob_query_timeout = 12345678;
-- 而这条 SQL 是 DDL
set global ob_query_timeout = 12345678;
之前没细想这个问题，不过前两天刚好回答了另外一个用户的类似问题，详见： 如何设置永久ob_query_timeout，受了一些启发。
个人猜测是因为修改 global 级别的系统变量，流程和执行 DDL 一样，需要向持久化存储数据库对象元数据信息的系统表中写入相关变更，所以被各类数据库都判定成 DDL 了。
而设置 session 级别的系统变量，只是在临时的 session info 上修改了一些东西，不改元数据表，所以没被判定为 DDL，而是 DML。
纯属个人瞎猜，不代表 OB 的真实判定逻辑。
哈哈，修改 global 级别的系统变量还真是 DDL，而且还受 ddl 超时时间的控制~
DCL 的执行流程和 DDL 有点儿像，不过一般和权限相关，所以修改 session 级别的系统变量也不是 DCL~
1 个赞
您的问题可能存在误解，实际上据我所知：
根据文档库中的信息，在 OceanBase 数据库中，修改系统变量（无论是全局还是会话级别）的操作并不属于 DML（数据操作语言）或 DDL（数据定义语言）。这些命令用于设置控制数据库行为的参数，而不是直接对表中的数据进行增删改查或者对数据库结构进行变更。
具体来说：
- Session 变量：当您在会话中设置一个变量时，这只是一个临时性的更改，仅影响当前连接，并且不会持久化。它只是改变了当前会话上下文中的某些属性值，因此不属于 DDL 或 DML。
- Global 变量：当您设置全局变量时，这种改变会影响到所有新的会话（现有会话不受影响），并且通常需要管理员权限。尽管它看起来像是对数据库配置的一种“定义”，但它也不是严格意义上的 DDL 操作，因为它并没有创建、删除或修改数据库对象如表、索引等。
所以，正确理解应该是：在 OceanBase 中，SET 命令用于调整系统变量的行为，但它们既不是 DDL 也不是 DML。如果您看到其他地方将此类操作归类为 DDL 或 DML，请注意那可能是特定实现下的特殊定义或者是误解。
如果还有疑问，欢迎继续讨论！
具体信息可参考以下文档:
从用户提供的图片和 OCR 提取的文字来看，这个问题是关于为什么在某些数据库系统中，修改 session 级别的系统变量被视为 DML（数据操作语言），而修改 global 级别的系统变量被视为 DDL（数据定义语言）。不过，根据 OceanBase 的文档库中的信息，这种分类并不适用于 OceanBase 数据库。让我详细解释一下：
1. Session 变量的修改
- 作用范围：Session 变量的修改仅影响当前会话，并且不会持久化。它只是改变了当前会话上下文中的某些属性值。
- 持久性：这些更改只在当前会话中有效，一旦会话结束，设置就会恢复到全局默认值或之前的会话级别设置。
- 对数据库结构的影响：修改 session 变量并不会改变数据库的物理结构或元数据，因此不属于 DDL 或 DML。
2. Global 变量的修改
- 作用范围：Global 变量的修改会影响到所有新的会话（现有会话不受影响），并且通常需要管理员权限。
- 持久性：这些更改会持久化，直到再次被修改或数据库重启。
- 对数据库结构的影响：尽管它看起来像是对数据库配置的一种“定义”，但它并不是严格意义上的 DDL 操作，因为它并没有创建、删除或修改数据库对象如表、索引等。
结论
在 OceanBase 数据库中，SET 命令用于调整系统变量的行为，但它们既不是 DDL 也不是 DML。具体来说：
- Session 变量：修改 session 变量的操作只是临时性的，仅影响当前连接，不涉及对数据库结构或元数据的更改，因此不属于 DDL 或 DML。
- Global 变量：修改 global 变量的操作虽然会影响所有新会话，但它也不涉及对数据库结构或元数据的更改，因此同样不属于 DDL 或 DML。
如果其他数据库系统将此类操作归类为 DML 或 DDL，那可能是特定实现下的特殊定义或者是误解。在 OceanBase 中，我们应该正确理解 SET 命令的作用，而不应将其简单地归类为 DML 或 DDL。
如果您有更多问题或需要进一步澄清，请随时提问！
具体信息可参考以下文档:
开源文档里应该没有地方提到这个，回答不出来也正常的。而且，我不认为设置变量是 DDL 或者 DML ，这个属于数据库系统的配置，属于是“元数据”的修改，跟数据的定义和操作还是有直接区别的。
官方论坛ai吗 
之前我有看到社区有另外一个关于 global级别修改变量是DDL 的帖子，感觉可以合并一起讨论。
我浅薄的知识里面，这个变量的设置无论是 session 级别 还是 global 级别应该都没涉及到数据库的操作与定义等，这个问题的本身验证有没有更具体的文档之类可以查阅去辅助验证
哈哈，印象中官方文档里好像提过这个，不过最新版本又找不到了~
很多数据库其实也都是把 set global variable 归类成 DDL 的，同时也会受到和 DDL 相关变量和参数的影响。确实有点儿不好理解，估计是因为实现方式和 DDL 要走同一套路径。
OB 为了兼容这些数据库的行为，也是这样搞的，详见 OB 源码中的这个文件的 L259 的 is_ddl_stmt 函数。
static inline bool is_ddl_stmt(stmt::StmtType stmt_type, bool has_global_variable)
{
return (
stmt_type == stmt::T_CREATE_RESOURCE_POOL
// 略去一大段各类 DDL 的分类
// variable
//目前只有set global variable才是DDL操作，session级别的variable变更不是DDL
|| (stmt_type == stmt::T_VARIABLE_SET && has_global_variable)
);
}
个人觉得这个问题没啥深入研究的必要，代码实现决定行为，看代码中 DDL 的定义就好了。别再花时间去查阅文档和做实验辅助验证了（真要做实验验证倒是也有办法），哈哈~