连接 微软 SQL 服务器 适用于 Excel、Google Sheets、AI 和 REST

以 SQL Server 实际部署方式

实际情况很少像默认设置那样井然有序。连接细节反映的是人们实际采用的方案，而不是文档中描述的方案。

• 命名实例在服务器配置中以 SERVER\SQLEXPRESS 或 SERVER\PROD 的形式存在。除非您更改了实例，否则无需查找单独的字段，也无需提供端口号。
• 端口 1433 被假定为默认端口，并完全从连接字符串中省略；其他任何端口都按原样使用，因此 1435 端口上的实例不需要任何特殊设置。
• 一个连接对应一个数据库，同一个实例上的多个数据库实际上就是多个连接。 — 如果您的店铺采用这种模式，则每个店铺都需要有自己的登录信息和权限。
• 加密方式由您自行设置，是否信任自签名证书也由您决定。
• 身份验证方式为 SQL Server 身份验证 — 需要登录名和密码。不支持 Windows 和 Microsoft Entra 身份验证；如果您的实例设置为仅限 Windows，连接测试会明确提示，而不是显示莫名其妙的失败信息。

它具体会对你的实例造成什么影响？

任何维护生产环境 SQL Server 的人都想知道新增一个读取器会给他们带来多少成本。简而言之，每次只能创建一个连接，不会留下任何残留数据。

• 连接池已关闭，这是有意为之。查询之间不会在您的实例上累积空闲会话，这与大多数报表工具的做法恰恰相反。
• 取消操作确实会终止查询。当查询停止时，取消请求会发送到 SQL Server，从而终止查询的执行。 ——而不是让客户端离开，留下服务器处理一个无人阅读的结果。
• 在尝试登录之前，系统会检查网络连接情况，因此错误的主机名或关闭的端口会被视为网络错误，而不是登录失败并记录在错误日志中。 ——如果你有锁定政策，这一点就很重要了。
• 超时时间是明确的：默认连接时间为 30 秒，查询开始返回结果的时间为 35 秒。较长的结果流会根据需要持续返回。

能够经受住考验的 T-SQL 类型

将 SQL Server 数据导入电子表格时，精度往往会悄然下降。以下是一些已专门处理过的情况。

• datetimeoffset 会保留其瞬时值，并将其标准化为 UTC 时间，而不是将其转换为对下一个读者毫无意义的本地时钟时间。
• 小数和数值都保持其精度和比例。超出电子表格容量限制的值将以精确文本的形式传递，而不是进行无条件四舍五入。 — 错误的货币比不方便使用的货币更糟糕。
• 货币和小额货币以精确的小数形式到达，而不是浮点数。
• rowversion 和 timestamp 会以它们实际的 8 个字节的形式显示，而不是被误认为是日期，这是这些列被误读的最常见方式。
• uniqueidentifier 变为小写 GUID 字符串，sql_variant 和 hierarchyid 变为可读文本而不是被删除。

-- 处理特殊类型而非近似值 SELECT o.OrderId, o.PlacedAt, -- datetimeoffset -> UTC 即时值 o.RowVersion, -- rowversion -> 8 字节，非日期 o.Amount, -- money -> 精确十进制数 o.LedgerBalance -- decimal(38,10) -> 无损文本 FROM dbo.Orders AS o WHERE o.PlacedAt >= DATEADD(day, -30, SYSUTCDATETIME()) ORDER BY o.PlacedAt DESC;