标签: database-performance

我的查询问题需要17秒才能执行(350k行):

SELECT idgps_unit, MAX(dt) 
         FROM gps_unit_location
        GROUP BY 1

说明

1   SIMPLE  gps_unit_location   index       fk_gps2 5       422633  

玩完之后,我带来了这个需要1秒的解决方案:

Select idgps_unit, MAX(dt) from (
SELECT idgps_unit,  dt
         FROM gps_unit_location
) d1
Group by 1

说明:

1   PRIMARY <derived2>  ALL                 423344  Using temporary; Using filesort
2   DERIVED gps_unit_location   index       gps_unit_location_dt_gpsid  10      422617  Using index

现在我很困惑 - 为什么查询#2很快,而查询#1似乎是相同的查询,似乎写得更有效率.

Index1:DT,Index2:idgps_unit,Index3:idgps_unit + DT

执行时间是一致的; 查询#1总是需要17-19秒; 而#1 <1秒.

我正在使用Godaddy VPS Windows Server 2008经济版

表格示例:

id | idgps_unit | dt | location
1 | 1 | 2012-01-01 …

我知道这是一个常见的问题，我已经阅读了其他几篇文章和论文，但是找不到结合索引字段和两个查询都可以返回的记录量的文章。

我的问题确实很简单。在此建议以类似于SQL的语法（就性能而言）编写两者中的哪一个。

第一个查询：

Select *
from someTable s
where s.someTable_id in
                    (Select someTable_id 
                     from otherTable o
                     where o.indexedField = 123)

第二个查询：

Select *
from someTable
where someTable_id in
                  (Select someTable_id 
                   from otherTable o
                   where o.someIndexedField = s.someIndexedField
                   and o.anotherIndexedField = 123)

我的理解是，第二个查询将查询数据库，查询外部查询将返回的每个元组，第一个查询将首先评估内部选择，然后将过滤器应用于外部查询。

现在，考虑到对someIndexedField字段建立了索引，第二个查询可能会超快地查询数据库，但是说我们有成千上万个记录，那么使用第一个查询不是更快吗？

注意：在Oracle数据库中。

NewRelic提供了很好的数据库分析，但是它似乎只跟踪Web应用程序的事务。

我有独立管理的服务器，用于查询和加载我的Heroku postgresql数据库。有没有一种方法可以对数据库活动进行诊断和分析，以使其包括与数据库活动的所有连接？

查询在具有1,100万行的大型表上执行.我已经ANALYZE在查询执行之前在表上执行了一个.

查询1:

SELECT *
FROM accounts t1
LEFT OUTER JOIN accounts t2 
    ON (t1.account_no = t2.account_no
        AND t1.effective_date < t2.effective_date)
WHERE t2.account_no IS NULL;

解释分析:

Hash Anti Join  (cost=480795.57..1201111.40 rows=7369854 width=292) (actual time=29619.499..115662.111 rows=1977871 loops=1)
  Hash Cond: ((t1.account_no)::text = (t2.account_no)::text)
  Join Filter: ((t1.effective_date)::text < (t2.effective_date)::text)
  ->  Seq Scan on accounts t1  (cost=0.00..342610.81 rows=11054781 width=146) (actual time=0.025..25693.921 rows=11034070 loops=1)
  ->  Hash  (cost=342610.81..342610.81 rows=11054781 width=146) (actual time=29612.925..29612.925 rows=11034070 loops=1)
        Buckets: 2097152  Batches: 1  Memory Usage: 1834187kB
        ->  Seq Scan on …

我们有一个由SQL Server数据库支持的Web应用程序.

到目前为止,我们一直在使用SQL成员资格提供程序进行应用程序级别登录.对SQL Server的后端调用在Web.config的连接字符串中使用单个SQL帐户

我们客户的新合规性要求规定,所有应用程序用户必须在后台拥有自己的专用SQL帐户.

我已经将它原型化了,并且有一个工作版本.应用程序中的数据库连接上下文是为每个会话的当前用户配置的,在后台有SQLMembership帐户 - > DatabaseUser - > Sql Server Login之间的映射.密码可以计算为SQLMembership User Guid的SHA1哈希值.

这一切都运行正常,但我想知道由于拥有1000个服务器登录,数据库用户(+所有GRANT权限),数据库是否有任何性能考虑因素.

我有一个销售数据库,我想根据这些类别选择获取客户详细信息.我有大约15个类别,我的客户数据库是500万条记录.每种产品可能属于多个类别.我需要根据所选的类别检索客户名称.将所有这些类别作为列或为产品和类别创建单独的表然后内部联接是更好的方法吗？我想在性能方面哪一个是更好的方法.

方法1:

这里1表示该产品属于该类别.

方法2:

我有一个复杂的查询，它使用大量的二进制校验和函数，当我用两个不同记录的一些测试数据对其进行测试时，实际上返回了相同的校验和值。请在下面找到我使用的测试数据

SELECT BINARY_CHECKSUM(16   ,'EP30461105',1) AS BinaryCheckSumEx UNION ALL
SELECT BINARY_CHECKSUM(21   ,'EP30461155',1) AS BinaryCheckSumEx

现在，我正在尝试将HASHBYTES函数与“ MD5”算法一起使用，可以肯定地为其获取唯一记录，但是现在让我担心的是，在当前查询中，我使用“校验和”值来加入“合并”语句寻找新记录。由于“ HashBytes”返回我Varbinary数据类型，所以当我用“ HashByte”字段替换联接条件时，可以期望多少性能开销。

SELECT HASHBYTES('MD5', CONCAT(Col1,Col2,Col3,Col4,..))

而且，我需要为多个列创建哈希，在这种情况下，我需要具有一个额外的Concat函数，这会对我的性能产生额外的开销。

我真的很难优化这个查询:

SELECT wins / (wins + COUNT(loosers.match_id) + 0.) winrate, wins + COUNT(loosers.match_id) matches, winners.winning_champion_one_id, winners.winning_champion_two_id, winners.winning_champion_three_id, winners.winning_champion_four_id, winners.winning_champion_five_id
FROM
(
   SELECT COUNT(match_id) wins, winning_champion_one_id, winning_champion_two_id, winning_champion_three_id, winning_champion_four_id, winning_champion_five_id FROM matches
   WHERE
      157 IN (winning_champion_one_id, winning_champion_two_id, winning_champion_three_id, winning_champion_four_id, winning_champion_five_id)
   GROUP BY winning_champion_one_id, winning_champion_two_id, winning_champion_three_id, winning_champion_four_id, winning_champion_five_id
) winners
LEFT OUTER JOIN matches loosers ON
  winners.winning_champion_one_id = loosers.loosing_champion_one_id AND
  winners.winning_champion_two_id = loosers.loosing_champion_two_id AND
  winners.winning_champion_three_id = loosers.loosing_champion_three_id AND
  winners.winning_champion_four_id = loosers.loosing_champion_four_id AND
  winners.winning_champion_five_id = loosers.loosing_champion_five_id
GROUP BY winners.wins, winners.winning_champion_one_id, winners.winning_champion_two_id, winners.winning_champion_three_id, winners.winning_champion_four_id, …

我有一个简单的查询，例如select * from xxx where col is not null limit 10。我不知道为什么Postgres更喜欢seq扫描，它比部分索引要慢得多（我已经分析了表格）。如何调试这样的问题？

该表有超过400万行。并满足了约350,000行pid is not null。

我认为成本估算可能有问题。seq扫描的成本低于索引扫描。但是如何深入研究呢？

我有一个猜测，但不确定。非空行约占总行的10％。这意味着当seq扫描100行时，它可能会得到10行，这些行不为空。并且它认为seq扫描100行的成本低于索引扫描10行，然后随机获取10整行的成本。是吗？

> \d data_import
+--------------------+--------------------------+----------------------------------------------------------------------------+
| Column             | Type                     | Modifiers                                                                  |
|--------------------+--------------------------+----------------------------------------------------------------------------|
| id                 | integer                  |  not null default nextval('data_import_id_seq'::regclass) |
| name               | character varying(64)    |                                                                            |
| market_activity_id | integer                  |  not null                                                                  |
| hmsr_id            | integer                  |  not null default (-1)                                                     |
| site_id            | integer                  |  not null default (-1)                                                     |
| hmpl_id …

我遇到了一个与PostgreSQL查询类似的问题，但限制为1的速度非常慢，而带ORDER和LIMIT子句的PostgreSQL 速度非常慢，尽管在我的情况下，是否LIMIT为1、5或500 都没有关系。

基本上，当我无限制地运行由Django的ORM生成的查询时，该查询花费了半秒钟，但有限制（为分页而增加）则需要7秒钟。

耗时7秒的查询是：

SELECT "buildout_itemdescription"."product_code_id",
         MIN("buildout_lineitem"."unit_price") AS "min_price"
FROM "buildout_lineitem"
INNER JOIN "buildout_itemdescription"
    ON ("buildout_lineitem"."item_description_id" = "buildout_itemdescription"."id")
WHERE (("buildout_lineitem"."report_file_id" IN (154, 172, 155, 181, 174, 156, 157, 182, 175, 176, 183, 158, 177, 159, 179, 178, 164, 180, 367, 165, 173, 166, 167, 168, 368, 422, 370, 169, 1335, 1323, 161, 160, 162, 170, 171, 676, 151, 163, 980, 152, 369, 153, 963, 1718, 881, 617, 1759, 1780, …