SQL优化规则_07_Classic相关 - 03

建议为表添加注释

  • Content:为表添加注释能够使得表的意义更明确,从而为日后的维护带来极大的便利。
  • Case:
CREATE TABLE `test1` (
    `ID` bigint(20) NOT NULL AUTO_INCREMENT,
    `c1` varchar(128) DEFAULT NULL,
    PRIMARY KEY (`ID`)
)
ENGINE=InnoDB DEFAULT CHARSET=utf8

将复杂的裹脚布式查询分解成几个简单的查询

  • Content:SQL是一门极具表现力的语言,您可以在单个SQL查询或者单条语句中完成很多事情。但这并不意味着必须强制只使用一行代码,或者认为使用一行代码就搞定每个任务是个好主意。通过一个查询来获得所有结果的常见后果是得到了一个笛卡儿积。当查询中的两张表之间没有条件限制它们的关系时,就会发生这种情况。没有对应的限制而直接使用两张表进行联结查询,就会得到第一张表中的每一行和第二张表中的每一行的一个组合。每一个这样的组合就会成为结果集中的一行,最终您就会得到一个行数很多的结果集。重要的是要考虑这些查询很难编写、难以修改和难以调试。数据库查询请求的日益增加应该是预料之中的事。经理们想要更复杂的报告以及在用户界面上添加更多的字段。如果您的设计很复杂,并且是一个单一查询,要扩展它们就会很费时费力。不论对您还是项目来说,时间花在这些事情上面不值得。将复杂的裹脚布式查询分解成几个简单的查询。当您拆分一个复杂的SQL查询时,得到的结果可能是很多类似的查询,可能仅仅在数据类型上有所不同。编写所有此类查询是很乏味的,因此最好能够有个程序自动生成这些代码。尽管SQL支持用一行代码解决复杂的问题,但也别做不切实际的事情。
  • Case:
这是一条很长很长很长很长很长很长的SQL,案例略。

不建议使用HAVING子句

  • Content:将查询的HAVING子句改写为WHERE中的查询条件,可以在查询处理期间使用索引。
  • Case:
SELECT s.c_id,count(s.c_id) FROM s where c = test GROUP BY s.c_id HAVING s.c_id <> '1660' AND s.c_id <> '2' order by s.c_id

删除全表时建议使用TRUNCATE替代DELETE

  • Content:删除全表时建议使用TRUNCATE替代DELETE
  • Case:
delete from tbl

UPDATE未指定WHERE条件

  • Content:UPDATE不指定WHERE条件一般是致命的,请您三思后行
  • Case:
update tbl set col=1

不要UPDATE主键

  • Content:主键是数据表中记录的唯一标识符,不建议频繁更新主键列,这将影响元数据统计信息进而影响正常的查询。
  • Case:
update tbl set col=1

不建议使用存储过程、视图、触发器、临时表等

  • Content:这些功能的使用在一定程度上会使得程序难以调试和拓展,更没有移植性,且会极大的增加出现BUG的概率。
  • Case:
CREATE VIEW v_today (today) AS SELECT CURRENT_DATE;
    原文作者:在水一方_Eric
    原文地址: https://www.jianshu.com/p/adc14812cad1
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞