深入了解MySQL

转载于:http://www.cnblogs.com/RicCC/archive/2009/09/25/mysql.html

 

存储引擎


Attribute  MyISAM  Heap  BDB  InnoDB 
Transactions  No  No  Yes  Yes 
Lock granularity  Table  Table  Page (8 KB)  Row 
Storage  Split files  In-memory  Single file per table  Tablespace(s) 
Isolation levels  None  None  Read committed  All 
Portable format  Yes  N/A  No  Yes 
Referential integrity  No  No  No  Yes 
Primary key with data  No  No  Yes  Yes 
MySQL caches data records  No  Yes  Yes  Yes 
Availability  All versions  All versions  MySQL-Max  All Versions 

To make it easier to follow the unique characteristics of each storage engine, I created this magic quadrant diagram:

Below are some examples of using the best storage engine for different tasks:
Search Engine - NDBCluster
Web stats logging - Flat file for the logging with an offline processing demon processing and writing all stats into InnoDB tables.
Financial Transactions - InnoDB
Session data - MyISAM or NDBCluster
Localized calculations - HEAP
Dictionary - MyISAM

MyISAM
设计为处理读频率远大于写频率的情况,查询性能非常好;不支持事务,没有REDO、UNDO日志;支持表锁;
每个表使用独立的文件,索引和数据都存放在不同文件中,文件的存储以file block(页)的形式存储。只缓存索引,并不缓存实际数据,每次读取数据时要使用磁盘IO,索引在内存中以cache block形式组织,与file block对应。索引的缓存使用LRU算法管理,为了提高缓存的利用率,支持将缓存分成多个区域,例如分成Hot Area、Warm Area
key_buffer_size:设置缓存总大小
key_buffer_block_size:设置cache block大小
key_cache_division_limit:以百分比的形式将整个缓存区划分为多个区域。系统默认为100,即只有Warm Area
key_cache_age_threshold:控制各区域中的何时被降级,值越小,越容易降级到下一级area中
表的扫描分为Sequential Scan和Radom Scan 2种方式,read_buffer_size设置sequential scan时使用的缓存,read_rnd_buffer_size设置radom scan时使用的缓存
InnoDB
设计用于高并发读写情况,支持行锁(必须有索引支持);支持事务安全性,具有REDO、UNDO日志,具备故障恢复能力,其事务实现了SQL92的4个级别;支持外键,实现了数据库的引用完整性特性;
Adaptive Hash Index:InnoDB自动检测索引状况,如果发现可以通过hash index提高效率,会在内部创建一个基于B-Tree的hash index,并根据B-Tree索引的变化自动调整。hash index并不基于整个B-Tree创建,只针对其中的某部分;并不会存储到磁盘,仅创建在缓存区中
InnoDB的数据文件支持共享表空间和独享表空间2种模式,数据和索引存储在一起,支持数据和索引的缓存。存储结构从大到小依次为tablespace->segment->extent->Page,page默认为16KB,每个extent包含64个page,每个segment存放同一种数据,一般每个表存放于一个单独的segment中

锁机制
有表锁(MyISAM)、页锁(BDB)、行锁(InnoDB)三种

表锁:
有4个队列记录锁的使用情况:Current read-lock(当前读锁队列), Pending read-lock(等待读锁的队列), Current write-lock(当前写锁队列), Pending write-lock(等待写锁的队列)
读锁、写锁:
a). Current write-lock中当前资源的写锁会阻塞读锁和写锁请求.
b). Pending write-lock中WRITE类型的写锁会阻塞除了READ_HIGH_PRIORITY类型外的所有读锁请 求;READ_HIGH_PRIORITY类型的读锁比WRITE类型的写锁优先级高,因此它会阻塞Pending write-lock中所有的写锁请求;除了WRITE类型的写锁,Pending write-lock中其他类型的写锁优先级比读锁低(提高查询的响应时间)
c). Current write-lock中对资源的写锁类型为WRITE_ALLOW_WRITE时,允许除了WRITE_ONLY之外的所有读锁和写锁请求
MyISAM是MySQL官方开发的存储引擎,完全使用MySQL自己的表锁机制,其他几种支持事务的存储引擎都是让MySQL将锁处理交由存储引擎自行 实现,他们在MySQL中仅持有WRITE_ALLOW_WRITE类型的锁,至于锁的定义、并发冲突控制等都由各存储引擎处理
MyISAM表锁优化提示:MyISAM表锁读写互相阻塞,写锁优先级高于读锁
a). 参数选项low_priority_updates设置写锁优先级比读锁低,用于保证查询响应速度
b). 参数选项concurrent_insert配置是否使用并发插入特性,可以实现并发的读取和插入操作,配置值: 0:不允许并发插入; 1:数据文件中不存在空闲空间的时候可以在文件尾部进行并发插入; 2:不管数据文件是否存在空闲空间,均允许在文件尾部进行并发插入(插入操作将一直在文件尾部进行,中间的空闲空间无法利用,适用于删除操作很少的表)

InnoDB的行锁:
不是MySQL实现的锁机制,行锁都由其他存储引擎实现,这里以InnoDB为例(不同存储引擎实现机制也不一样)
Oracle的行锁是在物理块的事务槽中记录锁信息,而InnoDB是在索引键值的起始、结束位置上记录锁信息(间隙锁),所以InnoDB的行锁只是利用索引实现的一个范围锁,而利用索引可以定位到数据行
锁类型以及排他性:


   共享锁(S)  排他锁(X)  意向共享锁(IS)  意向排他锁(IX) 
共享锁(S)  兼容  冲突  兼容  冲突 
排他锁(X)  冲突  冲突  冲突  冲突 
意向共享锁(IS)  兼容  冲突  兼容  兼容 
意向排他锁(IX)  冲突  冲突  兼容  兼容 

InnoDB行锁潜在的问题:
a). 如果无法使用索引信息,InnoDB将使用表锁
b). 当索引不是确定到某一行数据时,InnoDB锁定的是索引匹配到的整个范围内的数据。例如使用索引定位到了10条记录,而加上非索引的条件可以准确确定到一条记录,这种情况下InnoDB仍然锁定这10条记录
事务隔离级别:
InnoDB实现了SQL92的4个隔离级别:Read UnCommited, Read Commited, Repeatable Read, Serializable
InnoDB有死锁检测机制,将发生死锁的2个事务中较小(修改数据量比较少)的那个作为死锁牺牲品。当然只限于InnoDB存储引擎范围之内,跨存储引擎的死锁只能通过死锁超时设置进行处理

索引
MySQL主要有4类索引:B-Tree索引、Hash索引、Fulltext索引、R-Tree索引

B-Tree索引: 通用索引类型
InnoDB中的B-Tree索引分为Cluster形式的Primary Key和Secondary Index,与SQL Server类似,Primary Key索引的叶节点是实际数据文件,按索引顺序排列,Secondary Index的叶节点只存储Primary Key值。MyISAM的主键索引和非主键索引没什么区别,与InnoDB的Secondary Index类似,只是其叶节点存放的不是PK值,而是直接定位到数据行的信息

Hash索引:
将数据的索引键值进行hash运算建立索引,查询匹配时将查询条件也做hash运算,比较hash值进行匹配。主要是Memory和NDB Cluster存储引擎使用
Hash索引的查询效率非常高,因为不需要像B-Tree一样从根匹配到页节点(《MySQL性能调优与架构设计》中说hash索引可以一次定位要查找的记录,这种说法可能存在问题,Hash索引的组织、hash值的匹配同样需要数据结构和算法的实现,不可能一次定位,设想hash索引以B-Tree方式组织,比B-Tree索引优秀的地方可能是其B-Tree数据量会小,即使这样也可能意味着hash冲突的存在,其效率比B-Tree索引高的说法是有待验证的,可能需要有不少前提条件)
缺点:只能进行等值匹配;hash索引是无序的,可能需要额外的排序操作;无法进行部分匹配,只能全索引匹配;遇到hash冲突后效率可能会比较低

Fulltext索引: 只有MyISAM的CHAR, VARCHAR, TEXT三种数据类型支持fulltext索引,主要用于优化效率比较低的like '%***%'操作
MySQL的fulltext中文支持有待考察,fulltext索引的创建成本比较高

R-Tree索引: 用于空间数据检索
MySQL有空间数据类型GEOMETRY(5.0.16之前只有MyISAM支持,之后BDB、InnoDB、NDB Cluster、Archieve等支持),只有MyISAM存储引擎支持R-Tree索引

查询优化器
Explain:在查询语句前加EXPLAIN查看查询计划,各操作解释参考《MySQL性能调优与架构设计》P131
Profiling:
a). set profiling=1; 开启Query Profiler
b). 执行查询
c). show profiles; 显示已记录的profile信息列表
d). show profile *** for query n; 例如show profile cpu, block io for query 6; 其中n为c)中的Query_ID

MySQL查询优化器在CBO(Cost Based Optimizer)增加了Heuristic Optimize(启发式优化),即增加了RBO(Rule Based Optimizer)功能,主要优化处理步骤与SQL Server有点相似

JOIN算法:只支持Nested Loop方式,有2种类型
a). simple nested-loop join (NLJ),假如有t1, t2, t3 3个表join,则算法为:


for each row in t1 matching range {
  for each row in t2 matching reference key {
    for each row in t3 {
      if row satisfies join conditions,
      send to client
    }
  }
}
即直接使用3个嵌套循环进行匹配
b). Block Nested-Loop Join (BNL),具体算法描述为:


for each row in t1 matching range {
  for each row in t2 matching reference key {
    store used columns from t1, t2 in join buffer
    if buffer is full {
      for each row in t3 {
        for each t1, t2 combination in join buffer {
          if row satisfies join conditions,
          send to client
        }
      }
      empty buffer
    }
  }
}

if buffer is not empty {
  for each row in t3 {
    for each t1, t2 combination in join buffer {
      if row satisfies join conditions,
      send to client
    }
  }
}
使用BNL的条件: 系统参数join_buffer_size有设置;MySQL的join类型为all(全表扫描)、index(全索引扫描)、range(索引区间扫描);进行join的记录能够放入join buffer中(记录太大无法放入join buffer无法使用BNL);内存满足join buffer分配
因为MySQL只有Nested Loop Join,如果内层表(被驱动表)没有索引或者无法使用索引等,就根本不适合使用Nested Loop,BNL主要用于处理这种情况。上面例子中如果t3没有索引,采用NLJ算法时在最内层每次都要对t3全表扫描,而使用BNL时,假如join_buffer_size可以存储100条中间结果,与NLJ相比每100次全表扫描t3可以减少为1次

ORDER BY算法:有2种,
a). 将排序字段和数据行定位信息读取到排序区(sort_buffer_size设定)中进行排序,完成排序后根据行定位信息从读取查询所需的列。缺点是有2次读取数据的操作
b). 将所需的列都读取到排序区进行排序,排序完后直接将结果返回。缺点是如果所需的列空间占用多,将消耗排序区空间影响排序性能
可以通过max_length_for_sort_data控制排序算法
另外一种对order by的处理是排序字段位于有序的索引中(例如不是hash索引等),索引本身是有序的因此不需要额外的排序操作

GROUP BY算法: 有3种,
a). 使用临时表。创建临时表,放入要group by的数据,按照group by的字段进行排序,生成group by结果集以及计算聚合函数的结果
b). Loose Index Scan
使用条件是针对单表的查询;group by的字段按照顺序前导匹配某个索引;索引必须是有序的;聚合函数只包含min、max,字段必须相同并且在索引中,并且是索引中紧跟着group by字段的下一个字段;索引字段中除了group by的字段外,其他字段如果出现在where条件中,where条件只能是常量值。MySQL 5.4.4加入了几个新的聚合函数:AVG(DISTINCT), SUM(DISTINCT), 和COUNT(DISTINCT),也是有限制性的
这种方式只需要部分扫描索引即可完成group by操作,如果where子句中只有group by字段的条件,则索引扫描的层级只需要到group by包含的字段(如果索引除了group by字段之外还包含其他字段,这种处理方式根本不需要扫描到索引页节点等层级)。正因为索引中包含的信息有限,因此该算法对聚合函数、索引的要求非常多,适用的场景比较窄,但是效率是最高的
例如表t1(c1,c2,c3,c4),有索引idx(c1,c2,c3),下面语句可以使用Loose Index Scan:


SELECT c1, c2 FROM t1 GROUP BY c1, c2;
SELECT c1, MIN(c2) FROM t1 GROUP BY c1;
SELECT c1, c2 FROM t1 WHERE c1 < const GROUP BY c1, c2;
SELECT MAX(c3), MIN(c3), c1, c2 FROM t1 WHERE c2 > const GROUP BY c1, c2;
SELECT c2 FROM t1 WHERE c1 < const GROUP BY c1, c2;
SELECT c1, c2 FROM t1 WHERE c3 = const GROUP BY c1, c2;
c). Tight Index Scan
其实就是利用有序索引的特性,避免创建临时表以及额外的排序操作,因此前提条件是能够利用有序索引;仅通过索引扫描可以完成查询
例如表t1(c1,c2,c3,c4),有索引idx(c1,c2,c3),下面2个语句都可以使用Tight Index Scan进行group by:


SELECT c1, c2, c3 FROM t1 WHERE c2 = 'a' GROUP BY c1, c3;
SELECT c1, c2, c3 FROM t1 WHERE c1 = 'a' GROUP BY c2, c3;

在EXPLAIN中,Extra中出现Using index for group-by表示使用Loose Index Scan实现;Using Temporary表示使用临时表实现;否则表示使用Tight Index Scan实现

SQL Server 7只有基本的group by算法,即先排序然后求group by结果集;SQL Server 2000引入了使用hash方法计算group by。而MySQL则是在这个基本算法基础上稍微拓展出了2种优化处理方法

DISTINCT算法:
distinct算法与group by基本相同,同样可以使用Loose Index Scan、Tight Index Scan、临时表实现,只是distinct只需要从group by结果中取出一条记录,不需要聚合运算等。算法的不同之处在于distinct算法本身并不要求排序操作(查询中包含group by、max聚合运算等其他操作可能要求排序)

你可能感兴趣的:(深入了解MySQL)