提高MSSQL数据库性能(1)对比count(*) 和 替代count(*)

简介: 原文:提高MSSQL数据库性能(1)对比count(*) 和 替代count(*)文章准备的数据库: Atricles 表   数据量60690000条数据 ArticleID 主键自增列+自动建立的聚集索引,ATitle nvarchar(100)  Acontent varchar(2000...
原文: 提高MSSQL数据库性能(1)对比count(*) 和 替代count(*)

文章准备的数据库: Atricles 表   数据量60690000条数据

ArticleID 主键自增列+自动建立的聚集索引,ATitle nvarchar(100)  Acontent varchar(2000) CreateDate DateTime(8)  

首先要说的是:select count(*) from table,那么count(*) 和 count(主键) count(文本列)效率比较:  这里是测试主代码

         dbcc freeProcCache  --清空SqlCache

              SET STATISTICS io ON

        SET STATISTICS time ON

        go

        ----这里是测试语句

        go

        SET STATISTICS profile OFF

        SET STATISTICS io OFF

        SET STATISTICS time OFF

那么我们来看看:

SELECT COUNT(*) FROM ATRICLES                          CPU 时间 = 1125 毫秒,占用时间 = 1140 毫秒。

SELECT COUNT(ATRICLEID) FROM ATRICLES           CPU 时间 = 1093 毫秒,占用时间 = 1094 毫秒

SELECT COUNT(ATITLE) FROM ATRICLES                 CPU 时间 = 2266 毫秒,占用时间 = 2267 毫秒

SELECT COUNT(ACONTENT) FROM ATRICLES           CPU 时间 = 2296 毫秒,占用时间 = 2303 毫秒。

Count(*) 是在处了 count(主键) 之外速度最快的  为什么最快其实我也不知道 - -! 猜想可能是SQL自动做了查询优化

 

那么我们是否一定得要 COUNT(*)呢 不是的 大家看这里:

SELECT ROWS FROM SYSINDEXES WHERE ID = OBJECT_ID('ATRICLES') AND INDID = 1

那么我们看看它和select count(主键)的比较吧:

首先是Count(主键)

表'ATRICLES'。扫描计数 1,逻辑读取 120368 次,物理读取 3 次,预读 120364 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

 SQL Server 执行时间:  CPU 时间 = 2282 毫秒,占用时间 = 21334 毫秒。

其次是 from SYSINDEXES

表 'SYSINDEXES'。扫描计数 1,逻辑读取 2 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0次,lob 预读 0 次。

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

SYSINDEXES 系统表   所有的表 行集 索引信息 存放在这个表中

ID =OBJECT_ID('ATRICLES') ID的意思是 索引所属的表ID

INDID 表示在聚集索引上查找 因为主键在建立的时候已经自动的建立了聚集索引

ROWS 基于 indid = 0 和 indid = 1 的数据级行计数,如果 indid >1,则该值包含重复的计数。

这篇文章想说的是: 在分页情况下 可以考虑使用上面语句查找数据行   AND  count(*) 并不是低效率的 感谢下面朋友指教

本文结束  晚安

目录
相关文章
|
12天前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
2月前
|
SQL 关系型数据库 MySQL
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
|
2月前
|
物联网 测试技术 API
时序数据库 InfluxDB 3.0 版本性能实测报告:写入吞吐量提升效果验证
TSBS 测试表明,对于少于 100 万台设备的数据集,InfluxDB OSS 3.0 的数据写入速度实际上比 InfluxDB OSS 1.8 更慢。 对于 100 万台及以上设备的数据集,InfluxDB OSS 3.0 的数据写入性能才开始超过 InfluxDB OSS 1.8。 InfluxDB OSS 3.0 的数据写入接口与 InfluxDB 1.8 并不兼容,用户无法顺利迁移。
81 7
|
3月前
|
Cloud Native 关系型数据库 分布式数据库
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
|
3月前
|
数据库
【YashanDB 知识库】误配置 SYSTEM 级别的 STATISTICS_LEVEL 参数为 ALL 导致数据库性能下降
**标题:误配置 SYSTEM 级别的 STATISTICS_LEVEL 参数为 ALL 导致数据库性能下降** **简介:** 数据库性能骤降至正常水平的百分之一,主要表现为大量 free buffer wait 等待事件。原因是系统级别 STATISTICS_LEVEL 被误设为 ALL。解决方法是将其恢复为默认值 TYPICAL,执行命令:`ALTER SYSTEM SET statistics_level='TYPICAL' SCOPE=BOTH;` 以恢复正常性能。
|
3月前
|
Cloud Native 关系型数据库 分布式数据库
刷新世界纪录!阿里云登顶全球数据库性能及性价比排行榜
阿里云PolarDB云原生数据库在TPC-C测试中登顶全球性能及性价比排行榜。此次突破展示了PolarDB在单核性能、横向扩展及软硬件结合上的创新,标志着中国基础软件的重大成就。
|
3月前
|
Cloud Native 关系型数据库 分布式数据库
世界第一!阿里云PolarDB登顶全球数据库性能及性价比排行榜!
2月26日,阿里云PolarDB在2025开发者大会上登顶全球数据库性能及性价比排行榜。此次突破标志着中国基础软件取得里程碑成就,PolarDB凭借创新的云原生架构,成功应对全球最大规模并发交易峰值,在性能、可扩展性等方面领先全球。
|
2月前
|
存储 NoSQL MongoDB
从 MongoDB 到 时序数据库 TDengine,沃太能源实现 18 倍写入性能提升
沃太能源是国内领先储能设备生产厂商,数十万储能终端遍布世界各地。此前使用 MongoDB 存储时序数据,但随着设备测点增加,MongoDB 在存储效率、写入性能、查询性能等方面暴露出短板。经过对比,沃太能源选择了专业时序数据库 TDengine,生产效能显著提升:整体上,数据压缩率超 10 倍、写入性能提升 18 倍,查询在特定场景上也实现了数倍的提升。同时减少了技术架构复杂度,实现了零代码数据接入。本文将对 TDengine 在沃太能源的应用情况进行详解。
74 0
|
3月前
|
Cloud Native 关系型数据库 分布式数据库
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
|
4月前
|
缓存 关系型数据库 MySQL
【深入了解MySQL】优化查询性能与数据库设计的深度总结
本文详细介绍了MySQL查询优化和数据库设计技巧,涵盖基础优化、高级技巧及性能监控。
1020 1

热门文章

最新文章