sql语句太长有什么坏处吗？

一条select语句竟然长达一百多行，虽然中间通过union all连接的，不过我想知道sql语句太长有啥大的坏处吗？我是不是应该把它简化比较好？

不能说坏处，有很多数据库本身的结构、算法就比较复杂，语句长是很正常的。只是同等效果的语句，尽量选择精简的。还有就是书写的格式，很重要，尽量多使用分行书写。语句的效率主要体现：
1、可读性，也就是再次查看、修改sql语句时，容易阅读。
2、执行效率，如一些重复分组、重复的计算，造成的语句执行速度缓慢。

呵呵，二楼说的特别有尿性啊

我什么都不说了，顶二楼！！！！！ 顺便更正二楼一个问题，是存储过程，不是储蓄过程

太长会影响数据库的解析速度，但是影响是比较小的，关键是语句的执行效率要高。

sql语句的效率问题跟长度没任何关系，长没关系，但只要注意一下编写格式，那么别人看起来也比较清晰，不会显得太乱。 特别要注意的就是每一行的代码不要太长，多分行是很好的习惯

1.不方便维护. 试想一下，一条长达100多行的查询语句如果维护起来时怎样的麻烦，如果有详细的注释还好说，不然要查看100多行的查询语句，更何况是一条...任何一个程序都是最少有百八十条的。 2.运行速度低 如果只是查询一张表不可能会有100多行，即使列再多像这样SLEECT INT_Id, CHR_Username...就这样一个列整一行也到不了100行吧..更合况设计表时要遵守三范式..那么多列的一张表，不能说没有，不过对于做普通项目的数据库,那也太菜了...证明肯定是多表联查的,一般想这种情况就用储蓄过程了，或是建立一个视图，查询视图。 3.结构清晰 现在不仅仅是数据库设计,包括所有的代码都不是将运行速度作为唯一的衡量的标准了，结构的清晰，代码的易懂也是不可缺少的东西，100多行的查询有些繁琐，肯定是要简化的，加上必要的注释，或者将一部分封装成储蓄过程，再调用,显然要比这样好.