重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
无论哪一种数据库,只要数据量不断增大都会逐渐变慢,有时候数据到一个量级
曹县网站制作公司哪家好,找成都创新互联!从网页设计、网站建设、微信开发、APP开发、响应式网站等网站项目制作,到程序开发,运营维护。成都创新互联于2013年创立到现在10年的时间,我们拥有了丰富的建站经验和运维经验,来保证我们的工作的顺利进行。专注于网站建设就选成都创新互联。
速度会断壁式下跌。
一般是直接从表查询快。已经是索引列了。但是第一个查询如果数据不存在还是要遍历其他的表。这样速度就大打折扣了。
如果能保证数据一定在指定表中就是第一个快了。
大体分为如下几种情况会逆袭:
1、这个就是数据不存在,如果挨个遍历表,速度可能不如使用视图。
2、使用索引视图技术,这个跟使用表查询速度相差不大。
3、sqlserver是高级版本,可以发挥多CPU优势,这个时候速度也相差不大。
4、索引碎片过多集中在的某三四个表以上,这时候性能都比较沮丧。
看如上,因为我这个是32核CPU,多并行几个时间只是略多一点,如果单表查询,那么执行计划就是一个分支。
在安装有SQLServer数据库的计算机上,我们在使用数据库的过程中,有时候会在任务管理器里发现sqlservr.exe这个进程的内存和CPU占用率较高。
接下来我们来看一下,如何解决上面这个问题,需要设置SQLServer数据库的内存配置。登录数据库,这里使用的是SQLServer2008,右键点击最上方的服务器名,在弹出的菜单中,点击【属性】
打开服务器属性窗口。默认显示的是第一项【常规】内容,点击第二项【内存】进行内存配置。
点击【内存】后,打开服务器内存选项配置界面。这里的【使用AWE分配内存】可以对内存进行扩展支持,我们要做的是更改下方的最大服务器内存。这个数值根据自己服务器内存大小来做适当设置。
5
个人建议设置本机内存的一半或稍微高一点,如机器内存为2G,那么我们这里填写1000。需要注意的是内存设置调小以后,在数据库执行较复杂SQL语句的时候,可能会比较慢,出现这种情况,我们再适当上调最大内存配置大小。
1. 执行计划中明明有使用到索引,为什么执行还是这么慢?
2. 执行计划中显示扫描行数为 644,为什么 slow log 中显示 100 多万行?
a. 我们先看执行计划,选择的索引 “INDX_BIOM_ELOCK_TASK3(TASK_ID)”。结合 sql 来看,因为有 "ORDER BY TASK_ID DESC" 子句,排序通常很慢,如果使用了文件排序性能会更差,优化器选择这个索引避免了排序。
那为什么不选 possible_keys:INDX_BIOM_ELOCK_TASK 呢?原因也很简单,TASK_DATE 字段区分度太低了,走这个索引需要扫描的行数很大,而且还要进行额外的排序,优化器综合判断代价更大,所以就不选这个索引了。不过如果我们强制选择这个索引(用 force index 语法),会看到 SQL 执行速度更快少于 10s,那是因为优化器基于代价的原则并不等价于执行速度的快慢;
b. 再看执行计划中的 type:index,"index" 代表 “全索引扫描”,其实和全表扫描差不多,只是扫描的时候是按照索引次序进行而不是行,主要优点就是避免了排序,但是开销仍然非常大。
Extra:Using where 也意味着扫描完索引后还需要回表进行筛选。一般来说,得保证 type 至少达到 range 级别,最好能达到 ref。
在第 2 点中提到的“慢日志记录Rows_examined: 1161559,看起来是全表扫描”,这里更正为“全索引扫描”,扫描行数确实等于表的行数;
c. 关于执行计划中:“rows:644”,其实这个只是估算值,并不准确,我们分析慢 SQL 时判断准确的扫描行数应该以 slow log 中的 Rows_examined 为准。
4. 优化建议:添加组合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
优化过程:
TASK_DATE 字段存在索引,但是选择度很低,优化器不会走这个索引,建议后续可以删除这个索引:
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在这个 sql 中 REL_DEVID 字段从命名上看选择度较高,通过下面 sql 来检验确实如此:
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由于有排序,所以得把 task_id 也加入到新建的索引中,REL_DEVID,task_id 组合选择度 100%:
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在测试环境添加 REL_DEVID,TASK_ID 组合索引,测试 sql 性能:alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引后执行计划:
这里还要注意一点“隐式转换”:REL_DEVID 字段数据类型为 varchar,需要在 sql 中加引号:AND T.REL_DEVID = 000000025xxx AND T.REL_DEVID = '000000025xxx'
执行时间从 10s+ 降到 毫秒级别:
1 row in set (0.00 sec)
结论
一个典型的 order by 查询的优化,添加更合适的索引可以避免性能问题:执行计划使用索引并不意味着就能执行快。
索引没用好。sqlserver大表的条件多的时候,就必须使用组合索引来提升查询速度,不使用索引会导致查询复杂,就会变慢。
到网上找一个内存管理工具,对内存进行定时管理,比如你的机器从重启到内存被SQL占用完要1小时,你可以把时间设置成30-45分钟清理一清内存,也可能用自动的那种,可能30秒一次吧。
要不然把你的SQL占用内存设为固定值,可能是你物理内存的50%左右,看你的具体情况了
如何监控sqlserver 慢查询
1,slow_query_log
这个参数设置为ON,可以捕获执行时间超过一定数值的SQL语句。
2,long_query_time
当SQL语句执行时间超过此数值时,就会被记录到日志中,建议设置为1或者更短。
3,slow_query_log_file
记录日志的文件名。
4,log_queries_not_using_indexes
这个参数设置为ON,可以捕获到所有未使用索引的SQL语句,尽管这个SQL语句有可能执行得挺快。