mysql调技巧做好limit优化.docVIP

我们在查询数据时，往往需要指定返回几行数据。如现在有一个B/S架构的应用程序，其每一页可能只显示30条记录。此时为了提高显示的效率，一般就要求数据库一次只返回三十条纪录。等用户按下一页的时候，再从数据库中返回30条记录，以此类推。这可以缩短数据显示的时间。当查询的基表比较大时，这个措施非常有效。此时可以使用Limit关键字来实现这个需求。Limit子句可以被用于强制Select查询语句返回指定的记录数量。　　 通常情况下，Limit关键字可以接受一个或者两个数字参数。需要注意的是，这个参数必须是一个整数常量。如果用户给定两个参数，则第一个参数表示第一个返回记录行的偏移量，第二个参数则表示返回记录行的最大数据。另外需要提醒的是，初始记录行的偏移量是0，而不是1。不少用户会在这里犯错误。 　　虽然使用了Limit语句来限制返回的记录数，从而可以提高应用程序的工作效率。但是其也会给系统的性能带来一些负面影响。如可能会导致全表扫描等等。为此笔者给出一些Limit关键字的优化的建议，以供大家参考。 　　建议一：灵活使用Limit 0子句 　　根据Limit关键字的定义，如果参数为0的话，则其返回的是空记录。这看起来好像没有多少的意义。其实不然。在实际工作中，灵活使用这个0参数，能够给我们带来很大的收获。 　　如现在数据库工程师想要确认一下某个查询语句的有效性，如果直接运行这个查询语句，需要等待其返回的记录。如果涉及的纪录数量比较多，或者运算逻辑比较复杂，那么需要等到比较长的时间。此时就可以在Select查询语句中，使用Limit 0子句。只要查询语句没有语法上的错误，这就可以让数据库快速的返回一个空集合。从而帮助数据库设计人员迅速的判断查询语句的有效性。另外这个空集和中还会返回某个表的各个字段的数据类型。即通过这个Limit 0子句还可以查询某个表的表结构。 　　可见灵活应用Limir 0子句，确实能够给我们带来不小的收益。不过需要注意的是，在某些特定的场合下，这个子句可能不会奏效。如通常情况下，在Monitor工作环境中不支持这个Limit 0子句。此时结果只会显示Empty Set，而不是我们所需要的结果。 　　建议二：Limit与Group By结合使用 　　Group By关键字主要用来对数据进行分类汇总。不过在分类汇总之前，往往需要对数据先进性排序。而Limit语句用来指定显示的结果数量时，往往也需要涉及到纪录的分类汇总与排序的问题。如现在一个学校成绩管理系统中，需要对学生的总分进行排序。即先对学生各科成绩进行汇总，然后显示其排名为前50的纪录。此时就需要同时用到Group By子句和Limit子句。其实从这个案例中我们也可以看出，这两个子句相互依赖的特性。正是因为这种特性(经常相互结合使用)，为此结合Group By子句可以提高Limit的查询效率。 　　这主要是因为两者如果一起使用的话，Limit关键字将不会再重复计算任何不必要的Group By的值。换句话说，在某些情况下，Group By子句能够通过顺序来读取键或者在键上做排序来解决分类汇总时的排序问题，然后再计算摘要直到关键字的值的改变为止。如此的话，两个子句所需要做的一些共同性的工作，只要做一次即可。这就可以从另外一次角度用来提高应用系统的性能。相比先做一个视图对数据进行分类汇总的运算，再使用一个查询语句来抽取特定数量的记录，效率就要高一点。因为后者是将两个子句分开来使用，就无法享受到结合使用所体现的优势。 　　建议三：使用SQL_calc_found_rows来提高子句的灵活性 　　默认情况下，Limit子句返回用户所指定的记录行数。只要数据库已经发送了用户所需要的行数，则数据库系统会放弃剩余的查询。即上面这个学生成绩的案例中，如果用户只需要返回总分成绩排名前50的学生，则数据库只返回50条记录，然后终止查询作业。 　　但是在某些特定的情况下，用户可能仍然需要继续后续的查询呢?如用户出了查询某些特定的记录，还需要知道总的记录数量，此时该如何处理?如现在用户需要知道排名前50的学生信息，同时需要知道总分在500分以上的总人数。此时单独使用Limit子句可能无法满足用户的需求，因为其只关心前面50条记录。如果要实现这个需求的话，往往需要结合SQL_calc_found_rows关键字。 　　这个关键字的主要用途就是能够在查询时为数据库管理员事先准备好符合Where条件语句的记录数目。然后用户只要在随后执行一条Select Found_ROWS语句之后，就可以获得符合条件的记录总数。不过需要注意的是，使用这个关键字会带来一定的副作用。即带有这个关键字的查询语句，是无法使用数据缓存的。故在某些情况下会降低数据查询的性能。故一般情况下，这个关键字只用于Where条件语句比较