标签: optimization

我使用的MySQL版本：5.5.38

有以下参数可以控制InnoDB日志文件：

innodb_log_files_in_group- 组中的日志文件数量，默认为 2。将创建 2 个文件 ib_logfile0 和 ib_logfile1

innodb_log_group_home_dir- InnoDB 日志文件的位置。

有没有办法将每个单独的日志文件放置到它自己的位置？

主要思想是提高性能并将每个文件放置到其自己的 HDD 驱动器中。因为我有很多与 InnoDB 日志文件相关的 IO。MySQL InnoDB 日志文件的 IO 过多

在这个答案中， Erwin 将IMMUTABLE函数分解为可以内联的函数和不能内联的函数。他有一个例子to_char()，表明IMMUTABLE函数 overto_char()实际上会更慢。

不过这很有趣，因为我什至不知道to_char()不是IMMUTABLE。此外，我不知道这IMMUTABLE会让任何事情变得更慢。我现在的问题是，如何确定标记为IMMUTABLE内联的函数是否被内联？

我在这里发生了哈希匹配溢出。我已经用 FULLSCAN 更新了涉及的表的统计信息，所以不是这样。任何指针都非常感谢。

https://www.brentozar.com/pastetheplan/?id=Bkq1VjySm

我使用的是 SQL 2017 Enterprise，内存为 64GB。

我有一个基于 col1 int 分区的分区表。我还有一个覆盖索引，用于我尝试解决的查询。

https://www.brentozar.com/pastetheplan/?id=BkNrNdgHm

以上是计划

任其发展，SQL Server 决定对整个表进行聚集索引扫描，这显然很慢。如果我强制索引（如上面的计划），查询会快速运行。

SQL Server 使用什么魔术逻辑来确定覆盖索引没有用？我不确定 top/orderby 和 rowgoal 是否与它有关。

我的表结构是

Create table object2(col1 int, col3 datetime, col4 int, col5, col6 etc) clusterd on col1

nonclustered non aligned index is on col3,col4 (col1 is clustered so its included in nonclust)

SELECT top(?) Object1.Column1
    FROM Object2 Object1 WITH (NOLOCK,index(Column2))
    WHERE  Object1.Column3 >= ?
    AND Object1.Column4 IN (?)
    ORDER BY Object1.Column1

编辑添加的回购

    CREATE PARTITION FUNCTION [PFtest](int) AS RANGE RIGHT FOR VALUES (100000, 200000, 300000, 400000, 500000, …

换句话说，我怎样才能摆脱下图中的sort操作符？

上图显示了以下2个select的执行计划：

                SELECT   TOP 1 so.OrgType, 
                              ch.Status, 
                              rcs.DBSstatusDescription, 
                              cid.ApplicationId
                   FROM   tbl_application_crb_initialData cid

                   INNER JOIN  tbl_season_organisationId so
                          ON   cid.OrganisationId = so.OrgId

                   LEFT JOIN  tbl_crbHistory ch  
                          ON  cid.ClientReference = ch.ClientReference

                   LEFT JOIN  ref_crbStatus rcs
                         ON   ch.Status = rcs.statusId    

                   ORDER BY  cid.DateAdded DESC, ch.DateAdded DESC

                SELECT   TOP 1 so.OrgType, 
                              ch.Status, 
                              rcs.DBSstatusDescription, 
                              cid.ApplicationId
                   FROM   tbl_application_crb_initialData cid

                   INNER JOIN  tbl_season_organisationId so
                          ON   cid.OrganisationId = so.OrgId

                   LEFT JOIN  tbl_crbHistory ch  
                          ON  cid.ClientReference = ch.ClientReference

                   LEFT JOIN  ref_crbStatus rcs
                         ON   ch.Status = rcs.statusId …

我正在对我公司的一些 SQL 进行一些性能基准测试，将 PG10 与 PG12 进行比较。我们在代码中使用了很多CTE，而 PG12 并没有对 CTE 进行原生优化，因此 PG10 和 PG12 之间的性能是相同的。

我的下一个实验是将NOT MATERIALIZED指令添加到 CTE，结果令人震惊：它大大缩短了查询时间（在某些情况下将它们减半）。

我在这里读到这MATERIALIZED是 PG12 之前的默认功能。该功能会将 CTE 的所有内容写入一个临时位置。

所以我的问题主要是NOT MATERIALIZED：

1. 与 相比，该NOT MATERIALIZED功能对幕后的数据MATERIALIZED有何作用？
2. NOT MATERIALIZED在重构我们的代码库之前，我应该注意哪些副作用？

将应用程序及其数据库从经典 PostgreSQL 数据库迁移到 Amazon Aurora RDS PostgreSQL 数据库（均使用 9.6 版本）后，我们发现特定查询在 Aurora 上的运行速度要慢得多——大约慢 10 倍在 PostgreSQL 上。

两个数据库都具有相同的配置，无论是硬件还是 pg_conf。

查询本身相当简单。它是从我们用 Java 编写的后端生成的，并使用 jOOQ 编写查询：

with "all_acp_ids"("acp_id") as (
    select acp_id from temp_table_de3398bacb6c4e8ca8b37be227eac089
) 
select distinct "public"."f1_folio_milestones"."acp_id", 
    coalesce("public"."sa_milestone_overrides"."team", 
    "public"."f1_folio_milestones"."team_responsible") 
from "public"."f1_folio_milestones" 
left outer join 
    "public"."sa_milestone_overrides" on (
        "public"."f1_folio_milestones"."milestone" = "public"."sa_milestone_overrides"."milestone" 
        and "public"."f1_folio_milestones"."view" = "public"."sa_milestone_overrides"."view" 
        and "public"."f1_folio_milestones"."acp_id" = "public"."sa_milestone_overrides"."acp_id"
)
where "public"."f1_folio_milestones"."acp_id" in (
    select "all_acp_ids"."acp_id" from "all_acp_ids"
)

用temp_table_de3398bacb6c4e8ca8b37be227eac089是单个列的表，f1_folio_milestones（17万个条目）和sa_milestone_overrides（100万左右的条目）是具有在所有用于列索引类似设计的表LEFT OUTER JOIN。

temp_table_de3398bacb6c4e8ca8b37be227eac089 最多可以包含 5000 …

目前我正在使用一个看起来像这样的 postgres 表 (postgres12)

create table if not exists asset (
  id text,
  symbol text not null,
  name text not null
  primary key (id)
);
create table if not exists latest_value (
  timestamp bigint,
  asset text,
  price decimal null,
  market_cap decimal null,
  primary key (asset),
  foreign key (asset)
    references asset (id)
    on delete cascade
);
create table if not exists value_aggregation (
  context aggregation_context,
  timestamp bigint,
  asset text,
  price jsonb null,
  market_cap jsonb null,
  primary key (context, timestamp, asset),
  foreign …

为了优化 SELECT 语句，我尝试在 MySQL 中使用以下 SQL 语句使索引唯一：

ALTER TABLE credentials DROP INDEX special_credential_id, ADD UNIQUE KEY special_credential_id(special_credential_id)

我的问题是：这是一笔交易吗？这意味着如果创建唯一索引失败，旧的special_credential_id索引是否仍然存在？通常创建一个新索引很容易，但我们讨论的是包含 100 个 Mio 条目的表。

DB用于存储市场报价，因此一天丢失数据是可以接受的。

所有写入操作均通过单个连接在一天的固定时间连续执行。

每天增加的数据量约为2GB。

由于预算削减，物理存储设备不得不从SSD改为传统硬盘，写入时间从10分钟改为2小时以上。

我应该如何调整 PG 配置以进行写入，尤其是使用传统硬盘？

环境：Ubuntu服务器20.04，Postgresql-11，CPU 4核，RAM 8G，写入时不需要做任何其他事情。