1. 项目概述
最近在整理公司数据仓库项目时，发现很多同事对DM数据库的SQL查询掌握程度参差不齐。有些简单的统计需求要反复沟通，而复杂的分析场景又经常需要DBA介入。于是我把这些年积累的DM数据库查询经验整理成8个典型场景，从最基础的增删改查到复杂的分析函数应用，覆盖了日常开发90%的需求。
DM数据库作为国产数据库的代表作之一，在企业级应用中越来越常见。它兼容标准SQL语法，同时又有自己的特色函数和优化特性。掌握好这些查询技巧，不仅能提高开发效率，还能避免很多性能问题。下面我就从实际案例出发，分享这些经过实战检验的SQL写法。
2. 基础查询场景解析
2.1 多条件精确查询
在用户管理系统中，经常需要根据多个条件精确查找记录。比如查找部门为"研发部"且入职满3年的员工：
sql复制SELECT emp_name, emp_id, hire_date
FROM employees
WHERE dept_name = '研发部'
AND DATEDIFF(YEAR, hire_date, CURRENT_DATE) >= 3
ORDER BY hire_date DESC;
这里有几个注意点：
- DM的DATEDIFF函数第一个参数支持YEAR/MONTH/DAY等单位
- 字符串比较默认区分大小写，可以用UPPER()函数统一格式
- 建议为dept_name和hire_date字段建立复合索引
2.2 模糊查询与通配符技巧
产品搜索功能常用到模糊查询。比如查找名称包含"服务器"且型号以"DL3"开头的产品：
sql复制SELECT product_id, product_name, model
FROM products
WHERE product_name LIKE '%服务器%'
AND model LIKE 'DL3%'
AND status = '在售';
重要提示：前导通配符(%在前)会导致索引失效，建议对model字段建立函数索引：
sql复制CREATE INDEX idx_model_prefix ON products(SUBSTR(model,1,3));
3. 中级查询场景实战
3.1 分组统计与HAVING筛选
每月统计销售额超过100万的商品：
sql复制SELECT
product_id,
product_name,
SUM(amount) AS total_sales,
COUNT(*) AS order_count
FROM sales
WHERE sale_date BETWEEN '2023-01-01' AND '2023-01-31'
GROUP BY product_id, product_name
HAVING SUM(amount) > 1000000
ORDER BY total_sales DESC;
常见问题：
- GROUP BY子句必须包含所有非聚合列
- WHERE在分组前过滤，HAVING在分组后过滤
- 大数据量时考虑先按日期分区再查询
3.2 多表连接查询优化
查询订单详情带客户和产品信息：
sql复制SELECT
o.order_id,
o.order_date,
c.customer_name,
p.product_name,
oi.quantity,
oi.unit_price
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE o.order_date >= DATEADD(MONTH, -3, CURRENT_DATE)
ORDER BY o.order_date DESC;
性能优化建议：
- 确保连接字段都有索引
- 大表连接时把过滤条件写在最前面
- 考虑使用/*+ LEADING */提示指定连接顺序
4. 高级分析场景实现
4.1 窗口函数应用
计算员工薪资部门排名及与平均薪资差异：
sql复制SELECT
emp_name,
dept_name,
salary,
RANK() OVER(PARTITION BY dept_name ORDER BY salary DESC) AS dept_rank,
salary - AVG(salary) OVER(PARTITION BY dept_name) AS diff_from_avg
FROM employees
WHERE status = '在职';
窗口函数要点：
- PARTITION BY类似GROUP BY但不减少行数
- ORDER BY决定计算顺序
- 支持ROWS/RANGE定义窗口范围
4.2 递归查询处理层级数据
查询部门完整层级路径：
sql复制WITH RECURSIVE dept_path AS (
-- 基础查询：获取顶级部门
SELECT
dept_id,
dept_name,
parent_id,
dept_name AS path
FROM departments
WHERE parent_id IS NULL
UNION ALL
-- 递归查询：连接子部门
SELECT
d.dept_id,
d.dept_name,
d.parent_id,
dp.path || ' > ' || d.dept_name
FROM departments d
JOIN dept_path dp ON d.parent_id = dp.dept_id
)
SELECT * FROM dept_path
ORDER BY path;
递归CTE使用注意事项：
- 必须包含UNION ALL
- 递归部分必须引用CTE自身
- 注意设置MAXRECURSION防止无限循环
5. 性能优化专项技巧
5.1 执行计划解读与优化
使用EXPLAIN分析慢查询：
sql复制EXPLAIN
SELECT * FROM orders
WHERE customer_id IN (
SELECT customer_id FROM customers
WHERE region = '华东'
)
AND order_date > '2023-01-01';
常见执行计划问题：
- 全表扫描(TABLE SCAN)：考虑添加索引
- 低效连接(NESTED LOOP)：检查连接条件索引
- 临时表排序(FILESORT)：优化ORDER BY/GROUP BY
5.2 索引策略实战建议
建立复合索引的最佳实践：
sql复制-- 好的复合索引示例
CREATE INDEX idx_orders_composite ON orders(customer_id, order_date DESC);
-- 查询可以充分利用索引
SELECT * FROM orders
WHERE customer_id = 1001
ORDER BY order_date DESC;
索引设计原则：
- 高选择性的列放在前面
- 经常一起查询的列建复合索引
- ORDER BY/DISTINCT考虑索引排序方向
- 避免过度索引影响写入性能
6. 特殊场景处理方案
6.1 分页查询优化
大数据量下的高效分页：
sql复制-- 传统分页(性能差)
SELECT * FROM large_table
ORDER BY create_time DESC
OFFSET 10000 LIMIT 20;
-- 优化方案：键集分页
SELECT * FROM large_table
WHERE create_time < '2023-06-01' -- 上一页最后一条的时间
ORDER BY create_time DESC
LIMIT 20;
分页优化要点：
- 避免大偏移量(OFFSET)
- 使用有索引的排序列
- 考虑使用游标分页
6.2 批量更新与事务控制
安全高效的批量更新：
sql复制BEGIN TRANSACTION;
-- 第一步：备份重要数据
CREATE TEMP TABLE backup_products AS
SELECT * FROM products WHERE category = '电子产品';
-- 第二步：执行更新
UPDATE products
SET price = price * 0.9
WHERE category = '电子产品'
AND stock_quantity > 100;
-- 第三步：验证影响行数
SELECT ROW_COUNT() AS updated_rows;
-- 确认无误后提交
COMMIT;
事务最佳实践：
- 明确的事务边界(BEGIN/COMMIT)
- 关键操作前备份数据
- 验证影响范围后再提交
- 设置合理的隔离级别
7. 常见问题排查指南
7.1 锁等待超时处理
识别和解决锁冲突：
sql复制-- 查看当前锁等待情况
SELECT * FROM sys.dm_tran_locks
WHERE request_status = 'WAIT';
-- 终止阻塞会话(谨慎使用)
KILL <session_id>;
锁问题排查步骤：
- 通过系统视图定位阻塞源头
- 分析事务设计和隔离级别
- 优化长事务和锁粒度
- 考虑使用乐观并发控制
7.2 查询性能突然下降
性能回退排查方法：
sql复制-- 检查统计信息是否过期
ANALYZE TABLE orders COMPUTE STATISTICS;
-- 查看最近执行计划变化
SELECT * FROM sys.dm_exec_query_stats
WHERE query_hash IN (
SELECT query_hash FROM sys.dm_exec_requests
WHERE session_id = <problem_session>
);
性能波动常见原因：
- 统计信息过时
- 执行计划变更
- 资源竞争加剧
- 数据量临界点突破
8. 最佳实践总结
经过这些年的DM数据库使用，我总结了几个关键经验：
-
索引不是越多越好：每个额外索引都会增加写入开销，定期评估索引使用率，删除冗余索引。
-
理解执行计划：学会阅读EXPLAIN输出是性能调优的基本功，要能识别全表扫描、低效连接等危险信号。
-
批量操作优于循环：能用一条SQL完成的工作，不要拆分成多次数据库访问。
-
事务要短小精悍：长时间运行的事务会锁定资源，影响并发性能。
-
适当使用提示(HINT)：当优化器选择不理想时，可以用/*+ INDEX */等提示引导执行计划。
最后分享一个实用技巧：DM数据库的DBMS_OUTPUT包可以用于调试复杂SQL：
sql复制BEGIN
DBMS_OUTPUT.PUT_LINE('开始处理数据');
-- 你的SQL逻辑
DBMS_OUTPUT.PUT_LINE('处理完成，影响行数：' || SQL%ROWCOUNT);
END;