MYSQL优化之LIMIT

我们知道,一套应用程序的运行,除了程序代码的质量,硬盘磁盘的I/O,还有一个就是SQL的高并发及查询了;

代码的质量在于程序员们如何去优化,磁盘I/O可以使用负载均衡,至于SQL当然也是可以使用负载均衡,然后进行数据的交互同步即可。当然了,前提是,做一个完善的负载均衡,站在作者的立场上来看,弄个光钎转线+服务器的一次性配置,没有个10万下不来,如果是精益求精的服务需求,单是服务器的配置就得200万+,所以,土豪老板和开发者就免看了!

在此对蛋蛋工作室的小张说声对不起,由于最近项目时间太紧,没去给他优化SQL的检索优化。

本文暂不提供MYSQL完整的负载均衡部署方式!

SQL,开发人员都知道是用来存储数据的,居然是存储数据,就会占用文件资源,我见过最大的数据库是几十GB的,当然数据量是近亿行;

我们来假设一下,一个10GB的数据库表数据,从中读取数据的时候,磁盘的I/O要占用多少?哪怕只是在UNIX里打开,也是吓人的,然后再进行SQL的查询。可以想象成10GB的数据是足球场,在座的每一位观众是一个数据,要想在足球场中找出某个人,是多么的难?

因此,有了索引、主键;好比我给每个观众捆绑一个座位号(比如ID主键),这时候,我要知道哪个用户在哪,直接通过ID就能马上获取了对应的位置,要找就好找了,因为我有了详细的座位号了!

跑题了,回到主题,LIMIT

一个高效的SQL语句,是脱离不开LIMIT的,比如用户的登陆

“SELECT user,password FROM `user` WHERE `user`=’$user’ AND `password`=’$password’ LIMIT 1;

这语句是不是感觉有点多余了? 用户名和密码都验证了,干嘛还判断?

正确的答案是,必须要!

假设阿里的淘宝用户是几个亿,如果都在一个表内,不进行LIMIT 1,SQL会全盘扫描,哪怕后面的数据没有重复的,都会全部扫下去,然后把对应的数据提取出来,如果一个1G的用户表,需要耗时是多少?

当然,如果有足够的服务器,可以把用户名+ID写入MEMCHACHE等缓存系统,在通过用户名获取对应的ID

然后”SELECT user,password FROM `user` WHERE `user`=’$user’ AND `password`=’$password’ WHERE `id`= x;的方式来进行,ID设置个主键,0秒内查询出基本不是问题。这也是负载均衡常用的做法;

就这一个简单的用户登陆查询,我想你看到这的时候,已经理解深刻了吧?

特别商城网站,为什么要有翻页?翻页原理有什么好?

1:优化用户视觉体验,不会被那么多的产品混淆;

2:数据的提取;

作者以前也写过一个留言版,是支持翻页的,当然,就是需要LIMIT来进行控制了。

执行全盘扫描的时候,先LIMIT 1 100;二次执行的时候LIMIT 101 200;以此类推,避免了数据量千万级甚至亿级的全盘扫描导致服务器宏机!

 

 

This entry was posted in MYSQL.

发表评论

:wink: :-| :-x :twisted: :) 8-O :( :roll: :-P :oops: :-o :mrgreen: :lol: :idea: :-D :evil: :cry: 8) :arrow: :-? :?: :!: