点滴学习第1篇：CentOS Stream 9环境下部署达梦8数据库
点滴学习第2篇：达梦数据库不更改SQL语句而改变其执行计划
“数据库突然卡顿，CPU飙升到90%，用户投诉不断，你却连问题出在哪儿都不知道？”
“明明硬件配置豪华，但查询性能像过山车，时快时慢，毫无规律可循？”
“日志里风平浪静，但业务系统却频频超时——难道数据库在‘演戏’？”
如果你是一名DBA或运维工程师，以上场景一定不陌生。
问题的答案，就藏在达梦数据库的“性能统计信息”中。它如同孙悟空的火眼金睛，能穿透表象，直击性能瓶颈的核心！
一、原理揭秘：性能统计信息是如何“炼成”的？
1. 数据采集：数据库的“心跳监测仪”
达梦数据库通过"内存级实时采样"技术，持续收集四大核心数据：
会话活动：谁在连接？执行什么SQL？是否空闲？
资源消耗：CPU、内存、磁盘I/O被哪些操作“吃掉”？
对象访问：哪些表、索引是“热点”？读写频率如何？
锁与事务：是否存在锁冲突？长事务是否拖垮性能？
这些数据以"动态表"形式暂存在内存中，通过`V$视图`对外暴露。DBA无需停机，即可实时获取数据库的“生命体征”。
2. 数据存储：轻量高效，毫秒级响应
内存优先：性能数据优先存储在内存中，确保查询效率（响应时间<10ms）。
持久化兜底：关键数据（如SQL执行历史）定期转储到系统表（如`V$SQL_HISTORY`），支持长期趋势分析。
3.设计优势：
零侵入性：不修改业务代码，对数据库性能影响<1%。
全景覆盖：从连接会话到硬件资源，从SQL执行到锁竞争，360°无死角监控。
二、视图分类：四大神器，直击性能痛点
达梦数据库的`V$视图`分为四类，如同四把“手术刀”，精准解剖性能问题。
1. 会话监控：揪出“捣蛋鬼”会话
会话信息包括连接信息、会话信息；涉及的动态视图有v$connect、v$stmts、v$sessions等。
场景应用：
深夜CPU报警：快速定位消耗CPU最高的会话，终止恶意操作。
连接数暴涨：分析`V$SESSIONS`中的异常IP和用户，封禁非法访问。
查看会话信息，SQL语句如下 。
SELECT sess_id,sql_text,state,create_time,clnt_host FROM v$sessions;
2. SQL分析：抓住“慢查询真凶”
SQL历史信息、SQL执行节点历史信息、SQL节点信；涉及的动态视图有v$sql_history、v$sql_node_history、v$sql_node_name等。
场景应用：
接口超时：找出TOP 5耗时SQL，针对性优化索引或改写逻辑。
执行计划突变：对比历史执行计划，发现索引失效或统计信息过期。
查看系统执行的SQL历史信息，SQL语句如下。
SELECT sess_id,top_sql_text,time_used,exec_id FROM v$sql_history;
通过视图v$sql_node_name与v$sql_node_history查询执行节点所花费时间，SQL语句如下。
SELECT n.name,time_used,n_enter FROM v$sql_node_name n,v$sql_node_history h WHERE n.type$=h.type$ AND exec_id=8623;
3. 资源统计：锁定“资源黑洞”
内存管理信息包括内存池使用情况、Buffer缓冲区信息等。涉及的动态视图有v$bufferpool、v$vpool等。
场景应用：
内存泄漏：监控各内存池的增长趋势，发现异常分配。
磁盘过载：通过找到高频访问文件，拆分热点表或迁移存储。
查看内存池BUFFERPOOL的页数、读取页数和命中率信息，SQL语句如下。
SELECT name,n_pages,n_logic_reads,rat_hit FROM v$bufferpool;
4. 锁追踪：破解“死锁迷局”
事务信息包括所有事务信息、当前事务可见的事务信息、事务锁信息等。涉及的动态视图有v$trx、v$trxwait、v$lock等。
场景应用：
死锁报警：通过`V$LOCK`定位阻塞会话，强制回滚或调整事务隔离级别。
长事务堆积：利用`V$TRX`找出运行超时的事务，优化业务逻辑。
查看系统中上锁的事务、锁类型，以及表的ID信息，SQL语句如下。
SELECT trx_id,ltype,lmode,table_id FROM v$lock;
三、实战案例：从报警到优化的全链路诊断
案例背景
某业务系统在交易日高峰期，资金划转接口超时率飙升，数据库CPU使用率突破95%。
第1步：全局扫描，锁定病灶
查询超过执行时间阈值的 SQL 语句
可通过查询 V$LONG_EXEC_SQLS 系统视图获取结果：
SELECT * FROM V$LONG_EXEC_SQLS;
第2步：解剖SQL，找到病根
使用 explain 命令查看执行计划执行计划是 SQL 语句的执行方式，由查询优化器为语句设计的执行方式，交给执行器去执行。在 SQL 命令行使用 EXPLAIN 可以打印出语句的执行计划。
结论：SQL通过全表扫描，未使用主键索引。
第3步：精准手术，药到病除
优化措施：为字段添加唯一索引。
效果验证：
SQL执行时间从8秒降至0.05秒。
CPU使用率回落至30%，超时投诉归零。
四、总结：DBA的“三重境界”
1. 第一重：救火队员（被动响应报警） → 知道数据库“病了”。
2. 第二重：数据侦探（主动分析V$视图） → 诊断出是“索引缺失”还是“锁竞争”。
3. 第三重：架构先知（设计预防性方案） → 通过历史统计预测瓶颈，防患未然。
“不懂性能统计信息的DBA，就像没有雷达的飞行员——全靠运气飞行！”
五、参考信息
2、动态管理和性能视图
https://eco.dameng.com/document/dm/zh-cn/pm/dynamic-management.html
3、达梦数据库事务管理
https://eco.dameng.com/community/post/2022122809412803SPUBP93W2KI8S9J1
4、达梦数据库锁机制
https://blog.csdn.net/southekaer/article/details/136341108
5、附录 2 动态性能视图
https://eco.dameng.com/document/dm/zh-cn/pm/dm8-admin-manual-appendix2.html
