临时表优于视图聚合，因其可建索引、避免嵌套膨胀、精确控制字段与排序、降低内存开销；视图每次重算、无法索引、易导致Spill和内存失控。
视图聚合不走索引，临时表可以建索引
视图本身不存数据，每次执行都得重跑底层查询 + 全量分组，中间结果集无法复用；而临时表是物理对象，你可以在它上面显式建索引，让 GROUP BY 直接走索引扫描或索引覆盖。比如在 SQL Server 里对 #orders_agg 建 CREATE INDEX IX_user_id_amount ON #orders_agg (user_id) INCLUDE (amount)，后续聚合就能避免哈希构建。
- 普通视图里写
GROUP BY user_id，即使基础表有索引，优化器也常因统计信息不准或谓词下推失败而放弃使用 - 临时表插入完成后立刻建索引，能强制让后续聚合走 Nested Loops 或 Stream Aggregate，大幅降低内存压力
- MySQL 的
CREATE TEMPORARY TABLE不支持INCLUDE，但联合索引如(status, created_at)仍可支撑GROUP BY status而不回表
视图嵌套导致执行计划失控，临时表边界清晰
当视图 A 引用视图 B，B 里又含 DISTINCT 或 LEFT JOIN，优化器很难准确估算中间行数，容易把本该 1 万行的结果膨胀成 50 万行——这直接抬高内存授予（memory grant），触发 Spill to TempDB 或 Created_tmp_disk_tables 暴涨。临时表则不同：你控制什么时候建、插多少、加什么索引，执行路径完全可控。
- EXPLAIN 显示
select_type = DERIVED且rows接近底层表总数，基本确认视图被物化且未下推 - SQL Server 执行计划里看到
Hash Match Aggregate节点带SpillLevel="1"，说明哈希表已溢出到磁盘 - 临时表命名明确（如
#user_active_2026Q2），不会被优化器反复展开，也不会受外层查询干扰
SELECT * 是视图的隐形内存杀手，临时表天然精简
视图定义里只要出现 SELECT *，数据库就可能加载 TEXT、JSON、BLOB 等大字段进内存，哪怕你最终只取 id 和 sum(amount)。临时表默认只存你需要的列，字段类型和长度也可精确控制，单行体积小，哈希分组时内存占用自然低。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- PostgreSQL 中一个
TEXT字段会让临时表直接落盘，哪怕只有一行；而CHAR(10)就不会 - MySQL 的
max_heap_table_size对视图无效，但对CREATE TEMPORARY TABLE生效，你可以按需设为128M - SQL Server 里用
SELECT INTO #temp会跳过索引定义阶段，务必改用CREATE TABLE #temp (...) + INSERT INTO #temp SELECT ...
ORDER BY 在视图里等于主动放弃下推
视图里写 ORDER BY created_at DESC，外层再加 LIMIT 10，PostgreSQL 和 SQL Server 都大概率不合并排序逻辑——结果是全量排序后再截断，内存消耗和数据量成正比。临时表没这问题：你只在真正需要排序时才加 ORDER BY，且能确保字段有索引支撑。
- EXPLAIN (ANALYZE, BUFFERS) 显示
Plan Rows: 1200000却只取 10 行，说明排序没下推 - 删掉视图里的
ORDER BY，外层显式写ORDER BY id DESC LIMIT 10，并确保id是聚集索引键 - 临时表上建
CREATE CLUSTERED INDEX IX_id ON #temp (id DESC)，TOP 10就能直接 Seek，不占额外内存
视图聚合的内存开销不是来自语法本身，而是执行路径不可控：你没法给“逻辑定义”建索引，也没法阻止优化器展开嵌套、加载多余字段、重复排序。临时表虽然多写几行代码，但它把控制权交还给你——这才是大数据量下真正能压住内存的关键。
