一个简单sql查询的诡异问题

wea1978 2010-09-15 09:15:56
sql 2000数据库

同样在查询分析器中查询数据结果

语句1(查询表返回数据)

select * from tablenames
order by names

语句2(查询视图返回数据)

select * from view_tablenames
order by names

视图语句
select * from tablenames
order by names

问题来了,,

语句1 和语句2 返回的结果竟然不一样!!!
并且数据都变乱了


这是什么原因造成的呢?

...全文
115 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
wea1978 2010-09-23
  • 打赏
  • 举报
回复
感谢楼上各位,现在还没找到原因,但问题却解决了. 因为在关键字前面加了一个字段,造成这个现象,把那个字段后移,问题就不存在了...
原因呢?
还是没找到....
黑子白子 2010-09-23
  • 打赏
  • 举报
回复
SQL2005的视图建立时,会自动把'*'转换为所有字段名,也许就是因为2000有这个BUG。
楼主试试就用“select names from tablenames”建视图,是否会乱?
claro 2010-09-23
  • 打赏
  • 举报
回复
--try
use 数据库
go
exec sp_refreshview N'视图名'
wea1978 2010-09-23
  • 打赏
  • 举报
回复
数据库是一样的,同一个数据库,创建视图的语句是普通的语句. CREATE VIEW
hao1hao2hao3 2010-09-17
  • 打赏
  • 举报
回复
是不是选择的数据库不同?这样的情况应该是不会的吧!仔细检查看看!

创建视图的语句是怎么写的?
wea1978 2010-09-16
  • 打赏
  • 举报
回复
没有人遇到过这种问题吗?
wea1978 2010-09-15
  • 打赏
  • 举报
回复
呵呵,视图语句放 order by 是不能保存视图的

不好意思,刚才写得匆忙, 连order by 都带上了...
事实上语句1和语句2
都是
select * from tablenames

只不过一个是放在视图里, 但它们的结果却不一致.
csdyyr 2010-09-15
  • 打赏
  • 举报
回复
视图语句明显就不对。
「已注销」 2010-09-15
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 bancxc 的回复:]

试图里边能写 order by names????????????
[/Quote]

他是select出来 orderby的
bancxc 2010-09-15
  • 打赏
  • 举报
回复
试图里边能写 order by names????????????
wea1978 2010-09-15
  • 打赏
  • 举报
回复
视图语句
select * from tablenames
order by names


其实视图语句和 第1个语句是一样的
按理返回的结果肯定是一样,但事实却不一样. 不知道哪里出了问题
bancxc 2010-09-15
  • 打赏
  • 举报
回复
看view_tablenames内容


大数据常见问题之数据倾斜全文共5页,当前为第1页。大数据常见问题之数据倾斜全文共5页,当前为第1页。大数据常见问题之数据倾斜 大数据常见问题之数据倾斜全文共5页,当前为第1页。 大数据常见问题之数据倾斜全文共5页,当前为第1页。 什么是数据倾斜 简单的讲,数据倾斜就是我们在计算数据的时候,数据的分散度不够,导致大量的数据集中到了一台或者几台机器上计算,这些数据的计算速度远远低于平均计算速度,导致整个计算过程过慢。 相信大部分做数据的童鞋们都会遇到数据倾斜,数据倾斜会发生在数据开发的各个环节中,比如: 用Hive算数据的时候reduce阶段卡在99.99% 用SparkStreaming做实时算法时候,一直会有executor出现OOM的错误,但是其余的executor内存使用率却很低。 数据倾斜有一个关键因素是数据量大,可以达到千亿级。 数据倾斜长的表现 以Hadoop和Spark是最常见的两个计算平台,下面就以这两个平台说明: 1、Hadoop中的数据倾斜 Hadoop中直接贴近用户使用使用的时Mapreduce程序和Hive程序,虽说Hive最后也是用MR来执行(至少目前Hive内存计算并不普及),但是毕竟写的内容逻辑区别很大,一个是程序,一个是Sql,因此这里稍作区分。 Hadoop中的数据倾斜主要表现在ruduce阶段卡在99.99%,一直99.99%不能结束。 这里如果详细的看日志或者和监控界面的话会发现: 有一个多几个reduce卡住 各种container报错OOM 读写的数据量极大,至少远远超过其它正常的reduce 伴随着数据倾斜,会出现任务被kill等各种诡异的表现。 经验: Hive的数据倾斜,一般都发生在Sql中Group和On上,而且和数据逻辑绑定比较深。 2、Spark中的数据倾斜 大数据常见问题之数据倾斜全文共5页,当前为第2页。大数据常见问题之数据倾斜全文共5页,当前为第2页。Spark中的数据倾斜也很常见,这里包括Spark Streaming和Spark Sql,表现主要有下面几种: 大数据常见问题之数据倾斜全文共5页,当前为第2页。 大数据常见问题之数据倾斜全文共5页,当前为第2页。 Executor lost,OOM,Shuffle过程出错 Driver OOM 单个Executor执行时间特别久,整体任务卡在某个阶段不能结束 正常运行的任务突然失败 补充一下,在Spark streaming程序中,数据倾斜更容易出现,特别是在程序中包含一些类似sql的join、group这种操作的时候。 因为Spark Streaming程序在运行的时候,我们一般不会分配特别多的内存,因此一旦在这个过程中出现一些数据倾斜,就十分容易造成OOM。 数据倾斜的原理 1、数据倾斜产生的原因 我们以Spark和Hive的使用场景为例。他们在做数据运算的时候会设计到,countdistinct、group by、join等操作,这些都会触发Shuffle动作,一旦触发,所有相同key的值就会拉到一个或几个节点上,就容易发生单点问题。 2、万恶的shuffle Shuffle是一个能产生奇迹的地方,不管是在Spark还是Hadoop中,它们的作用都是至关重要的。那么在Shuffle如何产生了数据倾斜? Hadoop和Spark在Shuffle过程中产生数据倾斜的原理基本类似。如下图。 大数据常见问题之数据倾斜全文共5页,当前为第3页。大数据常见问题之数据倾斜全文共5页,当前为第3页。 大数据常见问题之数据倾斜全文共5页,当前为第3页。 大数据常见问题之数据倾斜全文共5页,当前为第3页。 大部分数据倾斜的原理就类似于下图,很明了,因为数据分布不均匀,导致大量的数据分配到了一个节点。 3、从业务计角度来理解数据倾斜 数据往往和业务是强相关的,业务的场景直接影响到了数据的分布。再举一个例子,比如就说订单场景吧,我们在某一天在北京和上海两个城市多了强力的推广,结果可能是这两个城市的订单量增长了10000%,其余城市的数据量不变。然后我们要统计不同城市的订单情况,这样,一做group操作,可能直接就数据倾斜了。 如何解决 数据倾斜的产生是有一些讨论的,解决它们也是有一些讨论的,本章会先给出几个解决数据倾斜的思路,然后对Hadoop和Spark分别给出一些解决数据倾斜的方案。 一、几个思路 解决数据倾斜有这几个思路: 1.业务逻辑,我们从业务逻辑的层面上来优化数据倾斜,比如上面的例子,我们单独对这两个城市来做count,最后和其它城市做整合。 大数据常见问题之数据倾斜全文共5页,当前为第4页。大数据常见问题之数据倾斜全文共5页,当前为第4页。2.程序层面,比如说在Hive中,经常遇到count(distinct)操作,这样会
⼤数据常见问题之数据倾斜 什么是数据倾斜 简单的讲,数据倾斜就是我们在计算数据的时候,数据的分散度不够,导致⼤量的数据集中到了⼀台或者⼏台机器上计算,这些数据的计 算速度远远低于平均计算速度,导致整个计算过程过慢。 相信⼤部分做数据的童鞋们都会遇到数据倾斜,数据倾斜会发⽣在数据开发的各个环节中,⽐如: ⽤Hive算数据的时候reduce阶段卡在99.99% ⽤SparkStreaming做实时算法时候,⼀直会有executor出现OOM的错误,但是其余的executor内存使⽤率却很低。 数据倾斜有⼀个关键因素是数据量⼤,可以达到千亿级。 数据倾斜长的表现 以Hadoop和Spark是最常见的两个计算平台,下⾯就以这两个平台说明: 1、Hadoop中的数据倾斜 Hadoop中直接贴近⽤户使⽤使⽤的时Mapreduce程序和Hive程序,虽说Hive最后也是⽤MR来执⾏(⾄少⽬前Hive内存计算并不普 及),但是毕竟写的内容逻辑区别很⼤,⼀个是程序,⼀个是Sql,因此这⾥稍作区分。 Hadoop中的数据倾斜主要表现在ruduce阶段卡在99.99%,⼀直99.99%不能结束。 这⾥如果详细的看⽇志或者和监控界⾯的话会发现: 有⼀个多⼏个reduce卡住 各种container报错OOM 读写的数据量极⼤,⾄少远远超过其它正常的reduce 伴随着数据倾斜,会出现任务被kill等各种诡异的表现。 经验: Hive的数据倾斜,⼀般都发⽣在Sql中Group和On上,⽽且和数据逻辑绑定⽐较深。 2、Spark中的数据倾斜 Spark中的数据倾斜也很常见,这⾥包括Spark Streaming和Spark Sql,表现主要有下⾯⼏种: Executor lost,OOM,Shuffle过程出错 Driver OOM 单个Executor执⾏时间特别久,整体任务卡在某个阶段不能结束 正常运⾏的任务突然失败 补充⼀下,在Spark streaming程序中,数据倾斜更容易出现,特别是在程序中包含⼀些类似sql的join、group这种操作的时候。 因为 Spark Streaming程序在运⾏的时候,我们⼀般不会分配特别多的内存,因此⼀旦在这个过程中出现⼀些数据倾斜,就⼗分容易造成 OOM。 数据倾斜的原理 1、数据倾斜产⽣的原因 我们以Spark和Hive的使⽤场景为例。他们在做数据运算的时候会设计到,countdistinct、group by、join等操作,这些都会触发 Shuffle动作,⼀旦触发,所有相同key的值就会拉到⼀个或⼏个节点上,就容易发⽣单点问题。 2、万恶的shuffle Shuffle是⼀个能产⽣奇迹的地⽅,不管是在Spark还是Hadoop中,它们的作⽤都是⾄关重要的。那么在Shuffle如何产⽣了数据倾 斜? Hadoop和Spark在Shuffle过程中产⽣数据倾斜的原理基本类似。如下图。 ⼤部分数据倾斜的原理就类似于下图,很明了,因为数据分布不均匀,导致⼤量的数据分配到了⼀个节点。 3、从业务计⾓度来理解数据倾斜 数据往往和业务是强相关的,业务的场景直接影响到了数据的分布。再举⼀个例⼦,⽐如就说订单场景吧,我们在某⼀天在北京和上 海两个城市多了强⼒的推⼴,结果可能是这两个城市的订单量增长了10000%,其余城市的数据量不变。然后我们要统计不同城市的订单 情况,这样,⼀做group操作,可能直接就数据倾斜了。 如何解决 数据倾斜的产⽣是有⼀些讨论的,解决它们也是有⼀些讨论的,本章会先给出⼏个解决数据倾斜的思路,然后对Hadoop和Spark分别 给出⼀些解决数据倾斜的⽅案。 ⼀、⼏个思路 解决数据倾斜有这⼏个思路: 1.业务逻辑,我们从业务逻辑的层⾯上来优化数据倾斜,⽐如上⾯的例⼦,我们单独对这两个城市来做count,最后和其它城市做整 合。 2.程序层⾯,⽐如说在Hive中,经常遇到count(distinct)操作,这样会导致最终只有⼀个reduce,我们可以先group 再在外⾯包 ⼀层count,就可以了。 3.调参⽅⾯,Hadoop和Spark都⾃带了很多的参数和机制来调节数据倾斜,合理利⽤它们就能解决⼤部分问题。 ⼆、从业务和数据上解决数据倾斜 很多数据倾斜都是在数据的使⽤上造成的。我们举⼏个场景,并分别给出它们的解决⽅案。 数据分布不均匀: 前⾯提到的"从数据⾓度来理解数据倾斜"和"从业务计⾓度来理解数据倾斜"中的例⼦,其实都是数据分布不均匀的类型,这种情况和计 算平台⽆关,我们能通过设计的⾓度尝试解决它。 有损的⽅法: 找到异常数据,⽐如ip为0的数据,过滤掉 ⽆损的⽅法: 对分布不均匀的数据,单独计算 先对key做⼀层hash,先将数据打散让它的并⾏度变⼤,再汇集 ·数据预处理 三、Had

22,206

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

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