网站测试用例实例seo优化好做吗
目录
硬件失效
管理负载
避免竞争
统计信息
识别问题
调整统计
优化分布
优化设计
硬件失效
数据库的性能取决于它所运行的硬件基础设施。数据库由多台服务器（主机）构成，它们作为一个紧密的系统（阵列）一起工作。 作为诊断性能的第一步，应确保所有的数据库的实例都在线。数据库的性能将和阵列中最慢的那一台主机相同。 CPU利用、内存管理、I/O处理或者网络负 载方面的问题都会影响性能。常见的与硬件相关的问题有：
- 磁盘失效：尽管在使用RAID时单一磁盘失效不会剧烈的影响数据库性能，但磁盘重新同步确实会在有失效磁盘的主机上消耗资源。 gpcheckperf 工具可以帮助发现有磁盘I/O问题的主机
- 磁盘容量：主机上的磁盘容量应该永远不超过70%。数据库需要一些空闲空间来做运行时处理。 要回收已删除行占用的磁盘空间，可以在装载或者更新后运行VACUUM
- 主机失效：当一台主机离线时，该主机上的实例就不可操作。这意味着其他主机必须执行两倍于它们通常的负载。如果没有启用镜像，服务就会中断。为恢复失效的实例也需要临时中断服务
- 网络失效：一块网卡、一台交换机或者DNS服务器的失效都可能让实例宕掉。 如果在集群中无法解析主机名或者IP地址，这就表明是数据库中的Interconnect错误。 gpcheckperf可以帮助发现出现网络问题的主机
管理负载
一个数据库系统的CPU容量、内存和磁盘I/O资源是有限的。当多个负载竞争访问这些资源时，数据库性能就会受到影响。 负载管理能在符合多变的业务需求的同时最大化系统吞吐。数据库提供了资源队列和资源组来协助管理这些系统资源。资源队列和资源组限制了特定队列或组的资源使用量和并行查询总数，管理员可以控制并行用户查询，防止系统过载。数据库管理员应该在业务时段之后运行维护负载，例如数据装载和VACUUM ANALYZE操作， 不要与数据库用户竞争系统资源，在低使用率时段执行管理任务。
避免竞争
当多个用户或者负载尝试以冲突的方式使用系统时，竞争就会发生。例如，当两个事务尝试同时更新一个表时会发生竞争。 一个寻求表级或行级锁的事务将无限等待冲突的锁被释放。应用不应该保持事务打开很长时间，例如，在等待用户输入时。
统计信息
数据库使用一种依赖于数据库统计信息的基于代价的查询优化器。准确的统计信息让查询优化器更好地估计一个查询检索的行数， 以便选择最有效的查询计划。如果没有数据库统计信息，查询优化器就不能估计将返回多少记录。优化器并不假设它有足够多的内存来执行特定的操作， 例如聚集，因此它会采取最保守的行动并且通过读写磁盘来做这些操作。这比在内存中做要慢很多。ANALYZE 会收集查询优化器需要的数据库相关的统计信息。
识别问题
在使用EXPLAIN 或 EXPLAIN ANALYZE解释一个查询的计划之前，先熟悉一下有助于帮助发现统计信息问题的数据。在计划中检查下列不准确统计信息的指示器：
- 优化器的估计接近于现实吗？ 运行 EXPLAIN ANALYZE 并且看看优化器估计的行数是否和查询操作返回的行数接近
- 优化器是否选择了最好的连接顺序？在一个查询连接多个表时，确保优化器选择最具选择性的连接顺序。消除行数最多的连接应该在计划中被最早执行，这样会有较少的行在计划树中向上移动
- 计划中是否比较早地应用了选择性谓词？最具选择性的过滤条件应该在计划中早早地被应用，这样会有较少的行在计划树中向上移动
调整统计
下列配置参数控制统计信息收集采样的数据量。 default_statistics_target参数控制系统层面的统计信息采样。最好只对查询谓词中最频繁使用的列采样增加的统计信息。 用户可以对一个特定的列采用下面的命令调整统计信息，例如：
ALTER TABLE sales ALTER COLUMN region SET STATISTICS 50;这等效于为特定列增加default_statistics_target。后续的ANALYZE操作接着将为该列收集更多统计数据并且结果就是会产生更好的查询计划。
优化分布
当用户在数据库中创建一个表时，用户必须声明一个分布键，它允许在系统中所有的实例上均匀地分布数据。 因为实例会以并行的方式工作在查询上，数据库将总是和最慢的实例速度相同。 如果数据不平衡，拥有更多数据的实例将更慢地返回它们的结果，因此会拖慢整个系统。
优化设计
很多性能问题可以通过数据库设计改进。检查用户的数据库设计并且考虑以下几点：
- 模式是否反映了数据被访问的方式？
- 较大的表是否能被分解成分区？
- 是否在使用尽可能小的数据类型来存储列值？
- 用于连接表的列是否为相同的数据类型？
- 索引有没有被使用？