怎样的SQL语句 才是好的SQL语句?

[ttsffgg]

在网上看到一些程序,然后有一些人出来对其进行点评
我看这些点评里面经常会出现类似这样的说辞

"连 select XXX from XXX where XXX like '%XXX%' 这样的垃圾语句也能写出来......(略)"


我是新手,各位前辈能不能指点一下,这种语句到底存在什么问题,为什么有人会说其是垃圾语句?如果存在问题又该如何改进?

[發糞塗牆]

第一步：要满足业务需求，不然的话，再快、再好看的代码都没有任何意义。顶多是个艺术品。 第二步：可维护性要高。我见过3000行无注释，要我优化，结果可想而已。死的心都有了。 第三步：高效，高效这个太难描述了，知道这么回事就行。 第四步：要有一定程度的可扩展性，因为业务会变，代码很难永远都不用修改。预留一些可用于扩展的，对以后修改有帮助。 暂时想到这些

[魔者侠心之明星级程序员]

没有最好，只有更好，+油

[daiyueqiang2045]

lz你提到的这个sql，具体要看是应用在什么场景，有时候出于业务需要这样的语句是没有什么问题的。 一般就是建好索引，提高你的查询效率就好。 这个是我整理的一个查询的规范，拿来分享一下 http://www.cnblogs.com/worfdream/articles/3030326.html

[andy_liucj]

不这么说怎么能显示某些人的优越性呢 不过 1. select × from tb 一般不推荐使用，要哪些列就取哪里列 2. select xxx from tb where yyy like '％zzz％' 如果YYY列上有索引的话，是不会使用索引的

[tigerssj]

新手学习中,高手是怎么写数据库代码的

[software_artisan]

我估计是某些半瓶醋看到where yyy like 'zzz%'就觉得自己高人一等了吧。

[shmilylove]

对于模糊查询 还是少用的好

[q740362425]

引用 8 楼 u010363004 的回复:

对于模糊查询 还是少用的好

模糊查询运用挺广泛的吧。。比如商品啊客户啊之类的，很多都会有要求模糊查询名称。。毕竟你不能要求用户吧整个名称全记住，或者那可能N长的编号

[jack15850798154]

个人感觉好的SQL和程序一样，1、高效率 2、可重用 3、可维护 4、可扩展

[只看远方]

没看具体环境,大数据量比如100万左右的数据量,使用like 性能消耗太高,无法使用索引,访问量大话,数据库负载太高,他批评的原因,可能是在没有非常必要的情况下使用了like

[fbmsyu]

别理他们，一看就是没经验的。 真正的生产环境，数据量小，这种查询完全没问题。 数据量大的环境，业务时间段内，这种语句你自己都不敢用，会拖慢整个系统。

[jack15850798154]

针对Like 的效率问题可以参考一下：http://3871584.blog.163.com/blog/static/335265642011112911051476/

[Magichi]

可能他喜欢select * from XXX 然后在代码里面判断，其实都一样，你*的东西可能会被更改，代码就会出错

[Magichi]

要不就是累程序员，要不就是累数据库管理员，两者都可以实现

[张雨露]

引用 1 楼 DBA_Huangzj 的回复:

第一步：要满足业务需求，不然的话，再快、再好看的代码都没有任何意义。顶多是个艺术品。 第二步：可维护性要高。我见过3000行无注释，要我优化，结果可想而已。死的心都有了。 第三步：高效，高效这个太难描述了，知道这么回事就行。 第四步：要有一定程度的可扩展性，因为业务会变，代码很难永远都不用修改。预留一些可用于扩展的，对以后修改有帮助。 暂时想到这些

学习了

[shmilylove]

引用 14 楼 张雨露 的回复:

[quote=引用 1 楼 DBA_Huangzj 的回复:] 第一步：要满足业务需求，不然的话，再快、再好看的代码都没有任何意义。顶多是个艺术品。 第二步：可维护性要高。我见过3000行无注释，要我优化，结果可想而已。死的心都有了。 第三步：高效，高效这个太难描述了，知道这么回事就行。 第四步：要有一定程度的可扩展性，因为业务会变，代码很难永远都不用修改。预留一些可用于扩展的，对以后修改有帮助。 暂时想到这些

学习了[/quote] 呵呵 是啊 模糊查询是很广泛

[美到心痛]

like '%XXX%' 也不是說不可以,對用戶來講,是很方便的,只有執行速度用戶能接受就可以了. 一般默認不加%,介面上加個checkbox模糊查詢,用戶點的時候,再用%.

[Mr_Nice]

引用 1 楼 DBA_Huangzj 的回复:

第一步：要满足业务需求，不然的话，再快、再好看的代码都没有任何意义。顶多是个艺术品。 第二步：可维护性要高。我见过3000行无注释，要我优化，结果可想而已。死的心都有了。 第三步：高效，高效这个太难描述了，知道这么回事就行。 第四步：要有一定程度的可扩展性，因为业务会变，代码很难永远都不用修改。预留一些可用于扩展的，对以后修改有帮助。 暂时想到这些

补充，要有推到重来的准备，一切都有可能变化。