Mysql DOC阅读笔记

Mysql DOC阅读笔记

转自我的Github

Speed of SELECT Statements

1. 合理利用索引
2. 隔离调试查询中花费高的部分，例如函数调用是在结果集中的行执行还是全表中的行执行
3. 最小化全表扫描的数量，特别是在大表中
4. 定期使用ANALYZE TABLE语句更新表的统计数据，使查询优化器可以做出更合理的优化。
5. 学习各个存储引擎的特殊调试，索引和配置
6. 优化单条只读查询事务
7. 避免使用难以理解的方式编写QUERY,因为查询优化器可能使用的还是同样的优化决策,不要牺牲SQL的可读性
8. 如果性能问题不能通过基本的GUIDELINES解决，那么使用EXPLAIN语句查看更具体的信息
9. 调整MySQL所使用到的用作缓存的内存区域，例如(InnoDB buffer pool, MyISAM key cache, MySQL query cache)
10. 小心处理锁的问题

EXPLAIN Statement

结果字段

• id : SELECT的标识符
• select_type : SELECT的类型
  • SIMPLE : Simple SELECT (not using UNION or subqueries)
  • PRIMARY : Outermost SELECT
  • UNION : Second or later SELECT statement in a UNION
  • DEPENDENT UNION : Second or later SELECT statement in a UNION, dependent on outer query
  • UNION RESULT RESULT of a UNION
  • SUBQUERY First SELECT in subquery
  • DEPENDENT SUBQUERY First SELECT in subquery, dependent on outer query.
  • DERIVED Derived table SELECT (subquery in FROM clause)
  • MATERIALIZED Materialized subquery
  • UNCACHEABLE SUBQUERY A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query
• table : The name of the table to which the row of output refers
  • <unionM,N> M,N为子查询的id
  • <deriveN> N为子查询的id
  • <subqueryN> N为子查询的id
• partitions : 使用的分区
• type : JOIN TYPE
• possible_keys : 可选的索引
• key : 查询用到的key或者index
• key_len : The key_len column indicates the length of the key that MySQL decided to use. The length is NULL if the key column says NULL. Note that the value of key_len enables you to determine how many parts of a multiple-part key MySQL actually uses
• ref : The ref column shows which columns or constants are compared to the index named in the key column to select rows from the table.
• rows : The rows column indicates the number of rows MySQL believes it must examine to execute the query
• filtered : The filtered column indicates an estimated percentage of table rows that will be filtered by the table condition. That is, rows shows the estimated number of rows examined and rows × filtered / 100 shows the number of rows that will be joined with previous tables.
• Extra : This column contains additional information about how MySQL resolves the query. See Explain Extra Information

MySQL Index

1. 多列索引，查询条件需要按照列的顺序并且起始列为索引的起始列，中间不能有间隔
2. 使用MIN()或者MAX()查询的时候多列索引的使用也遵循最左列的原则，即WHERE中要先使用多列索引中的最左列，那么查询优化器会将MIN()和MAX()做一个key上的扫描，然后将常数的结果进行替换。例如: SELECT MIN(key_part2),MAX(key_part2) FROM tbl_name WHERE key_part1=10;
3. LIKE也能使用索引，只要参数是常量，并且不以通配符开头
4. 在不通列的对比中如果要使用索引，需要两个列的数据类型一样，CHAR(10)和VARCHAR(10)被认为是一样的。
5. 多列索引的实现: A multiple-column index can be considered a sorted array, the rows of which contain values that are created by concatenating the values of the indexed columns.
6. 多列索引详情见Multiple Index
7. Mysql对Where的优化详情见Where Optimization
8. InnoDB的聚簇索引含有列数据，优先建立组合索引而不是每一列的单独索引。InnoDB的二级索引的叶子节点中存储的是PK，而不是行号。MyISAM的索引是非聚簇索引，叶子节点中是行指针。See more
9. 在where条件中查询条件对索引使用的影响:

Any index that does not span all AND levels in the WHERE clause is not used to optimize the query. In other words, to be able to use an index, a prefix of the index must be used in every AND group. The following WHERE clauses use indexes:

... WHERE index_part1=1 AND index_part2=2 AND other_column=3

   /* index = 1 OR index = 2 */
... WHERE index=1 OR A=10 AND index=2

   /* optimized like "index_part1=‘hello‘" */
... WHERE index_part1=‘hello‘ AND index_part3=5

   /* Can use index on index1 but not on index2 or index3 */
... WHERE index1=1 AND index2=2 OR index1=3 AND index3=3;

These WHERE clauses do not use indexes:

   /* index_part1 is not used */
... WHERE index_part2=1 AND index_part3=2

   /*  Index is not used in both parts of the WHERE clause  */
... WHERE index=1 OR A=10

   /* No index spans all rows  */
... WHERE index_part1=1 OR index_part2=10

buffer pool

buffer pool 是Mysql中用来存放InnoDB的表和索引数据的内存区域， 这些内存区域被划分成页。buffer pool使用使用linked list作为pages的实现。页的交换使用LRU算法，在大内存的系统中，你可以将buffer pool划分成多个buffer pool instances。 innodb_buffer_pool_size中配置的内存大小被所有buffer pool实例所分割，多buffer pool实例更适给Innodb buffer pool划分几个G以上空间的应用，每一个实例都可以得到一个1G或者以上大小的空间。

Read-Only Transactions

如果InnoDB可以提前知道一个事务是只读事务，那么它就可以避免使用transaction ID(TRX_ID)。Transaction ID只需要在语句存在更新或者读语句中存在锁的情况中使用。 InnoDB是这样检测只读事务的:

1. 事务以START TRANSACTION READ ONLY语句开始，但是这种情况仍可以对session-specific临时表进行更新，因为对这些表进行更新不影响其他事务。
2. autocommit标志位打开的情况下，所有事务都是一条但语句，那么没有更新的语句将会被包装成只读事务。
3. 事务没有用READ ONLY选项，但是还没有更新语句或者明确的锁语句，这时候事务是一个只读事务，知道遇到了一个明确的锁或者更新语句。 所以，对于查询语句可以将它们放在一个READ ONLY事务中，或者在执行select语句之前打开autocommit选项，或者只是简单的不要吧DML放在DQL中间。

Other

innodb行锁的实现方式

对于innodb的表而言，insert、update、delete等操作虽然都是加行级锁，但这些行锁都是通过给索引上的索引项加锁来实现的，这就意味着：只有通过索引条件检索数据，innodb才能使用行级锁，否则，innodb将使用表级锁。 * 在不通过索引条件检索的时候，innodb使用的是表锁，不是行锁。 例如：

create table tab_no_index(id int,name varchar(10)) engion=innodb; create table tab_with_index(id int,name varchar(10),key id_idx(id)) engion=innodb; 语句select * from tab_no_index where id=1 for update;会加表锁，而select * from tab_with_index where id=1 for update;会加行锁。

• 虽然访问不同行的记录，但是如果是使用相同的索引键，仍然会出现锁冲突。 例如，上例表tab_with_index中有两条记录为(1,’1’)和(1,’4’)，则select * from tab_with_index where id=1 and name=’1’ for update;会对这两条记录都加锁。
• 当表有多个索引时，不同的事务可以使用不同的索引锁定不同的行。此外，不论是使用主键索引、唯一索引或普通索引，innodb都会使用行锁对数据加锁。

innodb的间隙锁（Next-key锁）

当使用范围条件而不是相等条件检索数据，并请求共享或排他锁时，innodb会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不 存在的记录，叫做“间隙”，innodb也会对这个“间隙”加锁。例如，emp表中只有101条记录，其中empid为索引键，值分别为 1,2,……,100,101，语句select * from emp where empid>100 for update;不仅会对101记录加锁，还会对empid大于101（这些记录不存在）的“间隙”加锁。