数据库管理员

希望提高数据库技能并向社区中的其他人学习的数据库专业人员的问答

2
REINDEX危险吗？
我一直在尝试COUNT(*)使用包含主键的150,000行的表。它用了大约5分钟的时间，所以我发现这是一个索引问题。 引用PostgreSQL手册： REINDEX与删除索引和重新创建索引相似，因为索引内容是从头开始重建的。但是，锁定注意事项却大不相同。REINDEX锁定对索引的父表的写入但不对其进行读取。它还对正在处理的特定索引采取排他锁，这将阻止尝试使用该索引的读取（...）。后续的CREATE INDEX锁定写入但不读取；由于索引不存在，因此不会进行任何读取尝试，这意味着将不存在阻塞，但可能会将读取强制进行昂贵的顺序扫描。 根据您自己的经验，您能否告诉您： 有REINDEXING危险吗？会损害数据一致性吗？ 会花费很多时间吗？ 这是我的情况的可能解决方案吗？ 更新： 对我们有用的解决方案是使用不同的名称重新创建相同的索引，然后删除旧索引。 索引创建非常快，我们将索引大小从650 MB减小到8 MB。使用COUNT(*)with between只需3秒。
17 postgresql 
6
Redgate SQL Compare与Visual Studio 2010 Premium / Ultimate数据库项目
我目前使用的是Visual Studio Professional Edition，它具有数据库项目作为项目模板，但是它的某些功能不可用，例如Schema Compare tool。架构比较和数据库更新脚本生成仅在Visual Studio 2010 Premium / Ultimate版本中可用。 但是，Visual Studio中的模式比较和更新脚本生成功能是否像Redgate SQL Compare工具中那样丰富？（我也没有使用过）我没有找到功能比较列表。谁同时使用了这两个工具，有谁能帮助说清楚？
4
包含表中所有列的主键有什么好处？
我有一个表，其中有四列都是不可为空的列，并且数据是如此，因此需要全部四列来区分唯一记录。这意味着如果要创建主键，则需要包含所有列。对表的查询几乎总是要拉回一条记录，即所有列将在查询中被过滤。 由于将需要搜索每一列，因此拥有主键是否对我完全有益（除了强制记录的唯一性）？
2
在Google BigTables（和其他集成数据库）上进行性能测试
有哪些有效的方法可以对数据库操作执行程序性能测试，尤其是在数据库本身不提供专用工具的环境中？ 例如，在Google App Engine中，整个页面加载被评估为一项操作，其中可能包括特定的数据库操作。SQLite和其他集成DB中也可能出现此问题。由于很难完全抽象出需要测试的（等效）选择和插入内容，是否有推荐的数据库工具对这些类型的查询执行更彻底的诊断？
2
交叉应用产生外部连接
为了回答SQL对分区的计数问题，Erik Darling发布了此代码来解决以下问题COUNT(DISTINCT) OVER ()： SELECT * FROM #MyTable AS mt CROSS APPLY ( SELECT COUNT(DISTINCT mt2.Col_B) AS dc FROM #MyTable AS mt2 WHERE mt2.Col_A = mt.Col_A -- GROUP BY mt2.Col_A ) AS ca; 查询使用CROSS APPLY（not OUTER APPLY），为什么执行计划中有外部联接而不是内部联接？ 同样，为什么取消注释group by子句会导致内部联接？ 我认为数据并不重要，但可以复制kevinwhat在另一个问题上给出的数据： create table #MyTable ( Col_A varchar(5), Col_B int ) insert …
5
当强制实施IsDeleted（软删除）时，合适的索引体系结构是什么？
当前，我们有一个功能齐全的现有数据库和应用程序。我目前无法更改架构。今天，数据库中的每个表都有一个“ IsDeleted” NOT NULL BIT字段，默认值为“ 0”。当应用程序“删除”数据时，它只是将IsDeleted标志更新为1。 我无法理解的是每个表的索引应如何构造。现在，每个查询/联接/等总是执行IsDeleted检查。这是我们开发人员必须遵循的标准。话虽这么说，我试图确定是否需要更改每个表上的所有群集主键索引，以包括主键和IsDeleted BIT字段。另外，由于每个查询/加入/等。必须执行IsDeleted检查，是否适当地假设每个单索引（以及非聚簇索引）都应将IsDeleted字段包括为索引的第一个字段？ 我还有一个问题是关于过滤索引的。我知道我可以在诸如“ WHERE IsDeleted = 0”之类的索引上放置过滤器，以减少索引的大小。但是，由于每个联接/查询都必须实现IsDeleted检查，这是否会阻止使用过滤后的索引（因为联接/查询中使用了IsDeleted列）？ 请记住，我没有能力更改IsDeleted方法。
1
从索引列上非常大的表中选择SELECT TOP 1非常慢，但不是相反的顺序（“ desc”）
我们有一个大型数据库，大约1TB，在功能强大的服务器上运行SQL Server 2014。几年一切正常。大约2周前，我们进行了全面维护，其中包括：安装所有软件更新；重建所有索引和紧凑的数据库文件。但是，我们没想到在实际负载相同的情况下，在某些阶段数据库的CPU使用率会增加100％以上至150％。 经过大量的故障排除后，我们将其范围缩小到一个非常简单的查询，但找不到解决方案。查询非常简单： select top 1 EventID from EventLog with (nolock) order by EventID 它总是需要约1.5秒！但是，带有“ desc”的类似查询始终大约需要0毫秒： select top 1 EventID from EventLog with (nolock) order by EventID desc PTable大约有5亿行；EventID是ASC数据类型为bigint（标识列）的主聚集索引列（有序）。有多个线程在顶部的数据表中插入数据（较大的EventID），有1个线程从底部的数据表中删除数据（较小的EventID）。 在SMSS中，我们验证了两个查询始终使用相同的执行计划： 聚集索引扫描； 估计行数和实际行数均为1； 估计的执行次数和实际的执行次数均为1； 估计I / O成本为8500（似乎很高） 如果连续运行，则两者的查询成本都是相同的50％。 我更新了索引统计信息with fullscan，问题仍然存在；我再次重建了索引，问题似乎消失了半天，但又回来了。 我通过以下方式打开了IO统计信息： set statistics io on 然后连续运行两个查询，发现以下信息： （对于第一个查询，慢速查询） 表“ PTable”。扫描计数1，逻辑读407670，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。 （对于第二个查询，快速查询） …
7
综合指标：选择性最强的列优先？
我一直在阅读composite indexes有关订购的信息，我有些困惑。该文档（至少不到一半）说 通常，应将预期最常使用的列放在索引的第一位。 然而，不久之后说 创建一个将最有选择性的列放在首位的复合索引；即，具有最多值的列。 甲骨文也在这里说 如果在WHERE子句中平等地使用所有键，则在CREATE INDEX语句中将这些键从最有选择性的顺序排列到最不有选择性的顺序可以最大程度地提高查询性能。 但是，我找到了一个SO答案，但答案却有所不同。它说 排列这些列，其中最不具选择性的列在前，最不具选择性的列在最后。如果是与柱子捆绑在一起，则更可能单独使用。 我引用的第一个文档说您应该首先去最常用的文档，而SO回答则应该只用于平局。然后它们的订购也有所不同。 该文档还讨论skip scanning并说 如果在复合索引的前导列中只有几个不同的值，而在索引的非前导键中有很多不同的值，则跳过扫描是有利的。 另一篇文章说 前缀列应该是查询中最具区分性和最广泛使用的 我相信最有区别的意思将是最独特的。 所有这些研究仍然将我引向同一问题。最有选择性的栏应该在第一还是最后？在抢七局中，第一栏应该是使用最多，选择最多的栏吗？ 这些文章似乎相互矛盾，但是它们确实提供了一些示例。从我收集到的信息来看，如果您期望，那么成为订单中least selective column的第一名似乎更有效率Index Skip Scans。但我不确定这是否正确。
1
Postgres：SET NOT NULL如何比CHECK约束“更有效”
在PostgreSQL文档Constraints中，它说 非空约束在功能上等同于创建检查约束CHECK (column_name IS NOT NULL)，但是在PostgreSQL中，创建显式非空约束更为有效。 我很好奇 “更有效”到底是什么意思？ 使用CHECK (column_name IS NOT NULL)代替的不利之处是SET NOT NULL什么？ 我希望能够添加一个NOT VALID CHECK约束并分别对其进行验证（因此，AccessExclusiveLock对于添加约束，该约束仅保留很短的时间，然后ShareUpdateExclusiveLock对于较长的验证步骤，将其保持一段时间）： ALTER TABLE table_name ADD CONSTRAINT column_constraint CHECK (column_name IS NOT NULL) NOT VALID; ALTER TABLE table_name VALIDATE CONSTRAINT column_constraint; 代替： ALTER TABLE table_name ALTER COLUMN column_name SET NOT NULL;
2
在SQL中实现具有总参与约束的多对多关系
我应该如何在SQL中实现以下实体关系图所示的方案？ 如图所示，每个A实体类型出现都必须与至少一个 B对应项（由双连接线指示）相关，反之亦然。我知道我应该创建以下三个表： CREATE TABLE A ( a INT NOT NULL, CONSTRAINT A_PK PRIMARY KEY (a) ); CREATE TABLE B ( b INT NOT NULL, CONSTRAINT B_PK PRIMARY KEY (b) ); CREATE TABLE R ( a INT NOT NULL, b INT NOT NULL, CONSTRAINT R_PK PRIMARY KEY (a, b), CONSTRAINT …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.