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

2018-07-02 02:51:54 977 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

车辆贷款违约预测挑战赛 2021科大讯飞-车辆贷款违约预测挑战赛--方案简介车贷违约预测问题，目的是建立风险识别模型来预测可能违约的借款人。预测结果为借款人是否可能违约，属于二分类问题。偏数据挖掘的比赛，关键点是如何基于对数据的理解抽象归纳出有用的特征。站在大佬的视角，尝试学习总结，站在巨人的肩膀上，也许看得会更远一些。直接进入主题，开始学习套路，芜湖~特征工程1、常用库、数据导入import pandas as pd import numpy as np import lightgbm as lgb import xgboost 阅读详情

如果2百万数据中查询50万数据用5秒，那么6百万数据中查询相同的数据用时多少呢
1000万数据中查询50万相同数据，时间会一样吗

...全文

Windows中的TLS 1.2启用方法（IIS、C#、.Net framework）折腾几天了windows中的tls1.2启用方法！特此记录一下开发背景：在一个用.net framework 2.0开发的客户端程序里面嵌入功能调用第三方物联网相关接口，服务器上有一个restful接口用于接收第三方上报的数据及处理，最后再调用第三方的物联网相关接口。本机开发环境Windows 10，客户服务器是Windows Server 2008 R2。第一次写这种物联网相关的接口调用，而且第三方提供的文档比较简单，最基本的报文示例都没。开发环境里面各种摸索一步一个坑，首先在发送HTTP请求前阅读详情

工控采集老赵

疑难问题 22,298 成员 121,727 内容

+ 关注 + 加入社区

切换为时间正序

85年程序员 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]

不好意思，别哭别哭, 总有办法的

二月十六 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]

不好意思，别哭别哭, 总有办法的

吉普赛的歌 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）

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

相关推荐