云服务器内容精选

  • 处理步骤 通过下列的操作步骤,可以分析出查询效率异常降低的原因。 使用ANALYZE命令分析数据库。 ANALYZ命令更新所有表中数据大小以及属性等相关统计信息,该命令为轻量级,可以经常执行。如果此命令执行后性能恢复或者有所提升,则表明autovacuum未能很好的完成它的工作,有待进一步分析。 检查查询语句是否返回了多余的数据信息。 例如,如果查询语句先查询一个表中所有的记录,而只用到结果中的前10条记录。对于包含50条记录的表,查询起来是很快的;但是,当表中包含的记录达到50000条,查询效率将会有所下降。 若业务应用中存在只需要部分数据信息,但是查询语句却是返回所有信息的情况,建议修改查询语句,增加LIMIT子句来限制返回的记录数。这样至少使数据库优化器有了一定的优化空间,一定程度上会提升查询效率。 检查查询语句单独运行时是否仍然较慢。 尝试在数据库没有其他查询或查询较少的时候运行查询语句,并观察运行效率。如果效率较高,则说明可能是由于之前运行数据库系统的主机负载过大导致查询低效。此外,还可能是执行计划比较低效,但是由于主机硬件较快使得查询效率较高。 检查相同查询语句重复执行的效率。 查询效率低的一个重要原因是查询所需信息没有缓存在内存中,这可能是由于内存资源紧张,缓存信息被其他查询处理覆盖。 重复执行相同的查询语句,如果后续执行的查询语句效率提升,则可能是由于上述原因导致。
  • 原因分析 请先判断同名的表是否确实是同一张表。在关系型数据库中,确定一张表通常需要3个因素:database,schema,table。从问题现象描述看,database,table已经确定,分别是human_resource、areas。接着,需要检查schema。使用dbadmin,user01分别登录发现,search_path依次是public和"$user"。dbadmin作为集群管理员,默认不会创建dbadmin同名的schema,即不指定schema的情况下所有表都会建在public下。而对于普通用户如user01,则会在创建用户时,默认创建同名的schema,即不指定schema时表都会创建在user01的schema下。最终确定该案例发生时,确实因为2个用户之间交错对表进行操作,导致了同名不同表的情况。