ctrl+k, ctrl+y 失效是因ssdt未安装或文档类型非sql；需确认为.sql文件、ssms≥18.0，并在选项中启用sql server data tools功能及格式化开关。
sql server management studio 里 ctrl+k, ctrl+y 不起作用？
这是最常被卡住的第一步：快捷键失效，不是你按错了，而是格式化功能默认被禁用或绑定冲突。ctrl+k, ctrl+y 是 ssms 内置 sql formatter 的触发组合，但它依赖两个前提——「sql server data tools (ssdt) 组件已安装」且「当前文档类型识别为 sql」。
常见错误现象：Ctrl+K, Ctrl+Y 按下后没反应、光标跳到别处、弹出“命令不可用”提示。
- 检查是否在
.sql文件中操作（新建查询窗口通常没问题；但若从.txt或.md打开再改后缀，SSMS 可能仍按文本模式解析） - 确认 SSMS 版本 ≥ 18.0（旧版如 17.x 默认不带 Formatter，需手动启用扩展或升级）
- 进入
工具 → 选项 → 文本编辑器 → Transact-SQL → 常规，勾选启用 SQL Server Data Tools 功能（部分版本叫启用 Transact-SQL 编辑器增强功能）
SSMS 格式化规则不生效？重点看这三项配置
内置 Formatter 不是“一键变美”，它严格按配置项执行。很多人调了缩进却没效果，是因为只改了 缩进大小，漏掉了更关键的开关。
路径：工具 → 选项 → 文本编辑器 → Transact-SQL → 格式化 → 常规
-
启用格式化必须勾选（默认可能关闭） -
将大写关键字转换为小写和将小写关键字转换为大写互斥，选一个，否则格式化后关键字乱跳 -
在 BEGIN 和 END 之间缩进语句块控制BEGIN...END内部对齐，不勾则IF块内语句顶格
示例：未启用 在 BEGIN 和 END 之间缩进语句块 时，这段代码格式化后不会缩进：
IF @flag = 1 BEGIN SELECT * FROM users WHERE id > 100 END
格式化后字段名/表名全大写？那是 关键字大小写 配置误伤了标识符
SSMS 的 Formatter 把 SELECT、FROM 当关键字处理，但默认配置会连带把 users、id 这类标识符也转成大写——这不是 bug，是它把所有“非字符串/数字”的 token 都当关键字扫了一遍。
根本原因：工具 → 选项 → 文本编辑器 → Transact-SQL → 格式化 → 大小写 中，将关键字转换为大写 开启后，Formatter 无法区分 SELECT 和 user_id（尤其当后者没加方括号）。
- 稳妥做法：关闭
将关键字转换为大写，靠人工或插件保关键字风格 - 折中方案：给标识符加方括号，如
[user_id]、[order]，Formatter 会跳过带括号的 token - 注意：
AS在别名前不加括号时也会被转大写，写成SELECT name AS [username]才安全
VS Code + mssql 扩展怎么替代 SSMS Formatter？
SSMS 格式化能力弱、配置反直觉，很多团队直接切到 VS Code。但 mssql 扩展本身不带 Formatter，得靠 sql-formatter 或 pgFormatter（兼容 T-SQL）这类后端驱动。
实操要点：
- 装好
mssql扩展后，再装SQL Formatter（作者：adpyke），它支持Ctrl+Shift+P → Format Document - 在
settings.json里配"sqlformat.language": "tsql"，否则默认按 PostgreSQL 规则格式化，TOP会被干掉 - VS Code 的
editor.formatOnSave对 SQL 文件默认关闭，要手动打开，否则保存不触发
性能影响很小，但首次格式化大文件（>500 行）可能卡顿 1–2 秒——这是 node.js 启动解析器的冷启动延迟，不是扩展问题。
复杂点在于：不同 Formatter 对 GO 批处理分隔符的支持不一致。SSMS 内置的能识别 GO 并分段格式化；而多数 VS Code 插件会把它当注释忽略，导致后续语句缩进错乱。真要用，要么删 GO，要么换支持批处理的插件（比如 sqltools 配 sqltools-postgres-driver，虽名字带 postgres，但 T-SQL 兼容性反而更好）。
