标签: database-optimization

我有这样的陈述超时:

DELETE FROM [table] WHERE [COL] IN ( '1', '2', '6', '12', '24', '7', '3', '5')

我试着像这样一次做一个:

DELETE FROM [table] WHERE [COL] IN ( '1' )

到目前为止,它已经到了22分钟仍在继续.

该表中有260,000行,是四列.

有没有人有任何想法为什么这会如此缓慢以及如何加快它？我确实在[COL]上有一个非唯一的非聚集索引,我在做WHERE.我正在使用SQL Server 2008 R2

更新:我没有触发器.

查询基本上是:

SELECT DISTINCT "my_table"."foo" from "my_table" WHERE...

我假装我100%肯定DISTINCT查询的部分是它运行缓慢的原因,我省略了其余的查询以避免混淆,因为它是我主要关注的不同部分的缓慢(不同的是永远是缓慢的来源).

该表有250万行数据.该DISTINCT 是需要在这里没有列出的目的(因为我不想回修改后的查询,而是让不同的查询,而只是一般的信息运行在较快的DBMS的水平,如果可能的话).

如何在DISTINCT不改变SQL的情况下更快地运行(特别是使用Postgres 9)(即,我无法改变此SQL,但是可以在数据库级别优化某些内容)？

在各种ORM的文档中,它们总是提供创建索引等的方法.他们总是提到要确保为效率创建适当的索引,就好像这是非手写SQLer的固有知识,需要使用ORM.我对索引(PK之外)的理解基本上是:如果您打算LIKE根据列的内容进行查询(即搜索),则应该为该列使用全文索引.关于指数(主要与效率有关),我还应该知道什么？我觉得我的门口有一个知识世界,但是它下方有一个巨大的折叠式鼠标垫,所以我无法通过(我不知道为什么我觉得我需要这么说,但是谢谢你提供沙发).

首先,我应该指出我对SQL Server索引知之甚少.

我的情况是我有一个SQL Server 2008数据库表,其中varchar(max)列通常填充了大量文本.

我的ASP.NET Web应用程序有一个搜索工具,可以在此列中查询关键字搜索,并且根据搜索的关键字数量,可能是SQL查询中的一个或多个LIKE'%keyword%'语句来进行搜索.

我的Web应用程序也允许通过此表中的各个其他列进行搜索,而不仅仅是一列.其他表也有一些连接.

我的问题是,是否值得在此列上创建索引以提高这些搜索查询的性能？如果是这样,什么类型的索引,只是索引一列是足够的,还是我需要包括其他列,如主键和其他可搜索的列？

我需要将其他数据放入数据库中,我可以选择修改现有表(table_existing)还是创建新表.

这就是table_existing现在的样子:

table_existing
-------------------------
| ID | SP | SV | Field1 |
| .. | WW |  1 | ...... |
| .. | WW |  1 | ...... |
-------------------------

选项(A)

table_existing
----------------------------------------------------------------------
| ID | SP | SV | Field1 | Field2 | Field3 | Field4 | Field5 | Field6 |
| .. | XX |  1 | ...... | ...... | ...... | ...... | ...... | ...... |
| .. | YY |  2 | …

所以我一直认为在Extra栏中看到"Using Where"是一件好事.然而,我正计划为我的同事准备一个棕色的包午餐来解释EXPLAIN,现在我不太确定.MySQL文档在关于"使用位置"的说明中说明了这一点:

WHERE子句用于限制哪些行与下一个表匹配或发送到客户端.除非您特意打算从表中获取或检查所有行,否则如果Extra值不是Using where并且表连接类型为ALL或index,则查询可能会出错.即使您正在为WHERE子句的所有部分使用索引,您也可以看到如果列可以为NULL则使用where.

这使我相信即使我的WHERE子句只包含索引的一部分,如果列可以具有NULL值,MySQL仍将检查行.

真的吗？如果是这样,如果我不需要它,我应该将列更改为不包括NULL吗？我会看到提速吗？

我曾经被告知,运行插入并让插入失败比检查数据库条目是否存在然后插入(如果它丢失)更快.

我还被告知,大多数数据库都经过大量优化,无法读取阅读而不是写入,因此快速检查不会比慢速插入快吗？

这是预期碰撞次数的问题吗？(IE只有在条目已经存在的可能性很小的情况下插入才会更快.)它是否依赖于我正在运行的数据库类型？就此而言,有一种方法会不断向我的错误日志中添加插入错误,这是不好的做法吗？

谢谢.

我想知道,在带宽和整体效率方面哪个选项最贵.

假设Client我的应用程序中有一个类,client数据库中有一个表.

它是最好有一个静态函数Client.getById检索整个客户端记录或多个(Client.getNameById,Client.getMobileNumberById即检索各领域,等等)？

如果单个记录有很多字段,并且我最终在当前脚本中使用了一个或两个,那么检索所有内容并在应用程序内部决定如何处理所有数据仍然更好吗？

顺便说一句,我正在使用PHP和MySQL.

晚间,

我正在经历漫长的过程,将数据从受到重视的,已有15年历史的只读数据格式导入MySQL,以便从中构建一些较小的统计表.

我之前构建的最大的表是(我认为)3200万行,但我没想到它会变得那么大并且真的让MySQL变得紧张.

该表将如下所示:

surname    name    year    rel    bco    bplace    rco    rplace
Jones      David   1812    head   Lond   Soho      Shop   Shewsbury

所以,小的int和varchars.

任何人都可以提供有关如何尽快使其工作的建议吗？任何coulmns上的索引是否有帮助,或者它们只会减慢查询速度.

每列中的大部分数据将重复多次.某些字段的可能值不超过100个.

我将查询表的主要栏目是:姓氏,名字,rco,rplace.

我正在从Elmasri和Navathe的作者，第5版的数据库系统基础一书中研究数据库，并且几乎在第15章开始时，他们都使用合并排序简要地解释了外部排序。他们将算法分为两个阶段：

1）排序：他们使用下一个符号：

• b =我们要排序的数据文件的块数。
• nb =内存中可用于排序的缓冲区（块）数。
• nr =份数。

在此阶段中，我们将尽可能多的块放入数据文件中，使用任何内部排序算法对它们进行排序，并将它们写入为临时排序的子文件。我们在文件的其余块中重复此操作，因此我们将获得更多排序的子文件。这些子文件被它们称为“部分”，它们的数量是：

nr =？b / nb？。

符号？？表示上限功能。此阶段的I / O成本为2b，因为我们需要一次读取每个块（b次访问）。然后，要保存所有部分，我们还需要进行b访问。

2）合并：他们说类似的话（我用我的解释重写了它，以使其更清楚）：

生成的部分（有序子文件）以一遍或多遍混合。每次通过时，将在内存中保留一个输出块，以放置混合结果，其余部分用作输入块，最大可达nb-1，并且每个块一次放置一个块有序部分，目的是将它们混合。当输入块少于部分时，需要多次通过。另外，由于每个部分可以具有一个以上的块，因此将每个遍细分为迭代，每个迭代中都放置了每个部分的块。

• dm =混合度，即每次通过中可以混合的部分数。

数字dm必须等于（nb-1）和nr之间的最小值。如果我们将对数的底数放在（）之间，而其对数放在??之间，则通过的次数为：

？log（dm）？nr ??。

我感到困惑的部分是，他们说这一阶段的成本是

2b *？log（dm）？nr ??，

所以他们基本上是在暗示，在每遍中，我们只需要读取一次每个块并将其写入一次，但是我不确定这是否正确。我怀疑可能需要更多访问权限。

因此，该算法的总成本为2b + 2b *？log（dm）？nr ??。

= 2b（1 +？log（dm）？nr ??）

实际上，他们不是这样说的，而是：“通常，对数以dm为底，表示访问的块数的表达式如下：”

（2 * b）+（2 *（b *（log（dm）？nr？））），

基本上是一样的

例如，假设我们有一个10个块的文件，每个块3条记录。内存（缓冲池）中的可用空间为4个块。让我们用||分隔文件的块

29,11,27 || 22,1,20 || 7,30,26 || 9,8,21 || 13,24,15 || 23,4,28 || 17,12,10 || 5,3,6 || 16,19,2 || 25,14,18

导致分选阶段的部分“ nr”的数量为“ …