能，SQL Server中#temp表可建且建议建聚集索引，因其默认无索引，即使定义PRIMARY KEY也仅自动创建非聚集索引；不建聚集索引易导致堆表扫描、性能下降，应显式用CREATE CLUSTERED INDEX或建表时指定CLUSTERED关键字。
SQL Server 中 #temp 表能建聚集索引吗
能，而且必须建——#temp 表默认不带任何索引，即使你定义了 PRIMARY KEY 或 UNIQUE 约束，SQL Server 也只自动建非聚集索引（除非显式声明为 CLUSTERED）。不加聚集索引的临时表在 JOIN、ORDER BY、GROUP BY 场景下极易退化为堆表扫描，性能反而比原查询更差。
常见错误现象：EXPLAIN 或执行计划里看到大量 Table Scan 或 Clustered Index Scan（注意：这里“Clustered Index Scan”其实是假的，因为没聚簇索引，实际是堆扫描 + 隐式 RID 查找）；STATISTICS IO 显示逻辑读远高于主表扫描。
- 建表时直接指定聚集索引列：
CREATE TABLE #orders (order_id INT CLUSTERED, customer_id INT, amount DECIMAL(10,2)) - 或先建表再加：
CREATE CLUSTERED INDEX ix_tmp_oid ON #orders(order_id) - 若需按业务逻辑排序存储（如时间递增插入），优先选
order_date或复合键(customer_id, order_date)作聚集键
MySQL 临时表如何模拟聚集索引效果
MySQL 没有“聚集索引”语法开关，但 InnoDB 引擎下，PRIMARY KEY 就是天然的聚集索引。所以关键不是“建不建”，而是“主键选哪列”。临时表若漏定义主键，就退化为无序堆，后续 ORDER BY 或范围查询全靠文件排序（Using filesort）。
使用场景：比如统计每个客户的最近订单，中间结果要按 customer_id 分组再取最新一条——这时 PRIMARY KEY (customer_id, order_date) 能让数据物理上按客户+时间局部有序，极大减少排序和查找开销。
- 正确写法：
CREATE TEMPORARY TABLE tmp_last_order (customer_id INT, order_date DATE, order_id INT, PRIMARY KEY (customer_id, order_date)) - 错误写法：
CREATE TEMPORARY TABLE tmp_last_order AS SELECT ...→ 字段全为 NULLABLE，无主键，无索引 - 插入后立刻补索引：
ALTER TABLE tmp_last_order ADD INDEX idx_cid_dt (customer_id, order_date)（如果无法改主键）
临时表聚集索引失效的三个典型坑
建了聚集索引 ≠ 查询就走索引。以下情况会让聚集索引“形同虚设”：
- WHERE 条件没覆盖聚集键最左列：比如聚集索引是
(a, b, c)，但查询只写WHERE b = ?，优化器大概率放弃使用 - JOIN 时类型不匹配：临时表
customer_id是INT，主表却是BIGINT，隐式转换导致索引失效 - SELECT * 导致回表过多：InnoDB 聚集索引叶子节点存整行数据，但若字段太多（尤其含 TEXT/BLOB），实际 I/O 反而比非聚集索引+覆盖索引更重
验证是否真用上：在 SQL Server 中看执行计划里的 Seek Predicate；在 MySQL 中用 EXPLAIN FORMAT=TREE 确认是否出现 index_reader 或 range 访问类型。
存储过程中临时表生命周期与索引维护
临时表在存储过程退出时自动销毁，但索引不会“延迟重建”——每次 CREATE TEMPORARY TABLE 都是一次全新对象，索引必须在建表后立即创建，不能依赖“上次残留”。尤其在循环体中反复建临时表时，容易忘记重复建索引。
实操建议：
- 把索引创建语句紧接在
CREATE TABLE后面，不要隔行或放在条件分支末尾 - 避免用
SELECT INTO #t（SQL Server）或CREATE TEMPORARY TABLE AS SELECT（MySQL）隐式建表——结构不可控，主键/索引全丢失 - 高并发下慎用命名冲突：多个会话同时执行同一存储过程，
#tmp名称会被自动后缀唯一标识，但显式索引名（如ix_tmp_cid）可能报“已存在”，建议索引名也带会话特征或直接省略名称（SQL Server 允许匿名索引）
最易被忽略的一点：临时表的统计信息默认不自动更新。当插入数据量超过阈值（SQL Server 是 500 行 + 20% 变更，MySQL 是 1/16 表大小），优化器仍用初始空表统计，可能导致错误选择嵌套循环而非哈希连接。必要时手动更新：UPDATE STATISTICS #orders 或 ANALYZE TABLE #orders。
