解决delete后查询的性能有关问题，怎么清理碎片，降低高水位

解决delete后查询的性能问题，如何清理碎片，降低高水位？

对于oracle，我知道delete后高水位不会下降，也就是说对于查询性能影响比较大。

对于sqlserver，是否也有这种问题？如果降低高水位。导入导出肯定可以，但是对于在线系统，而且delete都是按条件删的。如何解决由于插入删除后的查询性能问题呢？

请大师们指点。谢谢！

[解决办法]

删除少量数据应该没有什么影响，默认数据库会自动计算

如果是执行大量的删除、修改的，重新索引整理就可以了

[解决办法]

这样的东西应该不用考虑吧

[解决办法]

删除后立即COMMIT

[解决办法]

查看一下索引碎片,整理索引

[解决办法]

关注一下!!

[解决办法]

关注~

[解决办法]

一般来说,碎片情况如果严重的话,可以整理或者重建一下聚集索引,其他索引会一起更新

[解决办法]

delete 或 update 后，会使索引的物理位置不连续，要解决这个问题

定期用dbcc 清理碎片或重新建立索引

注意，有时清理碎片的时间可能会比后面的 *** 作还要费时

[解决办法]

学习

[解决办法]

聚集索引都整理好了，还理会什么表啊？

与聚集索引的情况下，数据存储是依赖聚集索引来存储的

[解决办法]

数据库维护计划里面有重新组织索引和重新整理索引

可以定一个计划每周执行一个，将指定的数据库或某个表下面所有的索引重新整理一次

一般索引碎片是由于

update/delete/insert *** 作，收缩文件，填充因子不合理，索引键设计不合理等造成的。

如果按照楼主说的，你可以定位一下究竟是什么原因造成的。系统是否频繁执行update/delete/insert *** 作，收缩文件之类的。另外索引的设计不合理这个也得重视。

重建后的索引，应该不包含碎片的。如果还有碎片，很有可能是因为文件系统的碎片导致。

如果你是用windows系统的本地磁盘，是很有可能出现这种问题的。

尝试做一次磁盘碎片整理。有可能会缓解这个问题。

当然，如果你是挂载的其他存储设备，以上推论无效。

另外，关于视图查询不出来的问题，先确定一下是不是sql性能问题。

比如你的sql里面是否用了适合的索引，还有就是sql是否过于复杂了？

一般来说如果是比较好的sql，不会因为索引的碎皮问题，导致查不出结果的。

当索引的碎片过多时，会影响执行查询的速度，从而影响到我们的工作效率。这时候采取的最有利的措施莫过于重建索引了。本文主要介绍了Oracle数据库中检查索引碎片并重建索引的过程，接下来我们就开始介绍这一过程。重建索引的步骤如下：1 确认基本信息登入数据库，找到专门存放index 的tablespace，并且这个tablespace下所有index的owner都是tax将index专门存放在一个独立的tablespace, 与数据表的tablespace分离，是常用的数据库设计方法。height >4 pct_used < 50% del_lf_rows / lf_rows +0001 > 003 g )3 google上下载了遍历所有index脚本发现anlyze index validate structure只能填充单个index分析信息，于是google了下，从网上下了个Loop 脚本，遍历索引空间下所有的索引名字，并且可以把所有index的分析信息存放到自己建立的一个用户表中。4 anlyze index 锁定index发现下载的脚本不好用，应为anlyze index在分析索引前要争取独占锁，锁住index，很明显有些index正在被应用系统的使用，所以运行anlyze失败。这里吸取的教训是，尽量晚上做这种事。但是本人比较喜欢准时回家，所以在语句中添加Exception Handler，抛出anlyze index执行失败的那些index 名称，使脚本正常运行完毕。并且根据打印到前台的index name手动执行那些index分析。5 总结虽然发现522个index中有160个符合上面的判断的依据。但是发现索引都不大，而那些拥有百万leaf的索引又没有符合上面的判断条件，所以结论是无需index rebuild online 没有啥碎片。rebuild index online，对那些有大量DML *** 作的大索引是有益的。可以每个月季度做一次针对较大索引的rebuild。通常哪怕rebuild index online也会造成I/O争用，所以有无online意义不大，可以放到３－５个晚上，分批执行rebuild index，锁定index，不让用户用（没有用户等入的时候），并且加上paralle 8关键字，应为发现数据库服务器有8个cpu processors

会影响的，数据字典是oracle存储关键信息的表和视图的集合。oracle进程会在sys模式中维护这些表和视图，也就是说数据字典的所有者为sys用户，数据存放在system表空间中，数据字典描述了实际数据是如何组织的，如一个表的创建者信息，创建时间信息，所属的表空间信息，用户访问权限等等。对数据字典可以向处理其他数据库和表或试图一样进行查询，但不能进行任何修改。

oracle数据字典通常是在创建和安装数据库时被创建的。oracle数据字典是oracle数据库系统工作的基础。没有数据字典的支持，oracle数据库系统就不能进行任何工作。

以MySQL为例，碎片的存在十分影响性能

MySQL 的碎片是 MySQL 运维过程中比较常见的问题，碎片的存在十分影响数据库的性能，本文将对 MySQL 碎片进行一次讲解。

判断方法：

MySQL 的碎片是否产生，通过查看

show table status from table_nameG;

这个命令中 Data_free 字段，如果该字段不为 0，则产生了数据碎片。

产生的原因：

1 经常进行 delete *** 作

经常进行 delete *** 作，产生空白空间，如果进行新的插入 *** 作，MySQL将尝试利用这些留空的区域，但仍然无法将其彻底占用，久而久之就产生了碎片；

演示：

创建一张表，往里面插入数据，进行一个带有 where 条件或者 limit 的 delete *** 作，删除前后对比一下 Data_free 的变化。

删除前：

删除后：

Data_free 不为 0，说明有碎片；

2 update 更新

update 更新可变长度的字段(例如 varchar 类型)，将长的字符串更新成短的。之前存储的内容长，后来存储是短的，即使后来插入新数据，那么有一些空白区域还是没能有效利用的。

演示：

创建一张表，往里面插入一条数据，进行一个 update *** 作，前后对比一下 Data_free 的变化。

CREATE TABLE `t1` ( `k` varchar(3000) DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

更新语句：update t1 set k='aaa';

更新前长度：223 Data_free：0

更新后长度：3 Data_free：204

Data_free 不为 0，说明有碎片；

产生影响：

1 由于碎片空间是不连续的，导致这些空间不能充分被利用；

2 由于碎片的存在，导致数据库的磁盘 I/O *** 作变成离散随机读写，加重了磁盘 I/O 的负担。

清理办法：

MyISAM：optimize table 表名；（OPTIMIZE 可以整理数据文件,并重排索引）

Innodb：

1 ALTER TABLE tablename ENGINE=InnoDB；(重建表存储引擎，重新组织数据)

2 进行一次数据的导入导出

碎片清理的性能对比：

引用我之前一个生产库的数据，对比一下清理前后的差异。

SQL执行速度：

select count() from testtwitter_11;

修改前：1 row in set (737 sec)

修改后：1 row in set (128 sec)

结论：

通过对比，可以看到碎片清理前后，节省了很多空间，SQL执行效率更快。所以，在日常运维工作中，应对碎片进行定期清理，保证数据库有稳定的性能。

以上就是关于解决delete后查询的性能有关问题，怎么清理碎片，降低高水位全部的内容，包括:解决delete后查询的性能有关问题，怎么清理碎片，降低高水位、数据库索引重建之后，碎片率再次提高、sql2005 表中索引碎片总计66+%，优化问题，，，等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！