faiss数据库（faiss数据库不适用生产环境吗）



通过上一节收集的数据组合在一起，并经过分析阶段，制定出对索引的创建、删除、修改方案，然后在实施阶段进行部署

主要关注下面几个部分：

1.审查服务器状态

2.未使用索引

3.索引计划使用

一：审查服务器状态

1.性能计数器

2.等待信息

3.Buffer分配

创建一个堆表，插入数据，并更新其中一些数据，引发堆分页，最后执行上面的查询检查情况

当Forwarded Records发生，再次执行代码

如果存在Forward Records问题，通常有3种解决方案

1.更改数据类型，把变长改成定长，如varchar-char，不够这种情况可能不是很通用，而且可能伴随数据截断等问题

2.改变表的存储结构，也就是创建一个聚集索引在上面，从而移除堆表的组织数据机制

3.就是重建堆表

2.Access MethodsFreeSpace Scans/sec（关于堆表的另一个计数器）

当在堆表中插入数据时，他会标识发生了什么操作，在插入过程中，可能会引起GAM、SGAM和PFS页的改动。如果插入的频率足够高，可能会在这些页上产生争用

通过汇总最小值、平均值和最大值来进行分析

如果FreeSpace Scans/sec很高，应该集中分析哪个堆有最高的插入数率。可以使用：sys.dm_db_index_operational_stats来查找

在查找到根源之后，最好的方法就是加上聚集索引，改变其数据组织机制

3.Access MethodsFull Scans/sec,通过这个计数器可查看Full Scans/sec的值，这个值包含聚集、非聚集索引及堆表。高值意味着查询存在性能问题，这种情况可能会引起Page Life Expectancy（用于衡量内存压力的一个主要计数器）的变动，这将加大数据在内存中的存储时间，并引起I/O问题

下面的脚本用于分析当前Full Scans/sec的值，同样也需要考虑Batch Requests/sec 计数器，如果这两个值的比例超过1000，就需要引起注意

4. Access MethodsIndex Searches/sec,大部分情况下，索引查找会比索引扫描有效，这个计数器显示SQL Server 实例上发生索引查找的比率，这个值相对于Full Scans/sec来说越高越好。这个比率是衡量索引是否有效的标准之一，这两个值的比率一般是1000:1

5.Access MethodsPage Splits/sec 对于堆表上的Forwarded Records，聚集索引上的就是Page Splits，没有聚集索引的表就是堆表，堆表上的非聚集索引还是使用的Forwarded Records。Page Splits是一个比较消耗资源的操作，而且在拆页的时候会对原来的页加上排他锁，并且会产生碎片，所以应尽可能少用。下面的脚本用于汇总这方面的数据，一般的建议是每20个Batch Requests/sec 不应该多于一个Page Split/sec 即Batch Requests：Page Split应该接近20:1

6.Buffer ManagerPage Lookups/sec用于衡量实例中的请求在buffer pool里面查询的单独页数量。这个数值很高时，可能意味着不高效的执行计划，通常需要研究该执行计划。一般数值很高是因为执行计划中产生了大量的Page Lookups和Row Lookups。通常情况下，每个Batch Request/sec不应该超过100次这类的lookups

以下脚本通过对比Page Lookups/sec 和Batch Request/sec来初始化数据，包括最小值、最大值和平均值。

7.Locks(*)Lock Wait Time(ms).这类计数器更偏重于检查索引的压力情况。可以衡量SQL Server花在索引、表、页上锁资源的时间。没有可参考的值，但是可以作为历史数据，然后用最近监控的数据和这个历史数据对比，比值应该越低越好。

用下面的脚本来监控该计数器的值，以便建立一个基准

由于锁通常具有实时性、易丢失性，所以这部分的监控可能需要稍微加大频率，并且做好历史记录。

8。Locks(*) NUmber of Deadlocks/sec。极端的情况下，不良的索引设计和过渡锁阻塞会引起死锁（Deadlocks），这种情况是绝对不能容忍的，可以使用下面的脚本监控并研究起因、解决方案

（2）

Buffer分配

查看数据库中使用了多少内存的Buffer，具体数量可能不重要，但是对比不同数据库中的比例情况就很重要

可以通过sys.dm_os_buffer_descriptors来检查，这个DMV会显示在内存中的每个数据页，以及其中的信息，并且通过计算显示出每个库所使用的Buffer情况

查看什么库使用了最多的Buffer，还可以改进一下，用它来查看占用了内存最多的表或者索引

2.无用索引

对于索引分析，其中一个重要的部分是移除无用索引,因为索引是有成本的，包括存储成本和修改成本，所以没有被用过的索引应该去除，一直都没有用户操作使用过的索引，由于某些索引是用于维护数据的一致性的，因此可能也会没有用户操作发生在上面。下面的脚本用于查找无用索引。

以上的脚本可能会把主键查出来，主键主要用于维护数据行的可表示性

3.索引计划使用：

用于查看多少个查询中使用了特定索引的所有执行计划，只需要替换脚本中的执行计划@IndexName。

通过增加物理操作符的名称来定位

通过这些脚本定位可能有问题的执行计划，通过执行计划分析得出解决方案

找出使用频率最高的20%的查询

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/rgzn-aibigd/44078.html