标签: query-performance

我正在尝试优化查询，试图避免重复用“ COMPLEX QUERY ”指示的查询，该查询使用了两次，并且两次都有相同的结果。

原始查询

SELECT news.* 
FROM   news 
   INNER JOIN((SELECT myposter 
               FROM   (SELECT **COMPLEX QUERY**)) 
              UNION 
              (SELECT myposter 
               FROM   `profiles_old` prof2 
               WHERE  prof2.profile_id NOT IN (SELECT **COMPLEX QUERY**))) r 
           ON news.profile = r.p 

我想知道这样的事情是否可能：

SELECT news.* 
FROM   (SELECT **COMPLEX QUERY**) complexQuery, 
   news 
   INNER JOIN ((SELECT myposter 
                FROM   complexquery) 
               UNION 
               (SELECT myposter 
                FROM   `profiles_old` prof2 
                WHERE  prof2. profile NOT IN (SELECT myposter 
                                              FROM complexQuery))) r 
           ON news. profile = r.p 

Mysql 是否对该类型的查询进行某种缓存？

我们有以下 mysql 表（为了直奔主题而简化）

CREATE TABLE `MONTH_RAW_EVENTS` (
  `idEvent` int(11) unsigned NOT NULL,
  `city` varchar(45) NOT NULL,
  `country` varchar(45) NOT NULL,
  `ts` datetime NOT NULL,
  `idClient` varchar(45) NOT NULL,
  `event_category` varchar(45) NOT NULL,
  ... bunch of other fields
  PRIMARY KEY (`idEvent`),
  KEY `idx_city` (`city`),
  KEY `idx_country` (`country`),
  KEY `idClient` (`idClient`),
) ENGINE=InnoDB;

CREATE TABLE `compilation_table` (
  `idClient` int(11) unsigned DEFAULT NULL,
  `city` varchar(200) DEFAULT NULL,
  `month` int(2) DEFAULT NULL,
  `year` int(4) DEFAULT NULL,
  `events_profile` int(10) unsigned NOT NULL DEFAULT '0',
  `events_others` …

我不明白为什么有时一个计划的总成本可能很小，但查看计划内部我们会发现巨大的成本。（确实查询速度很慢）。

有人能给我解释一下吗？

这是一个例子。显然，成本较高的部分来自主选择中的一个字段，该字段在子视图上执行 listagg，并且该子视图的连接条件包含一个复杂的条件（我们可以在一个字段或另一个字段上连接）。

| Id  | Operation                                    | Name                      | Rows  | Bytes | Cost  |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                             |                           |     1 |   875 |    20 |
|   1 |  SORT GROUP BY                               |                           |     1 |   544 |       |
|   2 |   VIEW                                       |                           |     1 |   544 |     3 |
|   3 |    SORT UNIQUE                               |                           |     1 |   481 |     3 |
|   4 |     NESTED LOOPS                             |                           |       |       |       |
| …

聚类因子 - 关于如何计算它的一个很棒的简单解释：

基本上，CF 是通过执行完整索引扫描并查看每个索引条目的 rowid 来计算的。如果被引用的表块与前一个索引条目的表块不同，CF 就会递增。如果被引用的表块与前一个索引条目相同，则 CF 不会增加。因此，CF 指示表中数据相对于索引条目的有序程度（索引条目始终按索引条目的顺序排序和存储）。CF 越好（越低），使用索引的效率就越高，因为通过索引检索必要数据所需访问的表块更少。

我的指数统计：

所以，这是我正在分析的索引（仅一列的索引）。

索引开始PK_是我的主键，并且UI是唯一键。（当然两者都有独特的价值）

查询1：

SELECT index_name,
  UNIQUENESS,
  clustering_factor,
  num_rows,
  CEIL((clustering_factor/num_rows)*100) AS cluster_pct
FROM all_indexes
WHERE table_name='MYTABLE';

结果：

INDEX_NAME           UNIQUENES CLUSTERING_FACTOR   NUM_ROWS CLUSTER_PCT
-------------------- --------- ----------------- ---------- -----------
PK_TEST              UNIQUE             10009871   10453407          96 --> So High
UITEST01             UNIQUE               853733   10113211           9 --> Very Less

我们可以看到 PK 具有最高的 CF，而其他唯一索引则不是。

让我印象深刻的唯一合乎逻辑的解释是，下面的数据实际上是按唯一索引上的列顺序存储的。

1）我的这种理解正确吗？
2）有什么办法可以给出PK，最低的CF数字吗？
3）从使用这两个索引的查询成本来看，单选择的速度非常快。但 CF 数字仍然让我们困惑。

该表相对较大，超过 10M 记录，并且还接收实时插入/更新。

我的数据库版本是 Oracle 11gR2，基于 Exadata X2

我目前正在用 C# 构建一个网络爬虫。为了对尚未爬网的 URL 进行排队，我使用 SQL Server。它工作得非常快，但随着时间的推移它开始变得非常大，这会减慢我的存储过程。

CREATE TABLE PriorityQueue
(
ID int IDENTITY(0,1) PRIMARY KEY,
absolute_url varchar (400),
depth int,
priorty int,
domain_host varchar (255),
);

CREATE INDEX queueItem ON PriorityQueue(absolute_url);
CREATE INDEX queueHost ON PriorityQueue(domain_host);

这是我用于队列的表。优先级编号从 1 到 5，其中 1 是最高优先级。正如您所看到的，我还在下面的存储过程中使用了索引。

将新项目添加到队列的过程：

DROP PROCEDURE IF EXISTS dbo.Enqueue
GO
CREATE PROCEDURE dbo.Enqueue(@absolute_url varchar(255), @depth int, @priorty int, @host varchar(255))
AS
BEGIN
    INSERT INTO [WebshopCrawler].[dbo].[PriorityQueue] (absolute_url, depth, priorty, domain_host) VALUES (@absolute_url, @depth, @priorty, @host);
END
GO

获取最高优先级项目的过程：

DROP PROCEDURE IF …

我有以下查询：

SELECT *
FROM
(
    SELECT *,
        ROW_NUMBER() OVER(PARTITION BY Code ORDER BY Price ASC) as RowNum
    from Offers) r
where RowNum = 1

Offers 表包含大约 1000 万条记录。但是那里只有大约 4000 个不同的代码。所以我需要为每个代码获取价格最低的行，结果中只有 4000 行。

我在 INCLUDE 语句中有一个关于（代码、价格）列的索引以及所有其他列。

查询运行 2 分钟。如果我查看执行计划，我会看到具有 10M 实际行的索引扫描。所以，我猜它会扫描整个索引以获得所需的值。

为什么 MSSQL 要做全索引扫描？是因为子查询需要整个数据吗？如何避免这种扫描？是否有仅处理分区中第一行的 SQL 提示？

还有其他方法可以优化此类查询吗？

我在SQL Server数据库中有一个包含10多万条记录的大表.该表包含美国所有50个州的特定类型的数据.因此,如果我从这个表创建50个视图,每个状态一个,那么从我的应用程序进行查询的性能是否会得到改善？其他建议？

最近在一次采访中被问到为什么SELECT对MySQL数据库的查询会非常缓慢,并提出以下建议:

1. JOIN在选择上执行多个
2. 关键过滤器字段中缺少索引(索引？)

还问了解决问题的方法,我说:

1. 如果查询具有高度重要性,则会对您的数据进行非规范化(我知道这会导致数据重复但是还有另一种方法可以避免 JOINs吗？)
2. 将索引添加到筛选列.

是否存在SQL查询效率低下的其他特征？请注意,我纯粹在寻找有关如何加速查询的提示,因此假设数据库服务器是完美的:-)

给定一个名为“ orders_products”的mySQL表，其中包含以下相关字段：

• products_id
• orders_id

两个字段都被索引。

我正在运行以下查询：

SELECT products_id, count( products_id ) AS counter
FROM orders_products
WHERE orders_id
IN (
  SELECT DISTINCT orders_id
  FROM orders_products
  WHERE products_id = 85094
)
AND products_id != 85094
GROUP BY products_id
ORDER BY counter DESC
LIMIT 4

该查询耗时极长，大约20秒。否则数据库不是很忙，并且在其他查询上表现良好。

我想知道，是什么原因导致查询如此缓慢？

该表相当大（大约150万行，大小约为210 mb），这可能是内存问题吗？

有没有一种方法可以确切说明花费了这么长时间的mySQL？

解释输出：

id  select_type     table   type    possible_keys   key     key_len     ref     rows    Extra
1   PRIMARY     orders_products     range   products_id     products_id     4   NULL    1577863     Using where; Using temporary; Using filesort
2   DEPENDENT SUBQUERY  orders_products     ref     orders_id,products_id   products_id …

我有三张桌子。每个表包含超过3M行。我运行以下代码：

SELECT * FROM 
(
    SELECT col_1, col_2, col_3, [date], 1 as type FROM table_1
    UNION
    SELECT col_1, col_2, col_3, [date], 2 as type FROM table_2 
    UNION
    SELECT col_1, col_2, col_3, [date], 3 as type FROM table_3
) AS tb 
tb.[date] BETWEEN (start_date) AND (end_date)  
ORDER BY [date] DESC OFFSET n ROWS FETCH NEXT m ROWS ONLY

但是，当我得到较大的日期间隔时，查询运行会变慢。例如：当我得到2019-01-01和2019-04-01间隔时，查询运行约13-14秒：

这个结果非常糟糕。我想在1秒内得到结果。我能做什么？