数以亿计的数据记录优化查询(转)

简介: 4亿多条数据不可怕,问题是你的数据量是多少,如果是OLTP的话,一天百万条数据,1个月也能到这个数据的,而且听你说只跑报表的吗 呵呵,80%的问题在SQL上,好好优化一下报表的SQL。分析数据库应用的特点,将那些重要的表、系统过程列出来,重点分析。

4亿多条数据不可怕,问题是你的数据量是多少,如果是OLTP的话,一天百万条数据,1个月也能到这个数据的,而且听你说只跑报表的吗

呵呵,80%的问题在SQL上,好好优化一下报表的SQL。<br /><br />分析数据库应用的特点,将那些重要的表、系统过程列出来,重点分析。

1、数据量大的表

2、运行频繁的系统过程、触发器;用 sp_depends 数据量大的表查找

3、用户容易报告慢的界面相关的系统过程。

由于系统过程的 TXT 文本大约有2M,一个个看是不可能的,因此需要做这些工作。

首先,有一句话要认识 : 80%的性能问题由SQL语句引起。 经过看 SYBASE 的书,结合从 MSSQL 迁移过来的系统过程 ,发现以下几个问题比较重要:

经验一、where 条件左边最好不要使用函数,比如 select ... where datediff(day,date1,getdate())  这样即使在 date1 列上建立了索引,也可能不会使用索引,而使用表扫描。 这样的语句要重新规划设计,保证不使用函数也能够实现。通过修改,一个系统过程的运行效率提高大约100倍!

经验二、两个比较字段最好使用相同数据类型,而不是兼容数据类型。比如 int 与 numeric(感觉一般不是太明显)

经验三、复合索引的非前导列做条件时,基本没有起到索引的作用。

比如 create index idx_tablename_ab on tablename(a, b)  update tablename set c = XX where b= XXX and ... 在这个语句中,基本上索引没有发挥作用。 导致表扫描引起blocking 甚至运行十几分钟后报告失败。 一定要认真检查 改正措施: 在接口中附加条件 update tablename set c = XX where a = XXX and b= XXX  或者建立索引类似于create index idx_tablename_ba on tablename(b,a)

经验四、 多个大表的关联查询,如果性能不好,并且其中一个大表中取的数据比较少,可以考虑将查询分两步执行。先将一个大表中的少部分数据 select * into #1 from largetable1 where ... 然后再用 #1 去做关联,效果可能会好不少。(前提:生成 #1表应该使用比较好的索引,速度比较快) 

经验五、 tempdb 的使用。

最好多用 select into ,这样不记日志 ,尤其是有大量数据的报表时。虽然写起来麻烦,但值得。 create table #tmp1 (......)这样写性能不好。尤其是大量使用时,容易发生tempdb 争用。

经验六、 系统级别的参数设置 

一定要估计一下,不要使用太多,占用资源 ,太少,发生性能问题。 连接数,索引打开个数、锁个数 等、 当然 ,内存配置不要有明显的问题,比如,procedure cache  不够 (一般缺省20%,如果觉得太多,可以减少一些)。如果做报表经常使用大数据量读,可以考虑使用  16Kdata cache

经验七、索引的建立。很重要。

clustered index /nonclustered index 的差异,自己要搞清楚。各适用场合,另外如果 clustered index 不允许 重复数,也一定要说明。 索引设计是以为数据访问快速为原则的,不能 完全参照数据逻辑设计的,逻辑设计时的一些东西,可能对物理访问不起作用

经验八、统计数据的更新:大约10天进行 update statistics ,sp_recompile table_name

经验九、强制索引使用

如果怀疑有表访问时不是使用索引,而且这些条件字段上建立了合适的索引,可以强制使用  select * from tableA (index idx_name) where ... 这个对一些报表程序可能比较有用。

经验十、找一个好的监视工具

工欲善其事,比先利其器,一点都不错呀。我用 DBartisian 5.4 ,监视哪些表被锁定时间长, blocking 等还有 sp_object_status 20:00:00 , sp_sysmon 20:00:00 等以上是我的一点经验,在不到一个月的时间内,我修改了20个左右的语句和系统过程 ,系统性能明显改善,cpu利用 高峰时大约50% 平时 不到30%IO 明显改善。所有月报表能顺利完成 5min 以内。 另外,系统中确认不使用的中间数据,可以进行转移。这些要看系统的情况哦 最后祝你好运气。 以上为个人经验,欢迎批评指正!

呵呵 写完后忘记一个 一定要注意热点表 ,这是影响并发问题的一个潜在因素。

解决方法: 行锁模式 如果表的行比较小,可以故意增加一些不用的字段,比如 char(200) 让一页中存放的行不要太多。

相关文章
|
存储 缓存 算法
【OSTEP】分页: 快速地址转换(TLB) | TLB命中处理 | ASID 与页共享 | TLB替换策略: LRU策略与随机策略 | Culler定律
【OSTEP】分页: 快速地址转换(TLB) | TLB命中处理 | ASID 与页共享 | TLB替换策略: LRU策略与随机策略 | Culler定律
776 0
|
7月前
|
网络协议 安全
说一下 TCP 的三次握手四次挥手过程
我是小假 期待与你的下一次相遇 ~
707 1
|
10月前
|
Java API 开发工具
蚂蚁百宝箱 ✖️ 调用对话型智能体
通过调用本接口,开发者可以向指定智能体发起对话,支持在对话时添加上下文消息,便于智能体做出合理的回复。
350 0
|
7月前
|
机器学习/深度学习 运维 监控
基于 YOLOv8 的高压输电线路(绝缘子、电缆)故障自动识别 [目标检测完整源码]
本文介绍基于YOLOv8的高压输电线路故障智能识别系统,融合深度学习与可视化技术,实现电缆破损、绝缘子损坏、植被遮挡等典型缺陷的自动检测。系统采用PyQt5构建友好界面,支持图片、视频及实时流输入,具备高效、准确、易用特点,适用于无人机巡检与在线监控,助力电力运维智能化升级。
423 9
基于 YOLOv8 的高压输电线路(绝缘子、电缆)故障自动识别 [目标检测完整源码]
|
5月前
|
人工智能 Linux API
阿里云/本地部署 OpenClaw 全场景实战:从早报到知识库,8类自动化工作流完整配置指南
在日常工作与生活中,大量“简单但繁琐、重复又耗时”的事务不断消耗精力:整理文件、筛选资讯、收发邮件、管理日程、追踪动态、发布内容、设置提醒、沉淀知识。OpenClaw作为轻量化AI智能体平台,无需编程基础,即可通过技能与定时任务,全自动处理以上事务。本文通过8个可直接落地的真实场景,完整讲解配置方法、代码命令与使用效果,同时提供2026年阿里云云端部署、MacOS/Linux/Windows11本地部署流程,以及阿里云千问大模型API与免费Coding Plan API的完整配置方案,搭配常见问题解答,让普通人也能快速拥有7×24小时的AI助手,真正实现效率提升。
1678 0
|
6月前
|
人工智能 自然语言处理 网络协议
2026年阿里云轻量服务器部署OpenClaw(Clawdbot)新手喂饭教程(零代码+全图解)
2026年,OpenClaw(前身为Clawdbot、Moltbot)凭借“自然语言指令+任务自动化执行”的核心优势,成为新手入门AI自动化的首选工具。这款开源AI代理平台无需专业编程基础,仅需输入日常口语化指令,就能完成文件处理、日程管理、多工具协同、代码生成等重复性工作,堪称“私人AI数字员工”。
834 7
|
前端开发
防抖和节流的区别,实现和用处。
防抖和节流是优化高频事件处理的两种技术。防抖确保在一系列连续事件后仅执行最后一次操作,如搜索输入完成后再发送请求;节流则保证在设定时间内仅执行一次操作,适用于滚动加载等场景。两者通过限制回调函数的执行频率,有效提升前端性能。示例代码展示了如何实现这两种技术。
879 2
十分钟了解阿里云数据库RDS
简介:阿里云关系型数据库(Relational Database Service,简称RDS)是一种稳定可靠、可弹性伸缩的在线数据库服务。基于阿里云分布式文件系统和SSD盘高性能存储,RDS支持MySQL、SQL Server、PostgreSQL、PPAS(Postgre Plus Advanced Server,高度兼容Oracle数据库)和MariaDB TX引擎,并且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。
13442 0
|
监控 Java 数据库连接
阿里云ads常见问题
【8月更文挑战第10天】
796 1
|
人工智能 小程序 搜索推荐
餐饮类小程序开发定制需要多少钱,费用是怎样的
餐饮小程序开发费用因需求、规模和复杂性而异。基础版约几千到万元,含菜品展示、在线点餐等功能;界面设计费几千到几万;服务器租赁年费几千到几万;维护更新费同水平。总成本通常在几万到几十万之间。选择开发商时要考虑实际需求、合同条款及付款方式。

热门文章

最新文章