一般来说，我总是使用 Ints。我知道理论上这不是最佳实践，因为您应该使用保证存储数据的最小数据类型。
例如，tinyint当您知道将存储的唯一数据是 1、0 或 null（以后将其扩展为 2 或 3 的可能性很小）时，最好使用。
但是，我知道这样做的唯一原因是出于存储目的——在一行中使用 1 个字节而不是 4 个字节。
除了节省硬盘空间之外，仅使用tinyint（smallint甚至bigint）会产生什么影响int？
在 SQL Server 2005 中，如何获取没有时间部分的当前日期？我一直在使用，GETDATE()但希望它的时间为 00:00:00.0
当我尝试删除数据库时，出现错误“无法删除数据库“dbname”，因为它当前正在使用中”。但是，当我运行时sp_who2，肯定没有连接到该数据库的会话。我还将数据库设置为single_user mode with rollback immediate.
为什么会这样？
查询是包含许多分组级别和聚合操作的单个选择。使用 SET ARITHABORT ON 只需不到一秒钟，否则需要几分钟。我们已经在 SQL Server 2000 和 2008 上看到了这种行为。
使用 LEFT JOIN 或 NOT EXISTS 格式之间是否有最佳实践？
使用一个比另一个有什么好处？
如果没有，应该首选哪个？
SELECT *
FROM tableA A
LEFT JOIN tableB B
ON A.idx = B.idx
WHERE B.idx IS NULL
SELECT *
FROM tableA A
WHERE NOT EXISTS
(SELECT idx FROM tableB B WHERE B.idx = A.idx)
我在 Access 中对 SQL Server 数据库使用查询。
是否有 T-SQL 查询显示某个数据库的上次还原日期时间？
考虑一下SO 上的这个答案，它使询问者对<>运营商感到放心：
<>是 ... 与 相同!=。
但随后一位评论者插嘴说：
确实，它们在功能上是相同的。但是，SQL 优化器如何使用它们是非常不同的。=/!= 被简单地评估为真/假，而 <> 意味着引擎必须查看该值是大于还是小于，这意味着更多的性能开销。只是在编写可能很昂贵的查询时需要考虑的事情。
我相信这是错误的，但为了解决潜在的怀疑论者，我想知道是否有人可以提供权威或规范的来源来证明这些运算符不仅在功能上相同，而且在所有方面都相同？
[敬礼]
（检查一个）
[ ] Well trained professional, [ ] Casual reader, [ ] Hapless wanderer,
我有一个（检查所有适用的）
[ ] query [ ] stored procedure [ ] database thing maybe
运行良好（如果适用）
[ ] yesterday [ ] in recent memory [ ] at some point
但现在突然变慢了。
我已经检查过以确保它没有被阻止，并且它不是某些长时间运行的维护任务、报告或其他带外进程的受害者。
有什么问题，我应该怎么做，我可以提供哪些信息来获得帮助？
[*Insert appropriate closing remarks*]
performance sql-server execution-plan parameter-sniffing query-performance
自 SQL Server 6.5 以来，我一直在使用 SQL Server，但仍然萦绕在我脑海中的旧建议是永远不要进行就地升级。
我目前正在将我的 2008 R2 DEV 和 TEST 系统升级到 SQL Server 2012，并且需要使用相同的硬件。不必恢复我的报告服务配置的想法非常有吸引力，我真的很聪明。不涉及分析服务或任何不寻常或非标准的东西——只安装了数据库引擎和报告服务。
有没有人遇到过就地升级的严重问题？或者我应该重新评估我对就地升级的立场？
我们正在研究开发一种工具来捕获和分析我们收集的大量网络流量数据。每天我们捕获大约 14 亿条流记录，它们的 json 格式如下所示：
{
"tcp_flags": "0",
"src_as": "54321",
"nexthop": "1.2.3.4",
"unix_secs": "1352234521",
"src_mask": "23",
"tos": "0",
"prot": "6",
"input": "105",
"doctets": "186",
"engine_type": "0",
"exaddr": "2.3.4.5",
"engine_id": "2",
"srcaddr": "9.8.7.6",
"dst_as": "12345",
"unix_nsecs": "752265174",
"sysuptime": "2943529544",
"dst_mask": "24",
"dstport": "80",
"last": "2943523241",
"srcport": "52672",
"dpkts": "4",
"output": "111",
"dstaddr": "6.5.4.3",
"first": "2943517993"
}
我们希望能够对数据集进行快速搜索（少于 10 秒），最有可能在很短的时间内（10 - 30 分钟间隔）。我们还希望索引大部分数据点，以便我们可以快速搜索每个数据点。我们还希望在执行搜索时拥有最新的数据视图。留在开源世界会很棒，但我们不反对为这个项目寻找专有解决方案。
这个想法是保留大约一个月的数据，这将是大约 432 亿条记录。粗略估计，每条记录将包含大约 480 字节的数据，相当于一个月内约 18.7 TB 的数据，可能是索引的三倍。最终，我们希望增加该系统存储数万亿条记录的能力。
我们已经（非常基本地）评估了 couchbase、cassandra 和 mongodb 作为这个项目的可能候选者，但是每个人都提出了自己的挑战。使用 couchbase，索引是每隔一段时间完成的，而不是在插入数据期间完成，因此视图不是最新的，cassandra 的二级索引在返回结果方面效率不高，因为它们通常需要扫描整个集群以获取结果，而 mongodb 看起来很有希望但是由于它是主/从/分片，因此扩展似乎要困难得多。我们计划评估的其他一些候选者是 elasticsearch、mysql（不确定这是否适用）和一些面向列的关系数据库。任何建议或现实世界的经验将不胜感激。