共 3 篇相关文章
在Hive SQL处理数据关联时，针对少量uid-email映射数据，构造临时表是高效方案。本文介绍了两种主要方法：stack和union all。stack作为UDTF函数，能整齐生成二维映射，但必须通过lateral view展开以避免直接使用select列表导致的报错；而union all通过多次select拼接，兼容性强且易于手工增删。文章提供了完整代码示例，包括常见错误如stack报错及修正，并展示了如何与其它表进行join操作。此外，扩展讨论了不同规模ID关联的最佳实践：少量ID用IN子句，中等规模用stack或union all临时表，大规模或频繁复用则推荐上传文件或维护维表。这些方法优化了查询可读性和性能，适合数据工程师在临时分析或生产环境中参考。
这篇讲的是MySQL临时表，文章作者从实际开发中常见的“临时数据存储”需求出发，点出了MySQL临时表的两种主要形态：内存临时表（基于MEMORY引擎）和磁盘临时表（基于InnoDB或MyISAM引擎）。 文章的核心是对比这两种表在关键特性上的差异。比如，内存临时表速度极快但受内存大小限制，且默认使用哈希索引；而磁盘临时表容量更大，支持事务和更复杂的索引，但I/O开销相对较高。作者还解释了MySQL优化器何时会选择创建临时表，例如在处理复杂子查询、GROUP BY或ORDER BY操作时，并且详细说明了通过tmp_table_size和max_heap_table_size参数来控制内存表大小、决定何时溢写到磁盘的具体机制。 这篇文章的价值在于，它不仅告诉你临时表是什么，更深入剖析了其背后的存储与选择逻辑，帮助开发者在面对大量临时数据处理或复杂查询优化时，能更好地理解数据库的行为并做出合理的配置与设计决策。
这篇讲的是一个在数据库调优中常被提及的误区。很多DBA会习惯性地盯着Created_tmp_disk_tables指标，用它来判断临时表使用率，甚至以此评估服务器性能。作者从这个常见实践出发，明确指出：我们大可不必对这个数字过分敏感。 核心观点在于，Created_tmp_disk_tables本身并非问题根源，它只是一个结果。文章深入解释了MySQL创建磁盘临时表的几种正当场景，比如处理大型的BLOB/TEXT列，或临时表大小超过设定阈值。在这些情况下，使用磁盘是内存无法容纳时的合理且必要的选择。单纯追求“零磁盘临时表”可能意味着浪费了宝贵的内存资源。更关键的是，判断临时表效率需要结合Created_tmp_tables和Created_tmp_disk_tables的比值与绝对值来看，单看后者容易陷入“数字焦虑”。 作者最终引导读者将关注点从“消灭磁盘临时表”转移到“优化查询本身”。比如，通过调整tmp_table_size/max_heap_table_size参数，或更根本地优化SQL语句以减少临时表的使用。这篇文章帮助我们跳出对单一指标的执念，去理解指标背后的技术逻辑，从而做出更合理的性能评估与优化决策。
