如果两百万数据中查询50万数据用5秒，那么6百万数据呢

班长老六哥 2018-07-02 02:51:54
如果2百万数据中查询50万数据用5秒，那么6百万数据中查询相同的数据用时多少呢
1000万数据中查询50万相同数据，时间会一样吗
...全文
872 26 打赏 收藏 转发到动态 举报
写回复
用AI写文章
26 条回复
切换为时间正序
请发表友善的回复…
发表回复
徐新帅 2018-07-04
  • 打赏
  • 举报
 回复
这个问题 看似简单的问题，但是当表中数据达到一定程度后，查询的路径就不一样了，这就涉及到索引的问题。查询的数据条件不同，也有可能会影响查询的用时，根据这个情况无法确定会增加或减少多少秒，需要实践下。祝好
学习的麋鹿 2018-07-04
  • 打赏
  • 举报
 回复
偷偷的学习一下
小灰狼 2018-07-04
  • 打赏
  • 举报
 回复
以前在 mysql 下做过测试，sql server 不知道
当一个分区中的数据量少于1.3亿时，对创建过索引的字段进行查等匹配查找，所花的时间差别不太大。但超过1.3亿时，查找所消耗的时间有比较明显的增大。
后来自己分析了认为，可能是二叉树引起的。因为深度为27的二叉树上可以有1.3亿多个节点，如果达到1.4亿的话，二叉树的深度就达到了28。
啊大1号 2018-07-04
  • 打赏
  • 举报
 回复
就一块硬盘？先不考虑速度，至少也得先考虑备份吧
吉普赛的歌 2018-07-03
  • 打赏
  • 举报
 回复 
--1. 增加主键（无主键，可能导致堵塞）

ALTER TABLE [dbo].[bbuild1] ADD  CONSTRAINT [PK_bbuild1]  PRIMARY KEY NONCLUSTERED ([no])

--2. 将 NULL 值记录更新为 '1900-01-01', 避免为NULL的情况

UPDATE [dbo].[bbuild1] SET [time] ='1900-01-01' WHERE [time] IS NULL

--3. 修改为非NULL列

ALTER TABLE [dbo].[bbuild1] ALTER COLUMN [time] SMALLDATETIME NOT NULL

--4. 增加聚集索引

CREATE CLUSTERED INDEX ix_bbuild1_time ON [dbo].[bbuild1] ([time])

--5. 增加非聚集索引

CREATE INDEX ix_bbuild1_area_build_unit_room ON [dbo].[bbuild1] ( area, build, unit, room )


你先这样一些索引。
索引用在百里挑一是合适的， 当然， 万里挑一更好。
如果你每次只导出 1 万条数据， 那只用索引就够用了， 不用分表分区。

先加上再说吧， 如果还觉得慢， 把具体的SQL 贴出来。
班长老六哥 2018-07-03
  • 打赏
  • 举报
 回复
引用 13 楼 zjcxc 的回复:
明显的已知条件不足
按照你说的，最终都是 取50万，最简单的情况，都是顺序取 50 万就行了，那数据量再大也没什么差别嘛

建议你具体描述，表结构，大致的数据分布，具体的查询需求

表结构放到楼上了，如下是我的查询语句

SELECT *

  FROM [tin].[dbo].[bbuild1] where area='b' and build='1' and unit='1' and room='1001'

就是查询一个小区一栋楼一个单元一户的数据，如果客户不查询整栋楼的，只是单户这样的，一年一万条就够了，要求保存三年的，那么请问大神，如果三年一个表有600万数据，我从中根据时间查出3万条应该很快吧，刚才试了一下200万中查一万就用不到一秒。
sj13483162817 2018-07-03
  • 打赏
  • 举报
 回复
不知道你是从哪里查询，查询时间不考虑的话，光看传输时间肯定要乘以12的
班长老六哥 2018-07-03
  • 打赏
  • 举报
 回复
引用 12 楼 yenange 的回复:
分区表， 对不再修改的分区， 碎片率不会再上升， 碎片集中在变化区域。
不过， 如果你定期重建索引， 也没什么关系， 服务器强劲一点的话分不分区影响不大。
只是管理、迁移数据这些方面更方便。
可以暂时不理分区的事。

建议你先分表：
当月表: xxxx_currMonth
当年表：xxxx_currYear
历史表：xxxx_history

每个月的第一天， 对表的数据进行转移。
每个表的时间范围清晰了， 后面要查询就变得容易了， 效率也会有一定的提高。
注意：将时间字段设置为聚集索引。
每个月自动产生 csv 文件， 这个还是按我上面说的来。

综合起来， 用户体验不会差的。

USE [tin]

GO



/****** Object:  Table [dbo].[bbuild1]    Script Date: 07/03/2018 09:39:59 ******/

SET ANSI_NULLS ON

GO



SET QUOTED_IDENTIFIER ON

GO



SET ANSI_PADDING ON

GO



CREATE TABLE [dbo].[bbuild1](

	[no] [bigint] IDENTITY(1,1) NOT NULL,

	[time] [smalldatetime] NULL,

	[area] [varchar](2) NULL,

	[build] [varchar](10) NULL,

	[unit] [varchar](10) NULL,

	[room] [varchar](10) NULL,

	[id] [float] NULL,

	[t] [float] NULL,

	[tsp] [float] NULL,

	[te] [float] NULL,

	[tc] [float] NULL,

	[tp] [float] NULL

) ON [PRIMARY]



GO



SET ANSI_PADDING OFF

GO



ALTER TABLE [dbo].[bbuild1] ADD  CONSTRAINT [DF_bbuild1_time]  DEFAULT (getdate()) FOR [time]

GO

这是我的表结构 求大神给写一个时间字段设置为聚集索引的sql，以前没用过，怕出问题，谢谢！
shinger126 2018-07-03
  • 打赏
  • 举报
 回复
看需求应该是要做报表，不过你确定报表需要50W条的明细记录？
zjcxc 2018-07-03
  • 打赏
  • 举报
 回复
明显的已知条件不足
按照你说的，最终都是 取50万，最简单的情况，都是顺序取 50 万就行了，那数据量再大也没什么差别嘛

建议你具体描述，表结构，大致的数据分布，具体的查询需求
足球中国 2018-07-03
  • 打赏
  • 举报
 回复
总共就600万条数据。又不是很大。为啥要建分区呢。慢不在查询上面，而在结果集很多。返回的量很大。
line_us 2018-07-03
  • 打赏
  • 举报
 回复
应该不是线性比例关系吧
吉普赛的歌 2018-07-02
  • 打赏
  • 举报
 回复
分区表， 对不再修改的分区， 碎片率不会再上升， 碎片集中在变化区域。
不过， 如果你定期重建索引， 也没什么关系， 服务器强劲一点的话分不分区影响不大。
只是管理、迁移数据这些方面更方便。
可以暂时不理分区的事。

建议你先分表：
当月表: xxxx_currMonth
当年表：xxxx_currYear
历史表：xxxx_history

每个月的第一天， 对表的数据进行转移。
每个表的时间范围清晰了， 后面要查询就变得容易了， 效率也会有一定的提高。
注意：将时间字段设置为聚集索引。
每个月自动产生 csv 文件， 这个还是按我上面说的来。

综合起来， 用户体验不会差的。
班长老六哥 2018-07-02
  • 打赏
  • 举报
 回复
引用 9 楼 yenange 的回复:
[quote=引用 7 楼 zk12668 的回复:]
[quote=引用 6 楼 yenange 的回复:]
[quote=引用 3 楼 zk12668 的回复:]
[quote=引用 1 楼 yenange 的回复:]
如果都有索引（分区）， 碎片率都比较低， 时间相差不会特别大。
但数据量大的时间长的可能性还是大一些。

可以想象一下：
从 4 个人中找 1 个人, 从 12 个人中找 1 个人， 200 个人中找 1 个人。

不过， 2百万中找50万，可能索引都无效了。
最好有实际的案例测试一下。

我现在一年200万 要存三年的可能600到800万 没用索引，准备用，你这句索引无效打击我了[/quote]

不好意思， 别哭别哭, 总有办法的
索引不是任何时候都有效， 但 最终结果记录数与总记录数的 比率是一个很重要的因素。
不明白你为什么要一次性出 50 万数据？
一般客户看不了这么多， 页面上都是分页处理。
你是用作报表么？[/quote]

是的 报表 要看和导出一年或是几个月的，有的时候可能导出200万的 比如去年的 有时候几个月可能几十万 但是速度太慢太影响体验[/quote]
1. 索引还是要建， 建立在 时间字段 上， 最好是设置为聚集索引。当然， 你学习一下分区做成分区表更好。
2. 如果经常要导出一年或几个月的数据， 不应该从经常数据库上取数据。
可以每个月的月头， 比如 20180701 ， 凌晨生成 201806 一个月的数据， 放在一个 csv 文件里面。
每个月一个 csv， 要几个月的数据， 就直接将这几个 csv 文件打包一下让用户下载就是了。
当前月的数据还是从数据库中取， 不过至多31天的数据， 这个速度不会很慢。
如果希望只保留一个csv文件，也不过文件组合一下而已， 也不难。[/quote]
刚才了解了一下分区，如果一块硬盘，不跨区查速度会快些，最好是多块硬盘跨区查速度会快很多，可惜我是一块硬盘，也可能不跨区查，所以悲哀
班长老六哥 2018-07-02
  • 打赏
  • 举报
 回复
引用 9 楼 yenange 的回复:
[quote=引用 7 楼 zk12668 的回复:]
[quote=引用 6 楼 yenange 的回复:]
[quote=引用 3 楼 zk12668 的回复:]
[quote=引用 1 楼 yenange 的回复:]
如果都有索引（分区）， 碎片率都比较低， 时间相差不会特别大。
但数据量大的时间长的可能性还是大一些。

可以想象一下：
从 4 个人中找 1 个人, 从 12 个人中找 1 个人， 200 个人中找 1 个人。

不过， 2百万中找50万，可能索引都无效了。
最好有实际的案例测试一下。

我现在一年200万 要存三年的可能600到800万 没用索引，准备用，你这句索引无效打击我了[/quote]

不好意思， 别哭别哭, 总有办法的
索引不是任何时候都有效， 但 最终结果记录数与总记录数的 比率是一个很重要的因素。
不明白你为什么要一次性出 50 万数据？
一般客户看不了这么多， 页面上都是分页处理。
你是用作报表么？[/quote]

是的 报表 要看和导出一年或是几个月的，有的时候可能导出200万的 比如去年的 有时候几个月可能几十万 但是速度太慢太影响体验[/quote]
1. 索引还是要建， 建立在 时间字段 上， 最好是设置为聚集索引。当然， 你学习一下分区做成分区表更好。
2. 如果经常要导出一年或几个月的数据， 不应该从经常数据库上取数据。
可以每个月的月头， 比如 20180701 ， 凌晨生成 201806 一个月的数据， 放在一个 csv 文件里面。
每个月一个 csv， 要几个月的数据， 就直接将这几个 csv 文件打包一下让用户下载就是了。
当前月的数据还是从数据库中取， 不过至多31天的数据， 这个速度不会很慢。
如果希望只保留一个csv文件，也不过文件组合一下而已， 也不难。[/quote]
索引会增加增,删,改的时间，分区不会有这个问题，所以大神才推荐我用分区是吧?
吉普赛的歌 2018-07-02
  • 打赏
  • 举报
 回复
引用 7 楼 zk12668 的回复:
[quote=引用 6 楼 yenange 的回复:]
[quote=引用 3 楼 zk12668 的回复:]
[quote=引用 1 楼 yenange 的回复:]
如果都有索引（分区）， 碎片率都比较低， 时间相差不会特别大。
但数据量大的时间长的可能性还是大一些。

可以想象一下：
从 4 个人中找 1 个人, 从 12 个人中找 1 个人， 200 个人中找 1 个人。

不过， 2百万中找50万，可能索引都无效了。
最好有实际的案例测试一下。

我现在一年200万 要存三年的可能600到800万 没用索引，准备用，你这句索引无效打击我了[/quote]

不好意思， 别哭别哭, 总有办法的
索引不是任何时候都有效， 但 最终结果记录数与总记录数的 比率是一个很重要的因素。
不明白你为什么要一次性出 50 万数据？
一般客户看不了这么多， 页面上都是分页处理。
你是用作报表么？[/quote]

是的 报表 要看和导出一年或是几个月的，有的时候可能导出200万的 比如去年的 有时候几个月可能几十万 但是速度太慢太影响体验[/quote]
1. 索引还是要建， 建立在 时间字段 上， 最好是设置为聚集索引。当然， 你学习一下分区做成分区表更好。
2. 如果经常要导出一年或几个月的数据， 不应该从经常数据库上取数据。
可以每个月的月头， 比如 20180701 ， 凌晨生成 201806 一个月的数据， 放在一个 csv 文件里面。
每个月一个 csv， 要几个月的数据， 就直接将这几个 csv 文件打包一下让用户下载就是了。
当前月的数据还是从数据库中取， 不过至多31天的数据， 这个速度不会很慢。
如果希望只保留一个csv文件，也不过文件组合一下而已， 也不难。
二月十六 2018-07-02
  • 打赏
  • 举报
 回复
报表是实时的吗？还是每月一总结？如果是后者的话，可以建立一个job，每月底生成一批报表数据信息存储起来，不用每次都去读那么多数据。
班长老六哥 2018-07-02
  • 打赏
  • 举报
 回复
引用 6 楼 yenange 的回复:
[quote=引用 3 楼 zk12668 的回复:]
[quote=引用 1 楼 yenange 的回复:]
如果都有索引（分区）， 碎片率都比较低， 时间相差不会特别大。
但数据量大的时间长的可能性还是大一些。

可以想象一下：
从 4 个人中找 1 个人, 从 12 个人中找 1 个人， 200 个人中找 1 个人。

不过， 2百万中找50万，可能索引都无效了。
最好有实际的案例测试一下。

我现在一年200万 要存三年的可能600到800万 没用索引，准备用，你这句索引无效打击我了[/quote]

不好意思， 别哭别哭, 总有办法的
索引不是任何时候都有效， 但 最终结果记录数与总记录数的 比率是一个很重要的因素。
不明白你为什么要一次性出 50 万数据？
一般客户看不了这么多， 页面上都是分页处理。
你是用作报表么？[/quote]

是的 报表 要看和导出一年或是几个月的，有的时候可能导出200万的 比如去年的 有时候几个月可能几十万 但是速度太慢太影响体验
吉普赛的歌 2018-07-02
  • 打赏
  • 举报
 回复
引用 3 楼 zk12668 的回复:
[quote=引用 1 楼 yenange 的回复:]
如果都有索引（分区）， 碎片率都比较低， 时间相差不会特别大。
但数据量大的时间长的可能性还是大一些。

可以想象一下：
从 4 个人中找 1 个人, 从 12 个人中找 1 个人， 200 个人中找 1 个人。

不过， 2百万中找50万，可能索引都无效了。
最好有实际的案例测试一下。

我现在一年200万 要存三年的可能600到800万 没用索引，准备用，你这句索引无效打击我了[/quote]

不好意思， 别哭别哭, 总有办法的
索引不是任何时候都有效， 但 最终结果记录数与总记录数的 比率是一个很重要的因素。
不明白你为什么要一次性出 50 万数据？
一般客户看不了这么多， 页面上都是分页处理。
你是用作报表么？
班长老六哥 2018-07-02
  • 打赏
  • 举报
 回复
引用 1 楼 yenange 的回复:
如果都有索引（分区）， 碎片率都比较低， 时间相差不会特别大。
但数据量大的时间长的可能性还是大一些。

可以想象一下：
从 4 个人中找 1 个人, 从 12 个人中找 1 个人， 200 个人中找 1 个人。

不过， 2百万中找50万，可能索引都无效了。
最好有实际的案例测试一下。

我是按照时间查询的数据，如果我建立一个年份和月份的字段，是不是会查的快些，它通过年份就排除其他年份数据，然后通过月份又排除很多数据，这样会快吗
加载更多回复（4）
mysql百万级数据查询优化实践-从开始到开除
然而这次在表里只有十多万数据时，每日统计查询竟然查不动了，查一次要四五秒。 如果是百万级数据，我还可以甩锅为服务器性能问题，十万数据查不动，要是汇报让领导升级服务器，估计领导直接让我去跟人事结算工资了...
Java 百万数据秒级导出到Excel中
出自: 腾讯课堂 700多分钟干货实战Java多线程高并发高性能实战全集 , 我学习完了之后,我做了个笔记. 1.案例背景 某个MySQL服务器的user表有100万条数据,请运用...如果你把一百万条数据导出到多个Excel里面,一个Excel里
mysql 百万数据关联_mysql百万数据关联查询优化
前段时间写过一篇MySQL Join的底层实现原理，里面稍微有提到怎么...表1(T1)：T1 count.png表2(T2)：T2 count.png可以看到T1有33万数据，T2有50万数据，sql语句是：select tbj.OWNER_TYPE, tpo.OWNER_NAME, tpo.PRINC...
两秒对比100万数据差异
日常工作中，有可能需要对比两个文件的数据差异，在大量数据的情况下，常用的办法是使用数据库对比，现推荐一个使用python脚本对比数据的方法，实际测试，文件一有60万行数据，文件2有50万行数据，对比差异耗时1.5S...
mysql对大量数据查询花费时间_对于Mysql大量数据查询速度慢的问题
1.如果mysql数据量过大，当查询的时候耗时比较长，则会影响页面数据展示。给客户的直观反应的：点击了某个查询功能，结果等了差不多十几秒才反应出来，这样的体验感太差了。2.为了增加反应速度。一般来是建立索引，...
疑难问题

22,209

社区成员

121,731

社区内容

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

加载中

查看更多榜单
社区公告
暂无公告

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

+ 用AI写文章