关于扫码操作实时统计的设计方案，请大家看看，给点意见。

eksmile

luckyrandom 发表于 2015-8-31 10:48
索引聚合视图就是TRIGGER维护聚合值的完美替代方式，开销绝对小过TRIGGER，开发、维护也更简单
从结果上说 ...

1. CREATE TABLE [dbo].[test_online_log](
2.         [ol_sessionid] [varchar](100) NULL,
3.         [ol_time] [datetime] NULL,
4.         [ol_status] [varchar](10) NULL
5. )
8. CREATE VIEW V_online_log
9. WITH SCHEMABINDING
10. AS
11. SELECT COUNT_BIG (*) AS Cnt
12. FROM dbo.test_online_log
15. CREATE UNIQUE CLUSTERED INDEX IDX_V_online_log
16.     ON dbo.V_online_log (Cnt);
19. SELECT * FROM V_online_log

复制代码

如上建表、视图、索引后，进行查询操作。
在视图上建立索引之前，与建立索引之后的执行计划并无差异，如下：


按理，在建立索引之后，应该不需要再对表进行全表扫描了呀，不知道哪里出了问题。

mssql_wang

eksmile 发表于 2015-8-31 10:14
主要就是前台需要1-2秒刷新，获得一次总记录数。（期望是可以1秒刷一次）
不管是否WITH(NOLOCK)，每秒CO ...

数据量大的情况下：
1）按日期时间段将某一日期D1前的数据归档，然后统计相关数据得出一常量SUM(1)
2)统计D1之后的数据得结果SUM(2)+SUM(1)就OK了，
以上前提为D1前的数据是不变的情况下。

eksmile

luckyrandom 发表于 2015-8-31 10:48
索引聚合视图就是TRIGGER维护聚合值的完美替代方式，开销绝对小过TRIGGER，开发、维护也更简单
从结果上说 ...

在使用索引视图之前，插入操作的执行计划如下：


在使用索引视图之后，插入操作执行计划如下：


从执行计划中可以看了，使用索引视图之后，对其进行插入操作，会对视图上的索引进行更新，那么按理对视图查询时，应该不需要表扫描了呀。

eksmile

mssql_wang 发表于 2015-8-31 14:43
数据量大的情况下：
1）按日期时间段将某一日期D1前的数据归档，然后统计相关数据得出一常量SUM(1)
2)统 ...

“统计D1之后的数据” 再与常量相加 这样的方式，
即使按分钟粒度对常量值进行更新，为了获取增量值，也仍旧需要对该表进行频繁的 "WHERE 时间>=D1"和“COUNT”操作。
虽无实际验证，但是觉得频繁的WHERE&COUNT操作的开销会相对大一些。

mssql_wang

eksmile 发表于 2015-8-31 14:51
“统计D1之后的数据” 再与常量相加 这样的方式，
即使按分钟粒度对常量值进行更新，为了获取增量值，也 ...

在时间列上建立索引基本不会有多大开销的。
我们十几亿条的记录，要查询数据照样是秒级别的。
你还可以考虑分区表或者SQL 2014列存储索引，内存表。

eksmile

mssql_wang 发表于 2015-8-31 15:14
在时间列上建立索引基本不会有多大开销的。
我们十几亿条的记录，要查询数据照样是秒级别的。
你还可以 ...

1. CREATE TABLE [dbo].[test_online_log](
2.         [ol_sessionid] [varchar](100) NULL,
3.         [ol_time] [datetime] NULL,
4.         [ol_status] [varchar](10) NULL
5. )

复制代码

您的意思是，形如这样的日志表，在ol_time字段上增加索引，然后按天/小时更新常量数据，
然后再用WHERE/COUNT获得增量数据，对于亿级的数据，
使用这样的方案获取统计值可以达到2秒内？

mssql_wang

eksmile 发表于 2015-8-31 15:26
您的意思是，形如这样的日志表，在ol_time字段上增加索引，然后按天/小时更新常量数据，
然后再用WHERE/ ...

1亿级别的查询只需要2秒，当然如果把SQL语句封装成SP可能会更快些。遇到慢要先判断到底是慢在哪里，是IO跟不上还是写法，还是别的等待造成的。然后再去找方案优化就应该能满足要求了。

SQL Server 分析和编译时间:
   CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。

(1 行受影响)
表 。扫描计数 1，逻辑读取 118777 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

SQL Server 执行时间:
   CPU 时间 = 2594 毫秒，占用时间 = 2608 毫秒。
SQL Server 分析和编译时间:
   CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。

SQL Server 执行时间:
   CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。

eksmile

mssql_wang 发表于 2015-8-31 15:37
1亿级别的查询只需要2秒，当然如果把SQL语句封装成SP可能会更快些。遇到慢要先判断到底是慢在哪里，是I ...

明白了。

对于COUNT可以采用这个方式，如果是求和操作呢？
在时间字段上增加索引，对另一个字段进行求和，针对这样的需求，查询时间应该会相应的延长吧。
（也采用定时更新常量数据的机制）

luckyrandom

太多了，没细看
取表总数，直接看 Sys.Partitions.Rows
举个索引视图例子：

CREATE VIEW V_online_log
WITH SCHEMABINDING
AS
SELECT City,COUNT_BIG (*) AS Cnt
FROM dbo.test_online_log Group By City

Go
CREATE UNIQUE CLUSTERED INDEX IDX_V_online_log
    ON dbo.V_online_log (City);

这就是聚合按市级取总数

eksmile

luckyrandom 发表于 2015-8-31 16:29
太多了，没细看
取表总数，直接看 Sys.Partitions.Rows
举个索引视图例子：

Sys.Partitions.Rows 足矣解决问题。谢谢。