数据库管理员

我目前正在设计交易表。我意识到将需要计算每一行的运行总计，这可能会降低性能。因此，出于测试目的，我创建了一个包含一百万行的表。 CREATE TABLE [dbo].[Table_1]( [seq] [int] IDENTITY(1,1) NOT NULL, [value] [bigint] NOT NULL, CONSTRAINT [PK_Table_1] PRIMARY KEY CLUSTERED ( [seq] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO 我尝试获取10个最近的行及其运行总计，但大约花了10秒钟。 --1st attempt SELECT TOP 10 seq …

8 sql-server  database-design  t-sql  query-performance  execution-plan 

信息 我的问题与堆有关的中等大表（〜40GB数据空间）有关 （不幸的是，应用程序所有者不允许我将聚集索引添加到表中） 在“标识”列（ID）上创建了自动创建的统计信息，但为空。 自动创建统计信息和自动更新统计信息处于启用状态 表格中发生了修改 还有其他（自动创建的）统计信息正在更新 由索引创建的同一列上还有另一个统计信息（重复） 内部版本：12.0.5546 重复统计信息正在更新： 实际问题 据我了解，即使在完全相同的列（重复项）上有两个统计信息，也可以使用所有统计信息并跟踪修改，所以为什么这个统计信息仍然为空？ 统计信息 数据库统计信息 桌子尺寸 创建统计信息的列信息 [ID] [int] IDENTITY(1,1) NOT NULL 身份栏 select * from sys.stats where name like '%_WA_Sys_0000000A_6B7099F3%'; 自动建立 获取其他统计信息 select * From sys.dm_db_stats_properties (1802541555, 3) 与我的空状态相比： 来自“生成脚本”的统计信息和直方图： /****** Object: Statistic [_WA_Sys_0000000A_6B7099F3] Script Date: 2/1/2019 10:18:19 AM ******/ …

8 sql-server  sql-server-2014  statistics 

在开发解决方案原型时，通常尚未决定技术，并且可能与最终产品中使用的技术不同。 在这种情况下，我倾向于使用Microsoft SQL Server以尽可能标准的方式编写查询，以简化最终迁移到另一台服务器的过程。 有没有一种方法或某种已知的实践可以直接在SQL Server中或通过SQL Server Management Studio（SSMS）通过T-SQL方言强制使用标准SQL ？

8 sql-server  sql-server-2016  migration  sql-standard 

我有很多财务报告，我们希望能够将两个输入（年份和季度）作为变量传递给他们。 我这样做，但是我真的不喜欢它： declare @quarter int, @year int, @date date set @quarter = 4 set @year = 2018 set @date = cast(@year as varchar(4)) + '-01-01' set @date = dateadd(quarter, @quarter - 1, @date) print @date 问题从整数输入重建日期的最佳方法是什么？ 预期结果： 2018-10-01

8 sql-server-2008-r2 

访问临时表中的历史记录时遇到一个奇怪的问题。通过AS OF子句访问时间表中较旧条目的查询所花的时间比对最近历史条目的查询所花的时间更长。 历史表是由SQL Server生成的（包括日期列上的聚簇索引并使用页面压缩），我向历史表中添加了5000万行，而我的查询检索了大约25,000行。 我试图确定问题的根本原因，但无法识别。到目前为止，我已经测试了： 创建一个具有聚集索引的5000万行的测试表，以查看速度下降是否仅是由于数量引起的。我能够在固定时间（〜400ms）内检索到25K行。 从历史表中删除页面压缩。这对检索时间没有影响，但是确实增加了表的大小。 我尝试使用ID列和日期列直接访问历史记录表的行。这是事情变得更有趣的地方。我可以在〜400ms处访问表中的旧行，其中与AS OF子句一样，它需要1200ms的时间。我尝试对日期列上的测试表进行过滤，并且与对ID列进行过滤相比，发现了类似的减速。这使我相信日期比较是某些放缓的原因。 我想更多地看这个，但是我也想确保我没有吠错树。首先，在访问临时表中的较旧历史数据时，是否还有其他人遇到过相同的行为（我们仅注意到速度下降超过1000万行）？其次，我可以使用哪些策略来进一步隔离性能问题的根本原因（我刚刚开始研究执行计划，但对我来说仍然有点神秘）？ 执行计划 这些是简单的检索查询：第一个访问较旧的行，第二个访问较新的行。 旧行〜1200ms执行时间 最近的行〜350ms执行时间 表格详情 这些是时间表中的列。历史记录表具有相同的列，但没有主键（根据历史记录表的要求）： 以下是历史记录表上的索引：

8 sql-server  performance  temporal-tables 

设定 我有一个约115,382,254行的巨大表。该表相对简单，并且记录了应用程序的处理操作。 CREATE TABLE [data].[OperationData]( [SourceDeciveID] [bigint] NOT NULL, [FileSource] [nvarchar](256) NOT NULL, [Size] [bigint] NULL, [Begin] [datetime2](7) NULL, [End] [datetime2](7) NOT NULL, [Date] AS (isnull(CONVERT([date],[End]),CONVERT([date],'19000101',(112)))) PERSISTED NOT NULL, [DataSetCount] [bigint] NULL, [Result] [int] NULL, [Error] [nvarchar](max) NULL, [Status] [int] NULL, CONSTRAINT [PK_OperationData] PRIMARY KEY CLUSTERED ( [SourceDeviceID] ASC, [FileSource] …

8 sql-server  index  partitioning  azure-sql-database 

由于SQL Server适用于Linux，我可以在Linux节点上配置群集吗？我的意思是与Windows混合-一些节点在Linux上，其他节点在Windows上的同一群集中？

8 sql-server  linux  clustering 

我是编程和数据库的新手，对于以下情况的帮助，我将不胜感激。 我在SQL Server中使用PHP。我正在建立一个员工出勤系统，我想创建一个（枢轴）表，其中月份作为行，所有工作日名称作为列（针对特定年份）。单元格中的值将是天数（1、2、3 ... 31）。 单元格的背景色（已存在于表格列中）声明了员工请假的类型。该表有以下栏目：employee_id, leave_date, leave_type, leave_type_color。 我想要达到如下结果： 谢谢。

8 sql-server  php  pivot 

我试图学习更多有关关系数据库的知识，并且发现没有更好的方法来学习然后实际去做。我决定亲自尝试一下“个人预算会计和预测”。到目前为止，我已经进行了一些研究，并希望对当前的数据库设计和规范化有一些了解。 您对我当前的数据库设计有何想法和建议？我在下面提供了一些信息，以便更好地帮助您：) 披露：这是一个个人项目。不用于家庭作业或工作。 商业事实 银行ACCOUNT可以有很多ENTRIES An ENTRY可以是CREDIT或DEBIT 的ENTRY日期已计入贷方或借方 安ENTRY有一个PAYEE 一个ENTRY可以被关联到BUDGET CATEGORY A CREDIT的金额为ENTRY A CREDIT的说明ENTRY 一个CREDIT可以在未来计划 A的CREDIT频率和/或金额可能会重复出现 A DEBIT的金额为ENTRY A DEBIT的说明ENTRY 一个DEBIT可以在未来计划 A的DEBIT频率和/或金额可能会重复出现 A PAYEE有个名字 一个BUDGET有很多BUDGET CATEGORIES A BUDGET只能与一个日历月份关联 一个BUDGET CATEGORY可以包含许多ENTRIES A BUDGET CATEGORY有个名字 A BUDGET CATEGORY有BUDGET金额 A FORECAST有开始日期 A FORECAST有结束日期 A FORECAST有期初余额 一个FORECAST有很多FORECASTED DAYS 一个FORECAST有一个FORECASTED BUDGET A FORECASTED DAY有一个日期 …

8 sql-server  database-design  best-practices 

我查看了PostgreSQL的INSERT INTO .. ON CONFLICT (..) DO UPDATE ..语法并意识到，您不能使用它进行多个唯一的约束检查。我的意思是，您可以通过列名引用复合唯一索引ON CONFLICT (Name, Symbol)（如果为这两列定义了唯一索引），或者您可以使用主键。如果为列定义两个单独的唯一索引，则只能检查一个。 CREATE TABLE student (Id int primary key, Name varchar(50), Symbol varchar(50), CONSTRAINT col1_unique UNIQUE (Name), CONSTRAINT col2_unique UNIQUE (Symbol) ); INSERT INTO student (Id, Name, Symbol) VALUES (1, 'John', 'J'), (2, 'David', 'D'), (3, 'Will', 'W'); INSERT INTO …

8 postgresql  database-design  merge 

我最近将2016 SQL Server更新为SP2，并于2018年8月发布了最新的CU（KB4458621）。就在最后一天左右，我注意到我正在进行一些阻止。我无法杀死SPID b / c，这不是用户进程。根据SP_WHO2，命令为“查询存储ASYN”。我尝试通过Script和UI清除数据并禁用查询存储。似乎没有任何效果，它只是旋转然后开始引起更多阻塞。还有其他人遇到这个问题吗？谁能帮我弄清楚如何成功禁用查询存储吗？SP_WhoIsActive @show_System_SPIDS =以下1个结果（仅查询存储结果） 更新-这现在导致TempDB驱动器填满。尝试在几个小时后重新启动，看看是否可以解决问题。会及时向大家发布。 谢谢，内特

8 sql-server  sql-server-2016  blocking  query-store 

是否可以重载SQL Server函数？是标量（如ltrim），还是聚合函数（如count）？ 即使这是一个非常非常糟糕的主意。可能吗？ T-SQL用户定义的函数重载有什么重复？我要说的不是100％重复，因为那是2005版的。也许这已经改变了？

8 sql-server  functions 

假设数据库使用完全恢复模型，那么在SQL Server中（通过INSERT/ UPDATEetc）写入记录时，预先写入日志将确保在修改数据页之前将更改写入日志文件。 日志和数据页条目均在RAM中进行，然后由Checkpoint提交到磁盘。 如果发生系统崩溃（出于参数争用而断电），脏页（在RAM中更改但未提交到磁盘的IE数据）会发生什么情况，因为RAM的内容在系统重新启动后无法生存，是否会丢失数据？ ？ 编辑 经过一些测试，我可以看到脏页没有丢失，但是我不确定为什么： 使用本教程 创建一个测试数据库 CREATE DATABASE DirtyPagesDB GO USE DirtyPagesDB GO 关闭自动检查点 DBCC TRACEON(3505, -1); DBCC TRACESTATUS(); 创建一个表，插入一些数据并发出一个检查点： CREATE TABLE t1 (Speaker_Bio CHAR(8000)) GO INSERT INTO t1 VALUES ('SQL'),('Authority') GO CHECKPOINT 确认没有脏页 -- Get the rows of dirtied pages SELECT database_name = d.name, OBJECT_NAME …

8 sql-server  checkpoint 

对于支持哈希索引的每个Postgres版本，都有警告或注意，至少在8.3版之前，哈希索引比btree索引“相似或更慢”或“不更好” 。从文档： 版本7.2： 注意：由于哈希索引的用途有限，因此通常应优先选择B树索引而不是哈希索引。我们没有足够的证据表明即使进行=比较，哈希索引实际上也比B树更快。而且，散列索引需要更粗的锁。参见第9.7节。 版本7.3（以及最高8.2）： 注意：测试表明PostgreSQL的哈希索引与 B树索引相似或比B树索引慢，并且哈希索引的索引大小和构建时间要差得多。在高并发下，哈希索引的性能也很差。由于这些原因，不鼓励使用哈希索引。 版本8.3： 注意：测试表明PostgreSQL的哈希索引的性能并不比B树索引好，并且哈希索引的索引大小和构建时间要差得多。此外，哈希索引操作目前还没有进行WAL记录，因此在数据库崩溃后可能需要使用REINDEX重建哈希索引。由于这些原因，目前不鼓励使用哈希索引。 他们声称在此版本8.0线程中，从未发现哈希索引实际上比btree更快的情况。 即使是在9.2版中，根据该博客文章（2016年3月14日）： AndréBarbosa撰写的Postgres哈希索引，除编写实际索引外，其他任何方面的性能提升也几乎没有。 我的问题是那怎么可能？ 根据定义，哈希索引是一个O(1)操作，其中btree是一个O(log n)操作。那么，O(1)查找比查找正确的分支然后查找正确的记录要慢（或什至类似于）的可能性如何呢？ 我想知道索引理论到底有什么可能！

8 postgresql  index  btree  hashing 

给定该band表，其中包含json一个数组的列： id | people ---+------------- 1 | ['John', 'Thomas'] 2 | ['John', 'James'] 3 | ['James', 'George'] 如何列出每个名字所属的乐队数量？ 所需的输出： name | count -------+------------ John | 2 James | 2 Thomas | 1 George | 1

8 postgresql  group-by  json  array