咱们一个个来拆解这些关于SQL Server永久表临时索引的疑问：

1. 永久表上临时索引的作用域是什么？ #

首先得澄清一个关键误区：SQL Server里根本不存在“永久表上的临时索引”这种原生对象。当你给永久表创建名字带#的索引时，它本质还是个永久索引，只是名字里包含#而已。

如果你误以为想创建“仅当前会话可用的索引”——抱歉，SQL Server并没有原生支持这个特性。真正的临时对象（比如临时表#temp）是会话级的，但永久表上的索引，不管名字带不带#，都是全局可见的，作用域覆盖整个数据库，所有有权限的会话都能看到并访问它。

2. 存储过程里执行那条CREATE INDEX语句，是正确的创建方式吗？ #

完全错误！这就是你遇到报错的核心原因。

你写的这条语句：

CREATE NONCLUSTERED INDEX #IX_MyTempIndex ON dbo.MyPermTable (ColumnA, ColumnB) INCLUDE (ColumnC);

看起来像是要创建临时索引，但SQL Server不会因为名字带#就把它当成临时对象处理——它会在dbo.MyPermTable上创建一个永久索引，名字就是#IX_MyTempIndex。

所以当其他会话（哪怕是几天后）尝试创建同名索引时，自然会抛出“索引已存在”的错误——因为这个索引一直躺在永久表上，根本没被自动清理掉。

如果你的需求是“只为当前会话的查询优化创建临时索引”，正确的做法是：

• 把需要的数据集导入临时表（比如#MyTempTable），然后在临时表上创建索引——临时表的索引才是会话级的，会话断开就自动销毁
• 如果必须用原表，考虑创建常规永久索引，用完后显式DROP；或者使用查询提示（比如WITH (INDEX(...))）来强制优化器使用特定索引，避免创建临时索引的需求

3. 哪些事件或作用域会导致这类“伪临时索引”消失？ #

因为这些带#的索引本质是永久索引，所以只有处理永久索引的操作才能让它消失：

• 显式执行DROP INDEX #IX_MyTempIndex ON dbo.MyPermTable;
• 删除基表dbo.MyPermTable（这显然是极端情况）
• 执行ALTER TABLE操作破坏了索引的依赖关系——比如修改索引键列的数据类型、删除索引包含的列，或者把列设置为计算列且更改表达式，导致索引被自动删除

重要提醒：创建它的会话断开连接不会自动删除这个索引！这是和真正临时对象最核心的区别，很多人都会踩这个坑。

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