我们知道，一套应用程序的运行，除了程序代码的质量，硬盘磁盘的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；以此类推，避免了数据量千万级甚至亿级的全盘扫描导致服务器宏机！