我来帮你梳理下这个问题——你遇到的SELECT 1大量出现的情况，其实在Azure SQL Server里挺常见的，先帮你拆解下可能的原因、是否有风险，以及对应的排查方向：

可能的触发原因 #

• 客户端连接池的心跳检测：绝大多数时候，这类查询是应用程序使用的数据访问框架（比如ADO.NET、Entity Framework）发起的连接健康检测。当连接池要把闲置连接分配给新请求时，会执行SELECT 1来验证连接是否还可用。如果最近你调整过应用的连接字符串参数（比如Connection Lifetime、Min Pool Size），或者更新了数据访问库的版本，都可能导致这类查询激增。
• Azure SQL内部服务检测：Azure SQL的后台组件（比如故障转移组的健康校验、只读副本的同步状态检查）也会发起这类极简查询。如果最近你的实例经历过维护、开启了异地复制，或者调整过弹性伸缩配置，可能会临时或持续出现这类查询。
• 第三方监控/运维工具：有没有新部署过数据库监控工具、自动化运维脚本？很多监控工具会用SELECT 1来测试数据库连通性，如果频率设置过高，就会产生大量的探查器记录。
• 异常连接行为排查：虽然你说没有用户或应用主动发起，但可以通过以下SQL查询追踪发起方：

SELECT 
    s.session_id,
    s.login_name,
    s.host_name,
    s.program_name,
    r.command
FROM sys.dm_exec_sessions s
JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
WHERE r.command = 'SELECT' AND r.text LIKE '%SELECT 1%'

这个查询能帮你定位到具体的发起进程、登录名或者主机，排除是否有未知的连接源。

是否存在问题？ #

SELECT 1本身是极其轻量的查询，对数据库性能几乎没有影响。但如果这类查询的数量多到占用了大量连接数，或者导致SQL日志异常暴涨，那就要排查根源了。如果只是正常的心跳或健康检测，完全不用担心。

是否属于已知问题？ #

是的，这属于Azure SQL和数据访问框架里的常见情况。不少开发者都遇到过：比如特定版本的Entity Framework在默认配置下会频繁发起这类心跳查询；Azure SQL故障转移过程中，也会临时出现大量SELECT 1来验证实例可用性。只要不是异常激增导致资源占用，都属于良性的常规操作。

内容的提问来源于stack exchange，提问作者maxiperez