PawSQL的博客

SQL查询中滥用派生表可能导致全表扫描等性能问题。本文通过真实案例展示了如何将低效的派生表查询（耗时12秒）通过PawSQL自动重写为LATERAL JOIN（0.2秒），性能提升61倍。文章解析了两种典型优化场景：窗口函数分页查询和分组聚合LIMIT查询，并详细说明了PawSQL的智能重写算法逻辑。该优化方法通过减少不必要的计算，将O(N²)复杂度降为O(N*K)。PawSQL的自动重写功能解决了手动改写的语法兼容性和易错问题，适用于多种主流数据库，为开发者提供高效、安全的SQL优化方案。

SQL开发中DISTINCT关键字的误用分析与正确实践 摘要：本文深入分析了SQL开发中DISTINCT关键字的常见误用问题。首先指出DISTINCT的本质错误在于混淆业务实体与度量指标的去重逻辑，强调去重应基于业务实体而非属性值。文章详细剖析了DISTINCT在多列（特别是浮点类型）场景下的精度陷阱，以及可能掩盖的JOIN逻辑错误、ETL管道问题和表设计缺陷等三大隐患。最后提出了五种正确替代方案：从源头修复重复问题、使用精确数值类型、基于业务主键去重、使用ROW_NUMBER()精确控制去重规则，以及完善

本文深入剖析了分布式数据库跨分片JOIN操作的性能问题。首先对比了三种主流架构（分片中间件、存算分离MPP、经典MPP）在处理跨分片JOIN时的不同执行路径，指出数据移动是性能瓶颈的核心原因。文章揭示了三大性能杀手：网络传输爆炸、协调节点单点瓶颈和数据倾斜，并提供了快速诊断清单。通过一个电商平台报表SQL拖垮集群的真实案例，展示了错误分布键设计导致的严重后果。最后强调优化目标是减少数据移动，让JOIN回归本地，为后续解决方案系列文章奠定基础。

大数据工程师的经典痛点当你在Hive中执行 SELECT MAX(salary) FROM 10B_table时，是否经历过单Reducer卡死数小时？无分组的聚合查询，会将所有数据压到单个Reducer，引发严重数据倾斜！PawSQL最新优化引擎通过零人工干预的智能优化，性能提升10倍+ ，彻底解决该问题。

PawSQL通过智能SQL重写优化索引使用效率，针对5类常见索引失效场景提供自动化解决方案：1）算术运算转换为等价表达式（如price+10>100重写为price>90）；2）日期函数替换为精确时间边界；3）类型转换反向处理；4）空值函数化简；5）字符串操作转为LIKE前缀匹配。该算法采用递归处理、运算符方向适配等技术，实现从全表扫描到索引扫描的性能跃升，执行时间从秒级降至毫秒级，显著降低资源消耗。这种自动优化既保持查询语义，又无需开发者具备深度优化经验。

DELETE逐行删除数据，支持WHERE条件，灵活性高但速度较慢；TRUNCATE则直接清空整张表，速度快但不支持条件删除。TRUNCATE的优势在于不生成每行删除日志，采用表级锁定，清空物理页，速度远超DELETE。然而，TRUNCATE不触发DELETE触发器，会重置自增列，且在有外键约束时无法直接使用。不同数据库对TRUNCATE的支持也有所不同，如MySQL的InnoDB支持回滚，而Oracle则不支持。正确使用TRUNCATE和DELETE，可以显著提高数据库操作的效率和安全性。

在SQL开发中，判断某条记录是否存在时，使用EXISTS通常比COUNT(*) > 0更高效。COUNT(*)需要遍历所有符合条件的记录，即使只需要知道是否存在一行，这在大数据量下会导致性能问题。而EXISTS具有短路特性，一旦找到符合条件的记录就会立即返回，避免了不必要的扫描。因此，在判断存在性时，EXISTS是更优的选择。PawSQL等工具可以自动将低效的COUNT(*)写法优化为EXISTS，进一步提升查询性能。

Lateral 查询是SQL中的一种连接方式，它允许FROM子句中的子查询引用同一FROM子句中前面的表的列。虽然这种特性提供了强大的表达能力，但在某些场景下可能导致性能问题。PawSQL优化器近日实现了一种针对特定类型Lateral Join的重写优化方案，以提升查询性能。

在数据库性能调优中,子查询优化是提升查询效率的关键点之一。今天,我们将分享一个使用 PawSQL 对EXISTS子查询进行重写优化的案例,展示如何通过合理的SQL重写与索引设计,实现超过487516.45%的性能提升!

在数据库性能优化领域，TPC-H 测试集是一个经典的基准测试工具，常用于评估数据库系统的查询性能。本文将基于 TPCH 测试集中的第 20个查询，结合 PawSQL 自动化优化工具，详细分析如何通过 SQL 重写和索引设计，将查询性能从 321 秒提升到 0.2 秒，性能提升高达1541倍。

过滤谓词下推（Filter Predicate Pushdown，简称FPPD）优化不是索引条件下推（Index Condition Pushdown，简称ICP）优化。ICP是在SQL执行时，把过滤条件下推到在存储引擎层进行数据过滤，减少在服务层的数据处理压力，进而提升SQL执行性能，ICP属于执行优化。FPPD优化通过尽可能的 “下压” 过滤条件至SQL中的内部查询块，提前过滤掉部分数据, 减少中间结果集的大小，减少后续计算需要处理的数据量，进而提升SQL执行性能，FPPD属于重写优化。

本篇介绍PawSQL优化引擎中的COUNT标量子查询重写优化，从正文可以看到，通过此重写优化，SQL性能的提升超过1000倍！

本文从两个角度阐述避免使用SELECT *的9个理由，同时讨论两个合理使用SELECT *的例外场景

​PawSQL性能巡检平台（Performance Patroller）是一款支持多种主流数据库的智能化性能巡检平台，具备以下核心特性：（1）全面的数据库支持，包括MySQL 5.6及以上版本、PostgreSQL 9.1及以上版本、openGauss 1.0及以上版本、阿里云RDS MySQL、达梦数据库、人大金仓数据库KingbaseES V8、MogDB等。（2）智能化的性能诊断能力：自动化慢查询采集与分析、基于语义的SQL重写优化、智能索引推荐、基于代价模型的性能验证、自动化数据库对象巡检。​

在数据驱动的现代世界，SQL查询的速度是应用程序快速响应的关键。尤其是那些涉及窗口函数的复杂查询，若缺乏恰当的索引支持，性能瓶颈可能会成为阻碍。本文将带您看看PawSQL是如何通过智能索引推荐，帮助一个包含窗口函数的查询性能提升50倍的。

在进行分页查询时，我们通常需要获取总记录数以计算总页数。传统方法是在原查询上添加count(1)或count(*)，但这在面对复杂查询时，会引入不必要的开销。

我们经常看到SQL优化规范要求避免order by random，原因是什么？有什么其他的替代方案吗？

你经常看到SQL优化技巧中说不要使用OR条件，这总是正确的吗？；不适用OR使用UNION一定能提升SQL性能吗？本文告诉你答案。

创建高效的索引最重要的原则是，基于您的工作负载（workload）创建索引，而不是基于您的表结构。 本文介绍索引创建时需遵循一些准则，以达到最佳的查询性能和数据维护效率，这些准则也是PawSQL索引推荐引擎的内部工作逻辑。

由于原生的MySQL和PostgreSQL都不支持表关联消除，PawSQL的JoinEliminationRewrite重写优化对它们是一个有意义的补充。在SQL被部署至生产环境真正执行之前，使用PawSQL可以把无意义的表关联给消除掉，避免数据库花费资源进行无意义的表关联操作。