PawSQL最新版本针对DML和DQL新增了审核和重写优化规则共计33个,整体的规则数目达到了83个,覆盖了正确性,安全性、可维护性、性能四个方面的SQL质量问题,并提供了优化建议,已经形成比较完善的针对数据操作的SQL质量审查体系。本文介绍其中新增的11个正确性相关的审核规则。本文介绍新增的18个SQL性能审核及重写优化规则。
在MySQL的早期版本中,即使没有order by子句,group by默认也会按分组字段排序,这就可能导致不必要的文件排序,影响SQL的查询性能。可以通过添加order by null
来强制取消排序,禁用查询结果集的排序;PawSQL识别并进行了重写。
譬如下面的例子中
SELECT l_orderkey, sum(l_quantity)
FROM lineitem
GROUP BY l_orderkey;
在MySQL 5.x版本中,group by l_orderkey
会引起默认排序, 可以通过添加order by null
来避免该排序。
SELECT l_orderkey, sum(l_quantity)
FROM lineitem
GROUP BY l_orderkey
ORDER BY NULL;
数据库可以利用索引的有序性来避免GROUP子句中列的排序,从而提升SQL的性能。但是如果Group字段是一个表达式或函数,则可能无法利用索引来进行排序。
数据库可以利用索引的有序性来避免ORDER子句中列的排序,从而提升SQL的性能。但是如果ORDER字段是一个表达式或函数,则可能无法利用索引来进行排序。
ORDER BY 子句中的所有表达式需要按统一的 ASC 或 DESC 方向排序,才能利用索引来避免排序;如果ORDER BY 语句对多个不同条件使用不同方向的排序无法使用索引。
在数据库中,分组通常是通过排序或哈希来做,如果需要分组的行数比较多,那么单个字段长度会较大的影响分组效率。此规则可以通过比较分组字段的长度是否超过用户输入的阈值。如果超过阈值,则会进行预警。
负向查询指的是否定查询,即<>
、NOT IN
等否定条件。此类查询无法利用索引进行快速定位。
表连接缺少链接条件会导致结果集变成两个表的笛卡尔集,数据量巨大,且有较大可能性不符合开发者的预期。PawSQL会检查此类写法,并进行提醒。
在访问分区表时,没有使用分区字段进行过滤,会导致需要访问所有分区。
如果一个表的过滤条件上没有主键或索引,则会导致全表扫描。
在单机版数据库执行计划的规划中,表连接的顺序和连接的方法是数据库优化器最重要的规划内容。表连接数目的增加将几何级数地增加数据库优化器对于最优执行计划的搜寻空间,导致生成执行计划的时间比较长,且容易生成性能较差的执行计划。所以PawSQL检测查询中表连接的数目是否超过某个阈值,并提醒用户可能的风险。在PawSQL中,阈值的默认值是5,用户可以在创建优化任务时修改此阈值。
可以在SQL中指定排序字段所使用的COLLATION
,譬如下面的SQL
select * from customer c order by c_name COLLATE utf8mb4_0900_bin
这样的话,该SQL将无法利用索引的有序性来避免排序。
在计算机中,排序是一个OlnN时间复杂度的操作,如果需要排序的行数比较多,那么单个字段长度会较大地影响排序效率。此规则可以通过比较排序字段的长度是否超过用户输入的阈值。如果超过阈值,则会进行预警。
标量子查询返回单行单列的一个值,它可以出现在SQL中任何单值出现的地方。标量子查询通常需要在执行时才能确定其是否只返回单行值,且其通常为相关子查询。容易引起运行时错误,以及性能问题。
在MySQL InnoDB引擎或是SQL Server数据库中,数据存储方式都是以主键的方式组织的。在这种情况下,对主键的更新会涉及到对数据在磁盘上物理组织的调整,而且也涉及到主键值唯一性的检查,在表数据量非常大的情况下,更新的代价可能非常之大。
对唯一性约束的列的值的更新,需要对它进行唯一性检查,在表数据量非常大的情况下,更新的代价可能非常大。
表连接的误操作可能导致结果集的行非常大,对大结果集的DELETE/UPDATE可能会非常耗时,锁表时间较长,也难以对操作进行回滚。
某些内置函数可能不满足业务或是计算上的某些规范要求。通过配置该规则可以指定业务中需要禁止使用的内置函数。
PawSQL专注数据库性能优化的自动化和智能化,支持MySQL,PostgreSQL,Opengauss等,提供的SQL优化产品包括