60 个解决方案
#1
關注
#2
關注
#3
等待高人
#4
我只是想到要应该要建立索引 结果还是被bs了一回 虽然面试失败 但是也要解决 当作是提高吧
#5
关注
#6
关注,
#7
我也来关注。
#8
建议楼主去数据库开发板块那里去问一下,那里有csdn的老大。^_^
#9
ok 可能发错地方了
#10
1. 增加索引。 当查询条件有的时候有效,当然还要看索引的查询条件和索引是否对应,所以这个应该没什么效果
2. 创建视图。 按查询结果创建视图。应该会有所提速吧
3. 增加subEname字段, select subEname from emp。
以上我都不是十分的确定,等着高手指导。
2. 创建视图。 按查询结果创建视图。应该会有所提速吧
3. 增加subEname字段, select subEname from emp。
以上我都不是十分的确定,等着高手指导。
#11
我觉得增加视图应该没什么变化吧 如果增加一个存储substr的字段就是再一次查询的时候会提高速度
#12
一张有1000w级别的table最好别深层次改动表结构(除非优化到么的办法了,那就拆ename字段,那个比较高深且代价昂贵不确定是否能优化)
首先ename加一个索引是完全ok的
然后是查询,每次过滤查询不超过此table所有数据的20%为佳,查询还有个原则就是where后右操作优先
例如:
先过滤2=2 再1=1
所以最后优化结果:
substr() 各个db厂商不知道怎么实现的,如果还能优化可以再此再动动点子,原则还是把substr()集合再提前先缩小一些
以上为按照记忆中优化原则而来,欢迎指正
首先ename加一个索引是完全ok的
然后是查询,每次过滤查询不超过此table所有数据的20%为佳,查询还有个原则就是where后右操作优先
例如:
select * from tab where 1=1 and 2=2
先过滤2=2 再1=1
所以最后优化结果:
select substr(t.ename,2,2) from emp t where LENGTH(t.ename)>=3 and t.ename is not null
substr() 各个db厂商不知道怎么实现的,如果还能优化可以再此再动动点子,原则还是把substr()集合再提前先缩小一些
以上为按照记忆中优化原则而来,欢迎指正
#13
楼上的方法可以一试
#14
是不是可以考虑在原表上建一个计算列,然后在该计算上建索引,最后按计算列进行条件查询。
#15
等待等待
#16
人家问你
select substr(ename,2,2) from emp
整表查询
你居然说建索引,呵呵,你被人家故意说的“没有索引”骗了。因为这样的整表查询建索引没有用的。
如果是经常发生这样的substr(ename,2,2)查询,最好是把这个用一个单独的字段表示
select substr(ename,2,2) from emp
整表查询
你居然说建索引,呵呵,你被人家故意说的“没有索引”骗了。因为这样的整表查询建索引没有用的。
如果是经常发生这样的substr(ename,2,2)查询,最好是把这个用一个单独的字段表示
#17
帮顶
#18
函数索引.
#19
想法一致!!
#20
嘿嘿,我也经常这样引诱面试的同学。
比如我先问死锁,再问同步,最后问同步是不是解决死锁的办法。很多同学都上当答到“是,是吧,应该是吧。。。”,哈哈,就露馅了。
#21
晕了 难道只要添加一个字段 索引之类的是诱饵...........
#22
创建视图应该会提速的啊
#23
关注,等待高手指点,好好学习下
#24
晕,楼主面试人。。。。。。
#25
对数据库这部分不怎么懂,学习!
#26
严重同意 这中情况下 index是没用的.
#27
那到底该怎么做啥
#28
m
#29
关注
#30
这个题目面试程序员说明面试者自己就是个狗屁。
这是面试架构师的题目。
从1000万条数据库中提取所有记录(从实际情况看,ename >=3的条件基本是全满足)。
即使每条记录只有2byte(如果是双字节是4,UTF-8是6,UTF-16是8),总数据量是:
20000000byte/1024 约 = 20000m.
20000m/1024 约 = 20G.
你们见过什么样的数据库,什么样的硬件能提供在数据库地址空间内创建这么大的临时结果集?
这完全是架构总题,绝对不是结构问题。
这是面试架构师的题目。
从1000万条数据库中提取所有记录(从实际情况看,ename >=3的条件基本是全满足)。
即使每条记录只有2byte(如果是双字节是4,UTF-8是6,UTF-16是8),总数据量是:
20000000byte/1024 约 = 20000m.
20000m/1024 约 = 20G.
你们见过什么样的数据库,什么样的硬件能提供在数据库地址空间内创建这么大的临时结果集?
这完全是架构总题,绝对不是结构问题。
#31
20000000byte/1024 约= 20000 k
=.=
#32
答:你这个计算题是怎么算的?????
20000000byte/1024 约 = 20000m.
20000m/1024 约 = 20G.
你再想想!!
#33
进来瞅瞅~
#34
首先,视图不会对数据库的提速带来帮助,它是提升安全的,另外,视图会造成数据的不同步。
其次,索引并不会起到多大的作用。在这样大的数据量下。
最后,我的解决方案是,除了单纯对查询语句的优化外,还有必要修改表结构。
把表分区--------每区10万条-50万条。分100---20个区。
数据库会并行查询每个分区。是并行。
其次,索引并不会起到多大的作用。在这样大的数据量下。
最后,我的解决方案是,除了单纯对查询语句的优化外,还有必要修改表结构。
把表分区--------每区10万条-50万条。分100---20个区。
数据库会并行查询每个分区。是并行。
#35
晕,我确实算错了。
但是1000万条数据,直接提取,先不说substr,就说en已经是length =2了,不加任何条件查询看看。
这样的数据绝对不是修改结构和优化的问题,应该分区并行处理。
但是1000万条数据,直接提取,先不说substr,就说en已经是length =2了,不加任何条件查询看看。
这样的数据绝对不是修改结构和优化的问题,应该分区并行处理。
#36
同意楼上
#37
友情up
#38
友情up
#39
34楼的方法可行.up一个.
#40
不知道!!学习!!
#41
嘿嘿,1000亿条记录我没遇到过,1000万条记录还是遇到过的
#42
那怎么解决呢》
#43
我以前给银行写cobol的时候数据经常是20m记录以上的(测试环境),生产环境据说一天可以有100m记录以上。
晚上跑批量谁程序没写好一不小心就一夜都跑不完。。。囧。然后被夜班跑批量的人狂bs...
数据库能容纳多少记录和数据库和硬件环境都是有关系的。。。10m记录绝对不算多的。。
#44
另外lz的这个情况建索引是没有用的.substring这种在有没有索引的情况下效率基本一样。比较好的办法就是如果这个字段总是要被分成这样就把这个字段分成两个,然后建索引才行啊。
#45
是啊,其实1000万条记录不算多,正常处理就好了。
以前在IBM小机上的数据库,几个表日产数据100k以上,只要数据库规划得好,性能没有任何问题。
一般都是用的存储阵列,好像分区的用处不大(我自己的理解)
以前在IBM小机上的数据库,几个表日产数据100k以上,只要数据库规划得好,性能没有任何问题。
一般都是用的存储阵列,好像分区的用处不大(我自己的理解)
#46
这个是必需的,
然后就需要问他们,这个查询的要用于什么,具体情况得具体分析,不论是显示,还是数据对导,最好对查询进行分页处理。
如果说就是为了让内存溢出,你就可以拔了他的内裤,抽出皮筋,做成弹弓打他家玻璃
#47
学习....
#48
脑袋看得晕忽忽的
#49
友情UP一下!
#50
16楼的
“如果是经常发生这样的substr(ename,2,2)查询,最好是把这个用一个单独的字段表示”
和34楼的
“把表分区--------每区10万条-50万条。分100---20个区。数据库会并行查询每个分区。是并行。”
合起来应该是一个比较好的解决方案。
呵呵,学习中。。。。
“如果是经常发生这样的substr(ename,2,2)查询,最好是把这个用一个单独的字段表示”
和34楼的
“把表分区--------每区10万条-50万条。分100---20个区。数据库会并行查询每个分区。是并行。”
合起来应该是一个比较好的解决方案。
呵呵,学习中。。。。
#1
關注
#2
關注
#3
等待高人
#4
我只是想到要应该要建立索引 结果还是被bs了一回 虽然面试失败 但是也要解决 当作是提高吧
#5
关注
#6
关注,
#7
我也来关注。
#8
建议楼主去数据库开发板块那里去问一下,那里有csdn的老大。^_^
#9
ok 可能发错地方了
#10
1. 增加索引。 当查询条件有的时候有效,当然还要看索引的查询条件和索引是否对应,所以这个应该没什么效果
2. 创建视图。 按查询结果创建视图。应该会有所提速吧
3. 增加subEname字段, select subEname from emp。
以上我都不是十分的确定,等着高手指导。
2. 创建视图。 按查询结果创建视图。应该会有所提速吧
3. 增加subEname字段, select subEname from emp。
以上我都不是十分的确定,等着高手指导。
#11
我觉得增加视图应该没什么变化吧 如果增加一个存储substr的字段就是再一次查询的时候会提高速度
#12
一张有1000w级别的table最好别深层次改动表结构(除非优化到么的办法了,那就拆ename字段,那个比较高深且代价昂贵不确定是否能优化)
首先ename加一个索引是完全ok的
然后是查询,每次过滤查询不超过此table所有数据的20%为佳,查询还有个原则就是where后右操作优先
例如:
先过滤2=2 再1=1
所以最后优化结果:
substr() 各个db厂商不知道怎么实现的,如果还能优化可以再此再动动点子,原则还是把substr()集合再提前先缩小一些
以上为按照记忆中优化原则而来,欢迎指正
首先ename加一个索引是完全ok的
然后是查询,每次过滤查询不超过此table所有数据的20%为佳,查询还有个原则就是where后右操作优先
例如:
select * from tab where 1=1 and 2=2
先过滤2=2 再1=1
所以最后优化结果:
select substr(t.ename,2,2) from emp t where LENGTH(t.ename)>=3 and t.ename is not null
substr() 各个db厂商不知道怎么实现的,如果还能优化可以再此再动动点子,原则还是把substr()集合再提前先缩小一些
以上为按照记忆中优化原则而来,欢迎指正
#13
楼上的方法可以一试
#14
是不是可以考虑在原表上建一个计算列,然后在该计算上建索引,最后按计算列进行条件查询。
#15
等待等待
#16
人家问你
select substr(ename,2,2) from emp
整表查询
你居然说建索引,呵呵,你被人家故意说的“没有索引”骗了。因为这样的整表查询建索引没有用的。
如果是经常发生这样的substr(ename,2,2)查询,最好是把这个用一个单独的字段表示
select substr(ename,2,2) from emp
整表查询
你居然说建索引,呵呵,你被人家故意说的“没有索引”骗了。因为这样的整表查询建索引没有用的。
如果是经常发生这样的substr(ename,2,2)查询,最好是把这个用一个单独的字段表示
#17
帮顶
#18
函数索引.
#19
想法一致!!
#20
嘿嘿,我也经常这样引诱面试的同学。
比如我先问死锁,再问同步,最后问同步是不是解决死锁的办法。很多同学都上当答到“是,是吧,应该是吧。。。”,哈哈,就露馅了。
#21
晕了 难道只要添加一个字段 索引之类的是诱饵...........
#22
创建视图应该会提速的啊
#23
关注,等待高手指点,好好学习下
#24
晕,楼主面试人。。。。。。
#25
对数据库这部分不怎么懂,学习!
#26
严重同意 这中情况下 index是没用的.
#27
那到底该怎么做啥
#28
m
#29
关注
#30
这个题目面试程序员说明面试者自己就是个狗屁。
这是面试架构师的题目。
从1000万条数据库中提取所有记录(从实际情况看,ename >=3的条件基本是全满足)。
即使每条记录只有2byte(如果是双字节是4,UTF-8是6,UTF-16是8),总数据量是:
20000000byte/1024 约 = 20000m.
20000m/1024 约 = 20G.
你们见过什么样的数据库,什么样的硬件能提供在数据库地址空间内创建这么大的临时结果集?
这完全是架构总题,绝对不是结构问题。
这是面试架构师的题目。
从1000万条数据库中提取所有记录(从实际情况看,ename >=3的条件基本是全满足)。
即使每条记录只有2byte(如果是双字节是4,UTF-8是6,UTF-16是8),总数据量是:
20000000byte/1024 约 = 20000m.
20000m/1024 约 = 20G.
你们见过什么样的数据库,什么样的硬件能提供在数据库地址空间内创建这么大的临时结果集?
这完全是架构总题,绝对不是结构问题。
#31
20000000byte/1024 约= 20000 k
=.=
#32
答:你这个计算题是怎么算的?????
20000000byte/1024 约 = 20000m.
20000m/1024 约 = 20G.
你再想想!!
#33
进来瞅瞅~
#34
首先,视图不会对数据库的提速带来帮助,它是提升安全的,另外,视图会造成数据的不同步。
其次,索引并不会起到多大的作用。在这样大的数据量下。
最后,我的解决方案是,除了单纯对查询语句的优化外,还有必要修改表结构。
把表分区--------每区10万条-50万条。分100---20个区。
数据库会并行查询每个分区。是并行。
其次,索引并不会起到多大的作用。在这样大的数据量下。
最后,我的解决方案是,除了单纯对查询语句的优化外,还有必要修改表结构。
把表分区--------每区10万条-50万条。分100---20个区。
数据库会并行查询每个分区。是并行。
#35
晕,我确实算错了。
但是1000万条数据,直接提取,先不说substr,就说en已经是length =2了,不加任何条件查询看看。
这样的数据绝对不是修改结构和优化的问题,应该分区并行处理。
但是1000万条数据,直接提取,先不说substr,就说en已经是length =2了,不加任何条件查询看看。
这样的数据绝对不是修改结构和优化的问题,应该分区并行处理。
#36
同意楼上
#37
友情up
#38
友情up
#39
34楼的方法可行.up一个.
#40
不知道!!学习!!
#41
嘿嘿,1000亿条记录我没遇到过,1000万条记录还是遇到过的
#42
那怎么解决呢》
#43
我以前给银行写cobol的时候数据经常是20m记录以上的(测试环境),生产环境据说一天可以有100m记录以上。
晚上跑批量谁程序没写好一不小心就一夜都跑不完。。。囧。然后被夜班跑批量的人狂bs...
数据库能容纳多少记录和数据库和硬件环境都是有关系的。。。10m记录绝对不算多的。。
#44
另外lz的这个情况建索引是没有用的.substring这种在有没有索引的情况下效率基本一样。比较好的办法就是如果这个字段总是要被分成这样就把这个字段分成两个,然后建索引才行啊。
#45
是啊,其实1000万条记录不算多,正常处理就好了。
以前在IBM小机上的数据库,几个表日产数据100k以上,只要数据库规划得好,性能没有任何问题。
一般都是用的存储阵列,好像分区的用处不大(我自己的理解)
以前在IBM小机上的数据库,几个表日产数据100k以上,只要数据库规划得好,性能没有任何问题。
一般都是用的存储阵列,好像分区的用处不大(我自己的理解)
#46
这个是必需的,
然后就需要问他们,这个查询的要用于什么,具体情况得具体分析,不论是显示,还是数据对导,最好对查询进行分页处理。
如果说就是为了让内存溢出,你就可以拔了他的内裤,抽出皮筋,做成弹弓打他家玻璃
#47
学习....
#48
脑袋看得晕忽忽的
#49
友情UP一下!
#50
16楼的
“如果是经常发生这样的substr(ename,2,2)查询,最好是把这个用一个单独的字段表示”
和34楼的
“把表分区--------每区10万条-50万条。分100---20个区。数据库会并行查询每个分区。是并行。”
合起来应该是一个比较好的解决方案。
呵呵,学习中。。。。
“如果是经常发生这样的substr(ename,2,2)查询,最好是把这个用一个单独的字段表示”
和34楼的
“把表分区--------每区10万条-50万条。分100---20个区。数据库会并行查询每个分区。是并行。”
合起来应该是一个比较好的解决方案。
呵呵,学习中。。。。