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;