12306的这个SQL语句为什么说明了12306效率低下?

#12306# 尼玛被注入,被爆库,也就算了,看看SQL 语句 ,like '%...%' 这就是所谓技术专家的牛B的负载系统?! 这么2的代码在我们这里都是无法容忍的!这就是12306效率底下,卡死的真相!所谓专家,你们就辩解吧。 真jb烂到家了。(http://weibo.com/1495169251/yDOqZChg9

连SQL语句是什么都不懂的人求简单易懂的答案!

推荐  (0) | 8人关注关注
5个答案
18 0

nasdaq软件工程师,小众软件爱好者

2012-09-27 21:48

只说性能问题的话。
首先select * 是第一个问题,这里*的涵义是检索出表中全部字段的数据。但很多场景下未必需要这样,只需要一部分数据的时候,用select * 就会增加不必要的数据流量,加大了数据库的负荷。(PS:还有一点就是select * 因为未指定字段名称,所以检索之前会有一个扫描表中所有字段的过程。普遍看法是会对性能造成一定的影响,但也有人认为这点影响微乎其微。)

其次 like '%...%' 这样的语句的涵义是全模糊查询(输入6可以查出6,36,63这样包含6的所有数据)但问题是,这样的全模糊查询是不走数据库索引(索引可以减小数据库的负荷)的,不可避免的要产生全表扫描。自然性能上也就差了。
业务上优化的话,首先要避免模糊查询。如果一定要用模糊查询的话,也要避免全模糊查询。比如 like '... %'这样的右模糊查询还是可以走索引的。全模糊查询很难做性能上的优化。

PS:另一位网友发表的看法。
@左耳朵耗子 上一条微博有人和我说SQL注入说Spring,我把 @caoz 的 的微博截图再发上来,我就是针对这条微博中的吐槽说like的问题,去12306看了下(http://t.cn/zl4pA6A)这就是一张字典表的查询,也就几十条记录,like就like了,so what?

其实这也是对的,性能优化只针对大数据量或频繁操作的表进行就可以了。而对于这个只有几十条的单表查询来做优化其实是没什么必要的。因为系统的瓶颈不在这里。

所以这个SQL看似未曾优化,实际上只能说明,开发的时候并不是很严谨的考虑了性能问题。而优化的时候由于不是瓶颈所在,所以也就没有必要进行优化了。

8 0

查看了一下这个页面,现在变成404了


我们来看看有啥问题吧。。。。。。。。。


1. SQL语句,大哥,你都不做参数过滤啊,不过滤的话要么象截图一样,数据库报错,要么就有人利用这个程序漏洞将所有数据清除掉,或者盗用用户隐私数据。单引号,分号什么的要么转义,要么就直接拒绝接收这种输入。

2. ziz这什么变量命名啊,英文缩写,拼音缩写?这程序是一次性的,不要维护?写完没人看了?

3. 访问数据库出现错误,你不抓异常吗?居然直接将服务器的错误让用户看到,给个错误页面啊!

2 0

游泳&下棋死理控、宅、情绪跳跃

2012-09-28 09:46
支持者: adoo23 两个意达

怀念在6502CPU上编程序时用A*A*A来替换A^3的时代。
再来个老笑话。
天堂的门坏了,管事的要修。德国人报价3000,印度人报1000,中国人报3000,然后和管事的商量,3000里面管事和中国人各1000,然后1000块给印度人干——甚至印度人会转包给干零工的代码奴来干。
天朝很多技术问题都是管理问题。

0 0

其实图片里想表达的意思是* 和 %通配符做了表扫描。模糊查询虽然说扫描全表,但也不代表不能使用。是否使用要看查询结果,如果说是字典表,记录也就几万行,单表查询也未尝不可。优化不是针对语句优化,而是针对查询结果和数据表记录进行优化。以sqlserver 为例子,建立了索引也不一定会提高查询效率,索引效率最高的情况是查询结果占总查询的4%左右。

所以用%和* 这里不能说明什么大问题

查看更多

添加回答

登录 后回答问题,你也可以用以下帐号直接登录

相关问答

关于我们 加入果壳 媒体报道 帮助中心 果壳活动 家长监控 免责声明 联系我们 移动版 移动应用

©果壳网    京ICP证100430号    京网文[2018] 6282-492号    新出发京零字东150005号     京公网安备11010502007133号

违法和不良信息举报邮箱:jubao@guokr.com    举报电话:18612934101    网上有害信息举报专区    儿童色情信息举报专区