TimBrown's questions

我们有一个使用 ORM 的应用程序，它不（容易）支持参数化查询。为了解决这个问题，我在我们的数据库 (SQL2008 R2) 上启用了强制参数化以避免缓存膨胀，并鼓励计划重用。

一个更复杂的查询没有被完全参数化，我已经将其缩小到 CASE 语句中使用的文字值：

SELECT
CASE WHEN auth_date > '2019-02-03 08:48:03' THEN authorisations.authorisation_amount END
FROM authorisations
WHERE auth_date > '2019-02-03 07:48:03'
AND merchant_id = 400000000031

（这个查询可能看起来不直观，但它是一组更大的嵌套子查询的片段，我们必须在最底层使用这个结构。这作为一个例子。）

查询计划使用的参数化语句为：

StatementText="select case when auth_date > '2019-02-03 08:48:03' then authorisations . authorisation_amount end from authorisations where auth_date > @0 and merchant_id = @1"

您会注意到 WHERE 子句中的文字已被参数化，但 CASE 语句中的日期文字尚未参数化。

为什么是这样？我错过了什么？我可以尝试解决这个问题吗？每次执行都会更改文字，所以目前，即使强制参数化，我最终也会为每次执行制定一个新计划。

我们有一个数据库，其中几个表被分区。这些表的主键（为简洁起见，PK）的形式为

• 交易日期，ID

其中transaction_date是分区键，id是唯一的整数列。如果我们没有对表进行分区，那么我们只会使用id作为 PK。

我们还有其他几个需要外键 (FK) 来引用这些分区表的表。我无法决定是使用复合 FK（引用 PK 的两列）还是使用单列 FK（引用唯一索引支持的id列）。

这两种方法有什么优点/缺点吗？到目前为止，我能想到的唯一因素（我什至可能在这些方面错了）是：

• 单列 FK：降低应用程序开发的复杂性。

• 复合 FK：在加入 FK 列时允许消除分区。

我一直在使用 CentOS 上的 SQL Server 为大型数据科学工作负载运行 PoC。我最近发现 SQL 只使用了 56 核服务器的 20 个核。我理解这是因为它是在 Server+CAL 许可模式下运行的，如 SQL 日志中的这条条目所示：

SQL Server 检测到 2 个插槽，每个插槽 28 个内核，每个插槽 28 个逻辑处理器，总共 56 个逻辑处理器；使用基于 SQL Server 许可的 20 个逻辑处理器。这是一条情报信息; 无需用户操作。

我知道我可以使用 mssql-conf 更改版本，但是是否可以更改许可模式以便我可以处理所有 CPU 插槽？

我正在尝试评估数据科学工作负载在大型数据集 (~200GB) 上的潜在性能。我们在 SQL Server 2017 中使用列存储索引取得了出色的结果。

然而，企业对节省成本很感兴趣，我已经向他们指出，列存储索引现在在标准版中可用，尽管内存限制为 32GB。可以通过查看 DMV sys.dm_column_store_object_pool来确定当前内存使用情况

我想知道是否可以限制列存储专用 RAM 分配以评估工作负载性能如何变化。

我知道可以限制 SQL Server 中的总 RAM 使用量，但这不会提供非常具体的列存储限制的真实指示。

我应该澄清一下，由于我们目前使用的是 Developer Edition，因此根本没有资源限制。