查询性能优化
优化LIMIT分页
在系统中需要进行分页操作的时候，我们通常会使用LIMIT加上偏移量的办法实现，同时加上合适的ORDER BY子句。如果有对应的索引，通常效率会不错，否则，MySQL需要做大量的文件排序操作。一个非常常见又令人头疼的问题就是，在偏移量非常大的时候(翻页到非常靠后的页面)，例如可能是
LIMIT 10 000，20这样的查询，这时MySQL需要查询10020条记录然后只返回最后20条，前面的10 000条记录都将被抛弃，这样的代价非常高。如果所有的页面被访问的频率都相同，内马尔这样的查询平均访问半个表的数据。要优化这种查询，要么是在页面中限制分页的数量，要么是优化大偏移量的性能。优化此类分页查询的一个最简单的办法就是尽可能地使用索引覆盖扫描，而不是查询所有的列。然后根据需要做一次关联操作在返回所需的列。对于偏移量很大的时候，这样做的效率提升会非常大。考虑下面的查询:
sql
mysql> SELECT film_id, description FROM sakila.film ORDER BY title LIMIT 50,5;如果这个表非常大，那么这个查询最好改写成下面的样子:
sql
mysql> SELECT film.film_id,film.description
-> FROM sakila.film
-> INNER JOIN (
-> SELECT film_id FROM sakila.film
-> ORDER BY title LIMIT 50,5
-> ) AS lim USING(film_id);这里的"延迟关联"将大大提升查询效率，它让MySQL扫描尽可能少的页面，获取需要访问的记录后再根据关联列回原表查询需要的所有列。这个技术也可以用于优化关联查询中的LIMIT子句。有时候也可以将LIMIT查询转换为已知位置的查询，让MySQL通过范围扫描获得到对应的结果。例如，如果在一个位置列上有索引，并且预先计算了边界值，上面的查询就可以改写为:
sql
mysql> SELECT film_id,description FROM sakila.film WHERE position BETWEEN 50 AND 51 ORDER BY position;对数据进行排名的问题也与此类似，但往往还会同时和GROUP BY 混合使用。在这种情况下通常都需要预先计算并存储排名信息。LIMIT和OFFSET的问题，其实是OFFSET的问题，它回导致MySQL扫描大量不需要的行然后再抛弃掉。如果可以使用书签记录上次取数据的位置，那么下次就可以直接从该书签记录的位置开始扫描，这样就可以避免使用OFFSET.例如，若需要按照租借记录做翻页，那么可以根据最新一条租借记录向后追溯，这种做法可行是因为租借记录的主键是单调递增的。首先使用下面的查询获得第一组结果:
sql
mysql> SELECT * FROM sakila.rental ORDER BY rental_id DESC LIMIT 20;假设上面的查询返回的是主键为16 049到16 030的租借记录，那么下一页查询就可以从16 030这个点开始:
sql
mysql> SELECT * FROM sakila.rental WHERE rental_id < 16030 ORDER BY rental_id DESC LIMIT 20;该技术的好处是无论翻页到多么后面，其性能都会很好。其他优化办法还包括使用预先计算的汇总表，或者关联到一个冗余表，冗余表只包含主键列和需要做排序的数据列。还可以使用Sphinx优化一些搜索操作
优化SQL_CALC_FOUND_ROWS
分页的时候，另一个常用的技巧是在LIMIT语句中加上SQL_CALC_FOUND_ROWS提示(hint)，这样就可以获得去掉LIMIT以后满足条件的行数，因此可以作为分页的总数。看起来，MySQL做了一些非常"高深"的优化，像是通过某种方法预测了总行数。但实际上，MySQL只有在扫描了所有满足条件的行以后，才会知道行数，所以加上这个提示以后，不管是否需要，MySQL都会扫描所有满足条件的行，然后再抛弃掉不需要的行，而不是在满足LIMIT的行数后就会终止扫描。所以该提示的代价可能非常高。一个更好的设计是将具体的页数换成"下一页"按钮，假设每页显示20条记录，那么我们每次查询时都是用LIMIT返回21条记录并只显示20条，如果第21条存在，那么我们就显示"下一页"按钮，否则就说明没有更多的数据，也就无须显示"下一页"按钮了。另一种做法时先获取并缓存较多的数据------例如，缓存1 000条------然后每次分页都从这个缓存中获取。这样做可以让应用程序根据结果集的大小采取不同的策略，如果结果集少于1000，就可以在页面上显示所有的分页链接，因为数据都在缓存中，所以这样做性能不会有问题。如果结果集大于1 000，则可以在页面上设计一个额外的"找到的结果多于1 000条"之类的按钮。这两种策略都比每次生成全部结果集再抛弃掉不需要的数据的效率要高很多。有时候也可以考虑使用EXPLAIN的结果中的rows列的值来作为结果集总数的近似值(实际上Google的搜索结果总数也是个近似值)。当需要精确结果的时候，再单独使用COUNT(*)来满足需求，这时如果能够使用索引覆盖扫描则通常也会比SQL_CALC_FOUND_ROWS块得多
优化UNION查询
MySQL总是通过创建并填充临时表的方式来执行UNION查询。因此很多优化策略在UNION查询中都没法很好地使用。经常需要手工地将WHERE、LIMIT、ORDER BY等子句"下推"到UNION的各个子查询中，以便优化器可以充分利用这些条件进行优化(例如，直接将这些子句冗余地写一份到各个子查询)。除非确实需要服务器消除重复的行，否则就一定要使用UNION ALL，这一点很重要。如果没有ALL关键字，MySQL会给临时表加上DISTINCT选项，这回导致对整个临时表的数据做唯一性检查。这样做的代价非常高。即使有ALL关键字，MySQL仍然会用临时表存储结果。事实上，MySQL总是将结果放入临时表，然后再独处，再返回给客户端。虽然很多时候这样做是没有必要的(例如，MySQL可以直接把这些结果返回给客户端)
静态查询分析
Percona Toolkit中的pt-query-advisor能够解析查询日志、分析查询模式，然后给出所有可能存在潜在问题的查询，并给出足够详细的建议。这像是给MySQL所有的查询做一次全面的健康检查。它能检测出许多常见的问题
使用用户自定义变量。
用户自定义变量是一个容易被遗忘的MySQL特性，但是如果能够用好，发挥其潜力，再某些场景可以写出非常高效的查询语句。在查询中混合使用过程话和关系化逻辑的时候，自定义变量可能会非常有用。单纯的关系查询将所有的东西都当成无序的数据集合，并且一次性操作它们。MySQL则采用了更加程序化的处理方式。MySQL的这种方式有它的弱点，但如果能熟练地掌握，则会发现其强大之处，而用户自定义变量也可以给这种方式带来很大的帮助。用户自定义变量是一个用来存储内容的临时容器，在连接MySQL的整个过程中都存在，可以使用下面的SET和SELECT语句来定义它们
sql
mysql> SET @one :=1;
Query OK, 0 rows affected (18.96 sec)
mysql> SET @min_actor := (SELECT MIN(actor_id) FROM sakila.actor);
Query OK, 0 rows affected (0.02 sec)
mysql> SELECT @last_week := CURRENT_DATE - INTERVAL 1 WEEK;然后可以在任何可以使用表达式的地方使用这些自定义变量:
sql
mysql> SELECT ... WHERE col <= @last_week;在了解自定义变量的强大之前，我们再看看它自身的一些属性和限制，看可能在哪些场景下我们不能使用用户自定义变量:
- 1.使用自定义变量的查询，无法使用查询缓存
- 2.不能再使用常量或者标识符的地方使用自定义变量，例如表明、列明和LIMIT子句中
- 3.用户自定义变量的生命周期是在一个连接中有效，所以不能用它们来做连接间的通信
- 4.如果使用连接池或者持久化连接，自定义变量可能让看起来毫无关系的代码发生交互(如果是这样，通常是代码bug或者连接池bug，这类情况确实可能发生)
- 5.在5.0之前的版本，是大小写敏感的，所以要注意代码在不同MySQL版本间的兼容性问题
- 6.不能显式地声明自定义变量的类型。确定未定义变量的具体类型的时机在不同MySQL版本中也可能不一样。如果你希望变量是整数类型，那么最好在初始化的时候就赋值为0，如果希望是浮点型则赋值为0.0，如果希望是字符串则赋值为'',用户自定义变量的类型在赋值的时候会改变。MySQL的用户自定义变量是一个动态类型
- 7.MySQL优化器在某些场景下可能会将这些变量优化掉，这可能导致代码不按预想的方式运行
- 8.赋值的顺序和赋值的时间点并不总是固定的，这依赖于优化器的决定。实际情况可能很让人困惑
- 9.赋值符号:=的优先级非常低，所以需要注意，赋值赋值表达式应该使用明确的括号
- 10.使用未定义变量不会产生任何语法错误，如果没有意识到这一点，非常容易犯错