MSSQLServer数据库的字段类型

上周一位客户问我MSSQLServer数据库字段类型之间有什么区别，这让我有点困惑。
毕竟种类有很多。
你问我3 6 划？我自己算过，看起来好像没有那么夸张，但实际上也不少。
给我印象最深的是经常使用的：
整数类： int：存储常规整数，从-2 ^3 1 到2 ^3 1 -1 它最常用，例如存储用户 ID。
Smallint：范围较小，-3 2 k到3 2 k，节省内存，一般用不到。
tinyint：0到2 5 5 ，正好适合存储状态码等。
h3int：当数字特别大时使用，比如分布式ID等。

日期时间类： 日期：只有日期，没有时间，例如生日等。
datetime：日期+时间，精确到百分之三秒，这就够了。
datetime2 ：比datetime精度更高，还可以存储小数秒。
新项目通常会使用它。
Smalldatetime：精确到分钟。
在老系统中很常见，现在基本不用了。
time：只有时间，没有日期，比如工作时间等。

文本类： char：固定长度的非Unicode文本，适合存储ID号之类的，填充空格。
varchar：变长非Unicode文本，最常用的文本类型，如姓名、地址等。
nchar：固定长度的Unicode文本，支持中文和英文，但长度限制为4 000。
nvarchar：变长Unicode文本，比varchar长。
现在基本都选择这个了，尤其是存储很多汉字的时候。
text/ntext：这是一种旧的数据类型。
不再建议使用可变长度文本。
请改用 varchar(max)/nvarchar(max)。

其他特殊类型： bit：存储布尔值，0、1 、NULL。
通常不使用位。
最好使用tinyint或int来存储状态。
钱/零钱：保存货币，精度有限，现在小数更准确。
小数/数字：存储精确的小数，例如价格、金额等。
您自己决定精度。
float/real：存储近似小数，精度较低，常见于科学计算中。
binary/varbinary：存储二进制数据，例如图像、文件等。
现在varbinary(max)就足够了。
xml：存储XML数据。
现在许多系统都必须处理 XML。
地理/几何：存储地理空间数据，仅由 GIS 系统使用。
hierarchyid：存储树形结构的数据，比如组织结构等，很少使用。
uniqueidentifier：存储GUID，全局唯一ID，通常用于分布式系统。
rowversion：数据库中自动递增的唯一二进制数，通常用于版本控制。

你问我为什么不用图片？这是一个老东西了，现在我们都使用varbinary(max)。
ntext 早已被淘汰，nvarchar(max) 才是出路。
我很少使用bit类型，感觉没有那么直观。

我自己遇到的坑就是之前接手了一个老系统，里面都是文字和钱，导致查询非常慢。
改成varchar(max)和decimal后，速度快多了。
因此，在选择类型时，不仅要看范围，还要看性能和兼容性。

无论如何，你使用什么取决于你的情况。
使用 nvarchar 存储中文，int 或 h3int 存储数字，decimal 存储金额，datetime2 存储时间，varbinary(max) 存储图像。
一旦您了解了自己的需求，剩下的就只剩下多项选择题了。

sql server内存暴涨如何解决

严格来说，控制SQL Server内存爆炸只有三个步骤：设置内存限制；监控系统监控；优化 SQL 和索引。

我们先来说最重要的事情：设置内存限制。
去年我们跑一个8 G内存的项目时，直接把最大内存设置为6 G，结果就翻转了——后来发现批处理任务突然放到了后台池化了。
用俚语来说，这称为雪崩效应。
事实上，前面任何小的延迟都会延迟后面的一切。
当系统上没有其他高负载程序时。
7 0%-8 0%是安全区。
但是，如果Exchange和ERP同时运行。
之前我以为总内存的 7 0% 就足够了。
结果，我意识到挂起的内存队列（Memory Grants Pending）已经增长到5 00+，我不得不为操作系统保留2 -4 G。

另一个原因是监控监控指标。
SQLServer:MemoryManagerMemoryGrants 等待在 Windows 性能监视器中尤为重要。
去年的一个项目中，这个值一直稳定在3 000以上，直接把SQL Server调成了内存吸盘。
比较设定值和缓冲池（BufferPool）的实时存在情况就会知道查询是否太愚蠢。
不或者它可以帮助确定是否存在内存泄漏，但不要太认真。
实际入住率比设定值高1 0%至2 0%；这是正常损失。

还有一个非常重要的细节，就是优化SQL和索引。
检查 sys.dm_exec_query_memory_grants。
去年，我发现一个报表查询将所有 3 000 行数据加载到内存中，这直接耗尽了缓冲池。
暂时忽略标签；执行计划中的“嵌套循环”可能比丢失索引更致命。

说实话，这很令人困惑。
许多人并不关心内存优化表（MEMORY_OPTIMIZED_DATA）消耗额外的内存这一事实。
去年我们测试列存储索引时；我没有单独查看这个几乎使服务器崩溃的计数器。

建议在重新启动之前运行 DBCC DROPCLEANBUFFERS，因为它可以避免许多问题。
但是重启对于业务的实时性影响是巨大的，这取决于你的业务的容错能力。