标签: sql-server

表格或Type字段的最佳设计是什么？换句话说，鉴于此架构：intchar(1)

create table Car
(
    Name varchar(100) not null,
    Description varchar(100) not null,
    VehType .... not null
)

VehType成为 anint或 a是否更有效（在性能方面）char(1)？假设你有五种类型的汽车，你应该使用递增值 0 -> 4，还是类型的字符（比如；'v'、's'、'c'、't'、'm'）？

如果不止于此，我将使用单独的 Type 表并具有外键关系，但我认为没有必要这样做。

我注意到sys.objects目录视图为type字段使用了一个字符。有什么原因吗？我是否只是在稀薄的空气中抓住了它，这是我更舒服的吗？

在 SSMS 中创建表时，我意识到如果执行以下语句：

CREATE TABLE [tableName];

该表将在您自己的架构（而不是 dbo）下创建。因此，为了在 dbo 模式下创建它，您需要明确说明，如下所示：

CREATE TABLE [dbo].[tableName];

有谁知道一种方法（例如服务器范围的设置），以便在创建表时不需要指定 [dbo] 部分？

我试图找出一个简单的查询，我可以做一个简单的查询来测试一个大表是否有一个条目列表，在任何列中至少有一个空白（NULL/空）值。

我需要类似的东西

SELECT * FROM table AS t WHERE ANY(t.* IS NULL)

我不想做

SELECT * FROM table AS t WHERE t.c1 = NULL OR t.c2 = NULL OR t.c3 = NULL

这将是一个巨大的查询。

我有一个大表（约 5000 万行）我正在尝试批量插入 SQL Server，但出现错误：

无法为数据库“I 3 Stroke”中的对象“myDB”分配空间，因为“PRIMARY”文件组已满。通过删除不需要的文件、删除文件组中的对象、向文件组添加其他文件或为文件组中的现有文件设置自动增长来创建磁盘空间。

数据库中有另一个表，大约有 2500 万行。该数据库将仅在一台机器上使用，它旨在挖掘已经存在的数据，并且在任何情况下都不会超过其当前大小。

对于这种情况，解决此问题的最佳方法是什么，这样 SQL Server 就不会抱怨？这个数据库不会暴露给多个用户的解决方案是否重要？

我们正在使用带有唯一标识符的 SQL Server 2012，我们注意到在执行选择时在末尾添加了额外的字符（所以不是 36 个字符），它仍然返回与 UUID 的匹配项。

例如：

select * from some_table where uuid = '7DA26ECB-D599-4469-91D4-F9136EC0B4E8' 

返回带有 uuid 的行7DA26ECB-D599-4469-91D4-F9136EC0B4E8。

但是如果你运行：

select * from some_table where uuid = '7DA26ECB-D599-4469-91D4-F9136EC0B4E8EXTRACHARS'

它还返回带有 uuid 的行7DA26ECB-D599-4469-91D4-F9136EC0B4E8。

SQL Server 在进行选择时似乎忽略了 36 以外的所有字符。这是错误/功能还是可以配置的东西？

这不是一个大问题，因为我们在前端验证了长度，但对我来说这似乎不是正确的行为。

假设我有以下长时间运行的查询

UPDATE [Table1]
SET [Col1] = 'some value'
WHERE [Col2] -- some clause which selects thousands of rows

并假设在上述查询运行时执行以下查询

SELECT *
FROM [Table1]

第一个查询是否阻止第二个查询运行，直到第一个查询完成？如果是这样，第一个查询会阻止第二个查询在所有行上运行还是仅在 WHERE 子句中涉及的行上运行？

编辑：

假设第二个查询是

SELECT [Col1], [Col2]
FROM [Table1]
WHERE [Col2] -- some clause whose matching elements overlap those from
             -- the clause in the first query and which has additional matching elements

SQL Server 2016AT TIME ZONE似乎是不确定的。但是，我一直无法找到正式说明这一点或对其背后的推理给出理由的文档。

为什么是AT TIME ZONE不确定的？

显示非确定性的示例

执行：

CREATE TABLE Test (
    LegacyTimestamp DATETIME,
    Timestamp AS LegacyTimestamp AT TIME ZONE 'Eastern Standard Time' PERSISTED
); 

返回以下错误：

Msg 4936, Level 16, State 1, Line 1
Computed column 'Timestamp' in table 'Test' cannot be persisted because the column is non-deterministic.

在我正在处理的一个 Web 应用程序中，所有数据库操作都是使用一些在实体框架 ORM 上定义的通用存储库进行抽象的。

但是，为了通用存储库的简单设计，所有涉及的表都必须定义一个唯一的整数（Int32在 C# 中，int在 SQL 中）。直到现在，这一直是桌上的PK，也是IDENTITY.

外键被大量使用，它们引用这些整数列。它们对于一致性和 ORM 生成导航属性都是必需的。

应用层通常会做以下操作：

• 从表(*)加载初始数据-SELECT * FROM table
• 更新-UPDATE table SET Col1 = Val1 WHERE Id = IdVal
• 删除-DELETE FROM table WHERE Id = IdVal
• 插入-INSERT INTO table (cols) VALUES (...)

不太频繁的操作：

• 批量插入-BULK INSERT ... into table后跟 (*) 所有数据加载（以检索生成的标识符）
• 批量删除- 这是一个正常的删除操作，但从 ORM 的角度来看是“庞大的”：DELETE FROM table where OtherThanIdCol = SomeValue …

我正在运行一个查询，该查询给出有关内存的警告Excessive Grant。

使用的表和索引太多，包括复杂的view，因此很难在此处添加所有定义。

我试图找出我可能导致Excessive Grant. 可以转换吗？

查看执行计划，我可以看到以下内容：

<ScalarOperator
  ScalarString="CONVERT(date,[apia_repl_sub].[dbo].[repl_Aupair].[ArrivalDate] as [repl].[ArrivalDate],0)">
  <Convert DataType="date" Style="0" Implicit="false">
    <ScalarOperator>
      <Identifier>
        <ColumnReference Database="[apia_repl_sub]" Schema="[dbo]" Table="[repl_Aupair]" Alias="[repl]" Column="ArrivalDate" />
      </Identifier>
    </ScalarOperator>
  </Convert>
</ScalarOperator>

和这个：

<ScalarOperator ScalarString="CONVERT(date,[JUNOCORE].[dbo].[applicationPlacementInfo].[arrivalDate] as [pi].[arrivalDate],0)">
  <Convert DataType="date" Style="0" Implicit="false">
    <ScalarOperator>
      <Identifier>
        <ColumnReference Database="[JUNOCORE]" Schema="[dbo]" Table="[applicationPlacementInfo]" Alias="[pi]" Column="arrivalDate" />
      </Identifier>
    </ScalarOperator>
  </Convert>
</ScalarOperator>

这是查询，尽管您也可以在此处查看带有执行计划的查询：

DECLARE @arrivalDate DATEtime = '2018-08-20'

SELECT      app.applicantID,
            app.applicationID,
            a.preferredName,
            u.firstname,
            u.lastname,
            u.loginId                       AS emailAddress,
            s.status                        AS statusDescription,
            CAST(repl.arrivalDate AS DATE)  AS …

今天我发现存储我的数据库的硬盘已满。这种情况以前发生过，通常原因很明显。通常有一个错误的查询，这会导致对 tempdb 的大量溢出，它会一直增长到磁盘已满。这次发生的事情不太明显，因为 tempdb 不是驱动器满的原因，而是数据库本身。

事实：

• 通常的数据库大小约为 55 GB，它增长到 605 GB。
• 日志文件大小正常，数据文件很大。
• 数据文件有 85% 的可用空间（我将其解释为“空气”：已使用但已释放的空间。一旦分配，SQL Server 将保留所有空间）。
• Tempdb 大小正常。

我找到了可能的原因；有一个查询选择了太多的行（错误连接会导致选择 110 亿行，而预计会有几十万行）。这是一个SELECT INTO查询，这让我怀疑是否可能发生以下情况：

• SELECT INTO 被执行
• 目标表已创建
• 数据在选择时插入
• 磁盘已满，导致插入失败
• SELECT INTO 被中止并回滚
• 回滚释放空间（删除已插入的数据），但 SQL Server 不会释放释放的空间。

但是，在这种情况下，我不希望 由 创建的表SELECT INTO仍然存在，它应该被回滚删除。我测试了这个：

BEGIN TRANSACTION 
SELECT  T.x
INTO    TMP.test
FROM    (VALUES(1))T(x)

ROLLBACK

SELECT  * 
FROM    TMP.test

这导致：

(1 row affected)
Msg 208, Level 16, State 1, Line 8
Invalid object name 'TMP.test'.

然而目标表确实存在。不过，实际查询并未在显式事务中执行，这能解释目标表的存在吗？

我在这里勾画的假设是否正确？这是可能发生的情况吗？