8.2.1 Optimizing SELECT Statements
8.2.2 Optimizing DML Statements
8.2.3 Optimizing Database Privileges
8.2.4 Optimizing INFORMATION_SCHEMA Queries
8.2.5 Other Optimization Tips
The core logic of a database application is performed through SQL statements, whether issued directly through an interpreter or submitted behind the scenes through an API.
The tuning guidelines in this section help to speed up all kinds of MySQL applications. The guidelines cover SQL operations that read and write data,
the behind-the-scenes overhead for SQL operations in general, and operations used in specific scenarios such as database monitoring.
数据库逻辑应用的核心是通过执行SQL语句,通过API直接通过翻译或提交。
8.2.1 Optimizing SELECT Statements 优化查询语句
查询, 以SELECT 语句的形式,在数据库里执行所有的查询操作。调优这些语句是同等大事,不管是实现集中响应对于动态网页,
或者是要花费数小时来产生巨大的隔夜报告。
除了SELECT 语句, 调优技术用于查询也应用去构建如CREATE TABLE … AS SELECT ,和WHERE 语句在DELETE 语句里,
这些语句有额外的性能考虑因为它们把鞋操作和读操作结合起来。
8.2.1.1 Speed of SELECT Statements
优化查询的主要考虑因素是：
让一个慢的SELECT .. WHERE 查询更快,首先检查是否可以添加索引,在where 条件列上使用索引,用来加快执行,过滤和最终的检索结果。
为了避免浪费磁盘中间,构建一个小索引,加快很多相关的查询。
隔离和优化查询的部分,例如函数调用,这需要花费过多的时间。依赖查询的结构, 对结果集的每一行返回,函数都会被调用一次,甚至是一个表中的每一行,打打的放大低效率。
在你的查询中,最大限度地櫇ХБ全表扫描的次数,特别是对于大表。
保持表的统计信息通过定期的使用ANALYZE TABLE 语句,因此优化器需要统计信息来构造高效的执行计划。
学习调优技术,索引技术,和配置参数 为每个表指定存储引擎。 InnoDB 和 MyISAM都有设置向导来支持高性能的查询。
特别是, 在MySQL 5.6.4 或者更高的版本, 对于InnoDB可以优化单个查询事务.
避免查询转化,让它难以理解的方式,特别是优化器会自动进行一些等价的转换。
如果一个性能问题是不容易被解决通过基本准则,调查指定查询通过读取EXPLAIN plan 和调整索引,
where 语句, join 语句 ，等等。（当你达到某个专业的程度,读取执行计划可能是你的第一步)
调整 MySQL 使用的内存区域的大小和属性。 随着InnoDB buffer pool的有效使用,
MyISAM key cache，和MySQL query cache，重复的查询会运行更加,因为结果是从内存获取。
对于一个查询使用cache memory areas 会run fast，你仍旧可以进一步优化, 以使它们不需要更少的cache memory，
从而使应用程序更具有可伸缩性。伸缩性意味着你的应用能处理更多的并发用户, 更大的请求.
处理锁定问题,你查询的速度可能被其他会话同时访问表
8.2.1.2 How MySQL Optimizes WHERE Clauses MySQL 优化 WHERE 语句:
本节讨论用于处理where 子句的优化, 例子使用SELECT 语句, 但同样的优化应用于DELETE 和UPDATE 语句:
注意:
因为在Mysql 优化进行时,并不是所有的优化，MySQL的执行都记录在这里。
你试图重写你的查询让操作更快, 在牺牲可读性。因为MySQL是类似的自动优化，你通常可以避开这项工作，并把查询更容易理解和维护的形式。一些优化由MySQL遵循：
去除不需要的括号:
((a AND b) AND c OR (((a AND b) AND (c AND d))))
-> (a AND b AND c) OR (a AND b AND c AND d)
常量表达式被用于索引 只求值一次:
count(*) 在一个单独的表上没有WHERE 条件被直接检索 从表中对于MyISAM和Memory 表,
这个也用于 任何的NOT NULL 表达式
无效的常量表达式早期检测, MySQL 快速的检测一些SELECT 语句是不可能的,返回0条记录。
HAVING 是和WHERE 合并的,如果没有使用GROUP BY 或者聚合函数
对于每个表的连接,简单的WHERE 被构建来得到一个快速的WHERE 评估 ,尽快跳过行
所有常量表被首选读取在任何其他表在一个查询里,常量表时下面几种:
1.一个空表或者表只有一条记录
- 一个表用于和WHERE语句 在一个主键或者UNIQUE INDEX上,所有的索引部分被当作常量表达式,被定义为NOT NULL。
下面所有的表格都用作常量表:
SELECT * FROM t WHERE primary_key=1;
SELECT * FROM t1,t2
WHERE t1.primary_key=1 AND t2.primary_key=t1.id;
最好的关联组合用于管理表时通过尝试所有的可能, 如果所有的列在ORDER BY 或者GROUP BY 子句,
来自同样的表, 该表是首先关联。
如果有ORDER BY 子句,和一个不同的GROUP BY 子句或者 如果ORDER BY 或者GROUP BY 包含
从一个列从表相比第一个表在join队列,则创建临时表。
如果你使用SQL_SMALL_RESULT选项, MySQL 使用一个内存中的临时表
每个表索引是需要的,并使用最佳索引,除非优化器认为它是更加适合使用全表扫描。
在同一时间,一个scan 被使用基于是否索引访问超过表30%的数据,但是一个固定的百分比不能决定使用索引和全表扫描。
现在的优化器是更加复杂的,它预估额外的因素table size, number of rows, and I/O block size.
在一些情况下, MySQL 可以从index读取数据 不需要访问相关的数据文件,如果所有使用的列都包含在索引 ,只需要访问索引就可以解决查询
在每行输出之前, 不匹配HAVING 语句被跳过:
Some examples of queries that are very fast:
SELECT COUNT(*) FROM tbl_name;
SELECT MIN(key_part1),MAX(key_part1) FROM tbl_name;
SELECT MAX(key_part2) FROM tbl_name
WHERE key_part1=constant;
SELECT … FROM tbl_name
ORDER BY key_part1,key_part2,… LIMIT 10;
SELECT … FROM tbl_name
ORDER BY key_part1 DESC, key_part2 DESC, … LIMIT 10;
MySQL resolves the following queries using only the index tree, assuming that the indexed columns are numeric:
SELECT key_part1,key_part2 FROM tbl_name WHERE key_part1=val;
SELECT COUNT(*) FROM tbl_name
WHERE key_part1=val1 AND key_part2=val2;
SELECT key_part2 FROM tbl_name GROUP BY key_part1;
The following queries use indexing to retrieve the rows in sorted order without a separate sorting pass:
SELECT … FROM tbl_name
ORDER BY key_part1,key_part2,… ;
SELECT … FROM tbl_name
ORDER BY key_part1 DESC, key_part2 DESC, … ;