标签: database-performance

我正在从头开始为新应用程序构建数据库模式，我的两个目标是松耦合（可扩展性）和性能（但性能是最重要的）。我不确定在中央表中包含外键列是否是一个好主意。使用示例可能可以最好地理解我的问题（请记住，这个示例纯粹是假设的）：

我们有一张桌子，我们称这张桌子为“动物”。在此表中，我们有几个条目可以定义数据库中存储的各种类型的“动物”的属性。我们还有另一个名为“AnimalName”的表，其目的是将“Animal”表中每个动物的名称与语言 ID 一起存储（因此我们有一个表将每个动物的名称存储在“Animal”表中）每种语言的动物”表）。

我有两种方法来实现上表：

第一种方式

动物表：AnimalID (PK)
AnimalName 表：AnimalNameID (PK)、AnimalID (FK)、LanguageID (FK)、Name

查询将如下所示：

SELECT * FROM Animal a JOIN AnimalName an ON an.AnimalID = a.AnimalID and an.LanguageID = ? WHERE a.AnimalID = ?

第二种方式

动物表：AnimalID (PK)、AnimalNameID (FK)
AnimalName 表：AnimalNameID (PK)、LanguageID (FK)、Name

查询将如下所示：

SELECT * FROM Animal a JOIN AnimalName an ON an.AnimalNameID = a.AnimalNameID and an.LanguageID = ? WHERE a.AnimalID = ?

对于第二种方式，如果我要向 AnimalName 表添加“AnimalID”FK 列，那么它也将支持以第一种方式表达的查询。

上述哪一种方法将提供最快的性能（这一点至关重要！）？根据您的经验，您通常会推荐上述哪一种方法？

预先非常感谢所有回答的人！

pluck当只需要一两个字段时，我一直默认使用，但我最近对性能差异进行了基准测试，并且勇气丢失了：

ActiveRecord::Base.logger.level = 1
n = 5000
Benchmark.bm do |x|
  x.report('Country.all:              ') { n.times { Country.all } }
  x.report('Country.unscoped:         ') { n.times { Country.unscoped } }
  x.report('base priority_order:      ') { n.times { Country.unscoped.with_translations(I18n.locale).order(list_at_top:   :desc).order(:name) } }
  x.report('.includes(:translations): ') { n.times { Country.unscoped.with_translations(I18n.locale).order(list_at_top: :desc).order(:name).includes(:translations) } }
  x.report('.pluck(:name):            ') { n.times { Country.unscoped.with_translations(I18n.locale).order(list_at_top: :desc).order(:name).includes(:translations).pluck(:name) } }
  x.report('.pluck(:name) only:       ') { n.times { Country.unscoped.with_translations(I18n.locale).order(list_at_top: :desc).order(:name).pluck(:name) } }
end

# Results
=begin
                                  user     system      total        real
  Country.all:                0.990000   0.020000   1.010000 (  1.023518)
  Country.unscoped: …

我有带索引timestamp_1, timestamp_2 and user_id字段的位置集合。执行查询时（您可以在以下日志中看到），然后查询大约需要 3 分钟（175670 毫秒）。我不知道为什么会这样！！我附上了以下 MongoDB-Log。
任何人都可以解释我下面的日志以及如何优化它？

2017-04-12T17:04:33.759+0000 I COMMAND [conn167] query location-collection query: { orderby: { timestamp_1: 1 }, $query: { $and: [ { timestamp_1: { $lte: 14920162944486.0 } }, {timestamp_2: { $gte: 1491993563400.0 } }, { user_id: "jkfjlsjfflki-14asddsd" } ] } } planSummary: IXSCAN { user_id: 1 }, IXSCAN { user_id: 1 } ntoreturn:10007Examined4p4p7Examined4p7s hasSortStage:1 cursorExhausted:1 keyUpdates:0 writeConflicts:0 numYields:3350 nreturned:67 reslen:176574 锁：{全局：{acquireCount：{r：6702}}，数据库：{acquireCount：{r：3351}}，集合： {acquireCount: { r: 3351 } } } 175670 毫秒

还有一个问题：我正在创建自己的“_id”字段值，所以这样有什么缺点吗？？我只是创建字符串值并期望 mongoDb 索引它没有任何问题。 …

根据文档：

使用 COUNT(*) 的 SELECT 表达式返回与查询匹配的行数。或者，您可以使用 COUNT(1) 来获得相同的结果。

使用后一种方法是否有任何性能优势（如在 RDBMS 中）？

我运行此查询来检查我的数据库中是否有一些未使用的索引。

select 
    t.tablename AS "relation",
    indexname,
    c.reltuples AS num_rows,
    pg_relation_size(quote_ident(t.tablename)::text) AS table_size,
    pg_relation_size(quote_ident(indexrelname)::text) AS index_size,
    idx_scan AS number_of_scans,
    idx_tup_read AS tuples_read,
    idx_tup_fetch AS tuples_fetched
FROM pg_tables t
LEFT OUTER JOIN pg_class c ON t.tablename=c.relname
LEFT OUTER JOIN
    ( SELECT c.relname AS ctablename, ipg.relname AS indexname, x.indnatts AS number_of_columns, psai.idx_scan, idx_tup_read, idx_tup_fetch, indexrelname, indisunique FROM pg_index x
           JOIN pg_class c ON c.oid = x.indrelid
           JOIN pg_class ipg ON ipg.oid = x.indexrelid
           JOIN pg_stat_all_indexes psai ON x.indexrelid = psai.indexrelid )
    AS foo …

我正在尝试使用扩展来加速Postgres 中的一些文本匹配pg_trgm：

CREATE TABLE test3 (id bigint, key text, value text);

insert into test3 values (1, 'first 1', 'second 3');
insert into test3 values (2, 'first 1', 'second 2');
insert into test3 values (2, 'first 2', 'second 3');
insert into test3 values (3, 'first 1', 'second 2');
insert into test3 values (3, 'first 1', 'second 3');
insert into test3 values (4, 'first 2', 'second 3');
insert into test3 values (4, 'first 2', 'second 3');
insert into …

我正在尝试从 SQL 表中检索每条记录的最新数据。每条记录都会有重复的数据，并有一些数据变化。我需要检索最新的带时间戳的数据。有人可以建议哪个是性能方面的最佳解决方案吗？见过一些带有内部联接和子查询的解决方案。

下面给出的示例数据

Technology Students Amount Area      Date
python     500      1000   Bangalore 2021-08-06 12:03:26
Ruby       100      1000   Bangalore 2021-08-06 05:18:50
Java       300      1000   Bangalore 2021-08-06 18:23:40
python     900      1000   Bangalore 2021-08-06 16:23:30
Java       100      1000   Bangalore 2021-08-06 12:23:50
Ruby       500      1000   Bangalore 2021-08-06 15:13:40

我的 O/P 应该包含每种技术的最新数据

Technology Students Amount Area      Date
Java       300      1000   Bangalore 2021-08-06 18:23:40
python     900      1000   Bangalore 2021-08-06 16:23:30
Ruby       500      1000   Bangalore 2021-08-06 15:13:40

假设我已使用同一用户从不同的 PC 连接到数据库 3 次。Oracle 是否为每个区域创建单独的 PGA 区域，还是只创建一个区域？如果有，它如何处理来自同一用户连接的不同会话并同时执行的多个查询？

SQL Server中有3个数据量很大的表，每个表包含大约100000行。有一个 SQL 从三个表中获取行。它的性能非常糟糕。

WITH t1 AS 
(
    SELECT 
        LeadId, dbo.get_item_id(Log) AS ItemId, DateCreated AS PriceDate
    FROM 
        (SELECT 
             t.ID, t.LeadID, t.Log, t.DateCreated, f.AskingPrice
         FROM 
             t
         JOIN 
             f ON f.PKID = t.LeadID
         WHERE 
             t.Log LIKE '%xxx%') temp
)
SELECT COUNT(1)
FROM t1
JOIN s ON s.ItemID = t1.ItemId

在检查其估计执行计划时，我发现它使用了大行的嵌套循环连接。抢劫看下面的截图。图像中的顶部部分返回 124277 行，底部部分执行了 124277 次！我想这就是它这么慢的原因。

我们知道嵌套循环在处理大数据时存在很大的性能问题。如何删除它，并使用散列连接或其他连接代替？

编辑：以下是相关功能。

CREATE FUNCTION [dbo].[get_item_Id](@message VARCHAR(200))
RETURNS VARCHAR(200) AS
BEGIN
    DECLARE @result VARCHAR(200),
            @index int

    --Sold in eBay (372827580038).
    SELECT @index = PatIndex('%([0-9]%)%', @message)
    IF(@index = …

我们有一个由 3 个主节点（每个 4 核、16 GB RAM）、3 个热节点（每个 8 核、32 GB RAM、300 GB SSD）和 3 个热节点（每个 8 核、32GB RAM、1.5TB HDD）组成的集群。 。

我们按照 的命名约定为一年中的每个月都有一个索引voucher_YYYY_MMM(eg voucher_2021_JAN)。所有这些索引都有一个voucher充当读取别名的别名，我们的搜索查询针对该读取别名。

我们的索引在热节点上驻留 32 天，在此期间它将接收 99% 的写入。我们估计该索引中的数据约为 4.8 亿个文档，它有 1 个副本和 16 个分片（我们采用了 16 个分片，因为最终我们的数据会增长，现在我们正在考虑缩小到 8 个分片，每个分片有 30 GB数据，根据我们的映射，200 万个文档占用 1GB 空间）。

32天后索引将转移到温节点，目前，我们的热索引中有4.5亿个文档，温索引中有18亿个文档。文档总数达 22.5 亿篇。

我们的文档包含客户 ID 和我们正在应用过滤器的一些字段，它们全部映射为关键字类型，我们用于custom routing on customer id提高搜索速度。

我们典型的查询看起来像

GET voucher/_search?routing=1000636779&search_type=query_then_fetch
{
  "from": 0,
  "size": 20,
  "query": {
    "constant_score": {
      "filter": {
        "bool": {
          "filter": [
            {
              "term": …