有一个对数据库疑惑的问题,场景如下
有一个项目,大概跑了两年数据量比较大,偶尔会出现系统效率响应变慢的情况。
由于现场不能停工,第一反应是不是历史数据太大了,使用存储过程,分批把历史数据删除剩下几百万。
发现两个模块都慢,最终分析代码发现两个模块都调用了一个方法。方法执行的 sql 如下:
怀疑可能是 UNION 走了全表导致的,然后加了如下索引
CREATE INDEX IX_STATUS_WCSSOURCE ON TTT(STATUS, WCSSOURCE);
系统就正常了。
但是没搞懂的是,为什么清除历史数据了还是慢,而且期间运行了几年也没有卡顿。
备注:使用的是删除,主键此时还是比较大的数值
最简单的处理方法 ,explain plan ,看下 SQL 的执行计划。
这个组合索引并不优,不如分开建索引。
换成临时表都比 union 快
表要做碎片整理吧
这个表名起的
感谢,主要不能理解的是为什么数据量不大,查询也会有影响
能详细说一下吗?
表名是我替换了的,防止被同事看到
主要不能理解的是为什么数据量不大,查询也会有影响
sql 查询已经进行优化了,但是没理解的是为什么数据量不大也会受影响,之前都是正常运行的
你这个也不放个 explain plan ,我们表结构索引都不知道,怎么给你看么
union 一般来说包含两个操作 select 和 distinct 。 你可以试试 union all 。
并且你要是执行的是 del,表空间没有释放,你尝试新建个表,把数据倒进去,再执行这个 sql 试试
#6 他的意思可能是,数据虽然删除了,但是磁盘文件的对应空间并没有回收然后重写让剩下的数据在一起,那么此时查询数据库从磁盘读取数据时,每次读取依然只能读取的非常少的条数,读取磁盘的次数和数据量并没有显著降低,那么查询性能自然也不会有很大提升,不过如果你是时间有序数据,只是删除更早以前的数据,那这个问题影响应该不会很大吧
这个我当时也考虑了的,把相关数据删除之后,使用数据库文件收缩把,空间回收了的
好的,感谢由于事态比较紧急,处于夜间突发,所以当时没有考虑太多,只是尝试性加了一下索引,下次尝试这个思路试一下
数据删除后,存储空间会碎片化,可以 coalesce 合并一下;同理 index 的节点也有类似的问题,可以 rebuid 一下,你会发现空间释放出来很多。
真没必要太多猜测和尝试,正如一楼所说的,数据库性能
真没必要太多猜测和尝试,正如一楼所说的,explain plan ,看下 SQL 的执行计划,基本就能定位数据库性能问题。
对的同意楼上,不要猜测,看下执行计划。数据库做的这方面还是很好的
t.,x.这种写法要改正
sql 优化的问题,一定要贴执行计划
优化的两个重要原则 1 建立高效索引 2 避免回表
我们有一组记录: list_records = ( (department, name, salary), (department, name, salary), ...…
从1980年到现在,我们的科技到底进步了多少:) 下面这个图说明了1980年大机的1GB的内存和2009年的1GB的内存。 转载于酷壳CoolShell 无删改 仅以此纪念陈…
分区开启 BitLocker 后还能正常用第三方备份工具备份和还原吗? 比如上古神器 Ghost ,傲梅的备份助手,或者基于 Diskgenius 的易数一键还原 可以 基…