查询速度慢

baidu_35931093 2017-07-14 04:07:15


求大神解惑,百度了一些答案也没啥用,100多行花了12秒。


DBCC SHOWCONTIG 正在扫描 'hd_sqly' 表...
表: 'hd_sqly'(328492349);索引 ID: 1,数据库 ID: 18
已执行 TABLE 级别的扫描。
- 扫描页数.....................................: 117
- 扫描扩展盘区数...............................: 39
- 扩展盘区开关数...............................: 38
- 每个扩展盘区上的平均页数.....................: 3.0
- 扫描密度[最佳值:实际值]....................: 38.46%[15:39]
- 逻辑扫描碎片.................................: 11.97%
- 扩展盘区扫描碎片.............................: 69.23%
- 每页上的平均可用字节数.......................: 1328.4
- 平均页密度(完整)...........................: 83.59%
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。

碎片查出来也还好啊。
...全文
412 5 打赏 收藏 转发到动态 举报
写回复
用AI写文章
5 条回复
切换为时间正序
请发表友善的回复…
发表回复
二月十六 2017-07-14
  • 打赏
  • 举报
回复
能不用函数的就不用函数,这个东西非常耗时
OwenZeng_DBA 2017-07-14
  • 打赏
  • 举报
回复
你对adddate,sqlno desc ,appflage加索引 试试
baidu_35931093 2017-07-14
  • 打赏
  • 举报
回复
问题找到了,是GetSqCkStatus这个函数的效率有些低。
baidu_35931093 2017-07-14
  • 打赏
  • 举报
回复
引用 1 楼 z10843087 的回复:
[quote=引用 楼主 baidu_35931093 的回复:] 求大神解惑,百度了一些答案也没啥用,100多行花了12秒。 DBCC SHOWCONTIG 正在扫描 'hd_sqly' 表... 表: 'hd_sqly'(328492349);索引 ID: 1,数据库 ID: 18 已执行 TABLE 级别的扫描。 - 扫描页数.....................................: 117 - 扫描扩展盘区数...............................: 39 - 扩展盘区开关数...............................: 38 - 每个扩展盘区上的平均页数.....................: 3.0 - 扫描密度[最佳值:实际值]....................: 38.46%[15:39] - 逻辑扫描碎片.................................: 11.97% - 扩展盘区扫描碎片.............................: 69.23% - 每页上的平均可用字节数.......................: 1328.4 - 平均页密度(完整)...........................: 83.59% DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。 碎片查出来也还好啊。
首先,再跑一次查询看看 其次,你表的总行数的多少,是否有合适的索引[/quote] 跑了好几次了,每次都是12秒多。 一共5255行,就对第一列sqno字段列进行了聚集索引。
OwenZeng_DBA 2017-07-14
  • 打赏
  • 举报
回复
引用 楼主 baidu_35931093 的回复:
求大神解惑,百度了一些答案也没啥用,100多行花了12秒。 DBCC SHOWCONTIG 正在扫描 'hd_sqly' 表... 表: 'hd_sqly'(328492349);索引 ID: 1,数据库 ID: 18 已执行 TABLE 级别的扫描。 - 扫描页数.....................................: 117 - 扫描扩展盘区数...............................: 39 - 扩展盘区开关数...............................: 38 - 每个扩展盘区上的平均页数.....................: 3.0 - 扫描密度[最佳值:实际值]....................: 38.46%[15:39] - 逻辑扫描碎片.................................: 11.97% - 扩展盘区扫描碎片.............................: 69.23% - 每页上的平均可用字节数.......................: 1328.4 - 平均页密度(完整)...........................: 83.59% DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。 碎片查出来也还好啊。
首先,再跑一次查询看看 其次,你表的总行数的多少,是否有合适的索引
版本:presto-server-0.214.tar软件版本 presto-cli-0.214-executableCentOS71、presto的起因 hadoop ---hdfs----MR(java)-----hivehive底层原理用MR,速度比较慢,公司hadoop集群主要集中于晚上到凌晨,平日工作时间负载不是很高。但在工作时间内,公司业务人员有实时查询的需求,现在主要借助于hive提供业务人员的查询。hive是基于MR类的SQL查询工具,他会输入的查询SQL解析为MapReduce,能极大的降低使用大数据门槛,让一般的业务人员可以直接准对大数据进行查询,但是有一个利弊,它的查询基于MR,会让人等待比较着急,等待的时间可能是几个小时或者一天。 spark基于内存提高改良的hive,sql,现在factbook在hive上面开发一套利器,准对hive可以通过sql语句快速查询,presto。2、Facebook为何开发Presto  Facebook的2011的数据仓库存储在少量大型hadoopfs集群,Hive是FaceBook在几年前专门为Hadoop打造的一款数据仓库工具,在以前,facebook的科学家和分析师一直靠hive进行数据分析.但hive使用MR作为底层计算框架,是专为批处理设计的,但是随着数据的不断增多,使用hive进行一个简单的数据查询可能要花费分钟或者几个小时,显然不能满足查询需求,FaceBooke也调研了其他比hive更快的工具,但是他们需要在功能有限的条件下做简单操作,以至于无法操作Facebook庞大的数据要求。2012年开始研究自己的框架--presto,每日可以超过1pb查询,而且速度比较快,faceBook声称Presto的性能比hive要好上10倍或者100倍,presto和hive都是facebook开发的 Presto是一个开源的分布式SQL查询引擎,适用于交互式查询,数据量支持GB到PB字节。Presto的设计和编写完全是为了解决Facebook这样规模的商业数据仓库交互式分析和处理速度的问题Presto可以做什么 Presto支持在线数据查询,包括Hive kafka Cassandra关系数据库以及专门数据存储,一条Presto查询可以将多个数据源进行合并,可以跨越整个组织进行分析。Presto以分析师的需求作为目标,他们期望相应速度小于1秒到几分钟,Presto要么在使用速度的快的昂贵的商业方案,提高内存,要么是消耗大量的硬件进行快速查询。(128G 64G)本套课程教给如何在企业环境中使用Presto技术。

11,849

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 非技术版
社区管理员
  • 非技术版社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧