笔记来源这本书博主阅读后记录如下第一章 MySQL架构与历史1.1 MySQL逻辑架构1、连接管理与安全性服务器为每个连接的客户端单独分配一个线程该客户端的所有查询操作都在这个专属线程中执行保证了请求处理的隔离性多个线程会轮流在 CPU 核心上调度运行线程缓存服务器会预先创建并 “缓存” 一批线程即线程池当有新客户端连接时直接从线程池中拿一个线程处理完成后该线程不会被销毁而是放回线程池以后继续用避免了 每个新连接都创建 / 销毁线程的开销安全性当客户端连到MySQL服务器服务器对它进行认证基于用户名、原始主机信息和密码可以用SSL、X.509证书。连接成功后会接着验证该客户端是否具有执行某个特定查询的权限。2、优化与执行MySQL会解析查询并创建内部数据结构解析树进行各种优化比如选择合适索引等对于select语句解析查询前会先检查查询缓存找到就直接返回不用再执行查询解析、优化执行1.2 并发控制1、读写锁共享锁读锁可以多个同时读但是在已经有写锁的情况下不能读排他锁写锁会阻塞其他的写和读只有自己才能执行操作排他2、锁粒度表锁开销最小锁定整张表一个用户在写时需先获得写锁会阻塞其他用户的所有读写操作无写锁其他用户才能获得读锁读之间不阻塞​ 特定场景下表锁也有好的性能比如READ LOCAL表锁支持某些类型的并发写​ 写锁比读锁有更高的优先级所以写锁可以插入到读锁前面反之不行行级锁最大程度支持并发处理锁开销也大。行级锁只在存储引擎层实现MySQL服务层没有实现1.3 事务事务就是一组原子性的SQL查询事务内的语句要么全部执行要么全部失败ACID原子性 atomicity要么执行要么不执行不能只执行一部分。一个事务必须是不可分割的最小工作单元一致性 consistency数据必须符合业务要求比如转出200就必须另一个账户得到200隔离性 isolation并发执行时防止干扰持久性 durability一旦事务提交修改永久保存即使系统崩溃修改的数据也不会丢失**隔离级别未提交读 READ UNCOMMITTED允许读【未提交的数据】只禁止了脏写提交读 READ COMMITTED允许读【已提交数据】但存在-不可重复读两次相同查询但结果不一样可重复读 REPEATABLE READMySQL的默认事务隔离级别但不能解决脏读、幻行幻行时查询同一范围返回总行数/行内容不一致可串行化 SERIALIZABLE最高级别很少用。在读取的每一行都加锁强制所有事务都串行执行相当于单线程操作二、死锁多个事务在同一资源上相互占用并请求对方占有的资源产生恶性循环。相互等着对方释放锁又持有对方需要的锁死锁的产生原因真正的数据冲突、存储引擎的实现方式死锁发生后只有部分/完全回滚其中一个事务才能打破死锁InnoDB能检测到死锁的循环依赖并返回错误将持有最小行级排他锁的事务进行回滚三、事务日志和事务使用事务日志在修改表数据时只需要修改其内存拷贝然后再把该修改行为记录到事务日志中而不用每次都将修改同步到磁盘预写式日志修改表数据—记录到事务日志—最后批量刷入磁盘事务日志采用的是追加的方式所以写日志操作是磁盘上一小块区域内的顺序I/O不像随机I/O需要在磁盘多个地方移动磁头。事务日志持久化之后内存中被修改的内容会慢慢刷回到磁盘事务型存储引擎InnoDB、NDB Cluster1、自动提交。默认的每个查询都当做一个事务去执行也可以设置set AUTOCOMMIT来启用/禁用自动提交模式AUTOCOMMIT0不会自动提交只有commit才会提交。对于非事务型的表一直都是自动提交2、事务型的表支持回滚但是非事务型不支持回滚所以混合使用事务非事务的表可能会出错3、InnoDB用的是两阶段锁定协议事务执行时随时都可以锁定只有COMMIT/ROLLBACK才会释放锁所有的锁都是同一时刻释放1.4 多版本并发控制MVCC通过数据行的多版本管理实现并发控制避免了加锁开销更低MVCC通过保存数据在某个时间点的快照也就是不管需要执行多久每个事务看到的数据都是一致的InnoDB的MVCC工作过程通过在每行记录后保存两个隐藏列行创建时间、行过期时间删除时间存储的不是实际时间值而是系统版本号每开始一个新事务系统版本号都会自动递增MVCC只在REPEATABLE READ和READ COMMITTED隔离级别下工作1.5 MySQL的存储引擎存储引擎是表级别的概念每个表可以独立选择存储引擎比如表A可以选择InnoDB引擎支持事务、行锁表 B 可以用MyISAM引擎查询性能优但不支持事务1、InnoDB存储引擎InnoDB是MySQL的默认事务型引擎用MVCC支持高并发默认级别REPEATABLE READ通过间隙锁防止幻读InnoDB基于聚簇索引索引和数据放一起2、MyISAM存储引擎在MySQL5.1之前MyISAM是默认的存储引擎MyISAM提供了大量特性全文索引、压缩、空间函数但MyISAM不支持事务和行级锁而是对整张表加锁崩溃后无法安全恢复并发插入MyISAM在读取时对整个表加共享锁写入时加排他锁但是其他在读的时候也可以插入新数据MyISAM压缩表针对数据导入后不会再修改压缩表可以减少磁盘IO解压开销忽略不计1.6 选择合适的引擎除非需要用到InnoDB不具备的特性一般情况下都优先用InnoDB引擎应用不同存储引擎需考虑的因素事务需要事务支持用InnoDB不需要事务 且 主要是select、insert操作可以用MyISAM备份如果需要在线热备份选择InnoDB崩溃恢复MyISAM崩溃后损坏的概率比InnoDB高恢复速度也慢特有的特性比如地理空间搜索只有MyISAM支持1.7 转换表的引擎更改当前表的引擎最简单的方法是ALTER TABLE xx ENGINE InnoDB缺点是耗费时间长导入和导出使用mysqldump工具第四章 Schema与数据类型优化4.1 选择优化的数据类型①尽可能选择【可以正确存储数据的最小数据类型】原因更小的数据类型占用更少磁盘、内存、CPU缓存也更快②尽量避免包含NULL的列因为如果列里有NULL就会让索引、索引统计和值比较都变复杂更难优化一、整数类型TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT8 16 24 32 64 位存储空间UNSIGNED属性表示不允许负值二、实数类型FLOAT和DOUBLE类型支持使用标准的浮点运算进行近似计算DECIMAL存储精准的小数浮点类型在存储同样范围的值时通常比DECIMAL使用更少的空间MySQL使用DOUBLE作为内部浮点计算的类型三、字符串类型VARCHAR-----存可变长字符如果字符串列的最大长度比平均长度大使用varchar合适CHAR------定长如果经常变更、较短的数据char合适与VARCHAR、CHAR类似的还有BINARY、VARBINARY后面俩存的是二进制字符串BLOB和TEXT类型--------这俩为了存很大的数据字符串类型BLOB采用二进制方式存TEXT采用字符方式存使用枚举ENUM代替字符串把不重复的字符串存在一个预定义的集合如果枚举变量本身就是数字容易导致混乱因为MySQL把每个枚举值保存为整数必须进行查找才能转换成字符串枚举存数据实际为整数而不是原本字符串而且枚举字段是按照内部存储的整数而不是定义的字符串来排序的也可以使用FIELD函数显式指定排序顺序四、日期和时间DATETIME-----能保存大范围的值TIMESTAMP------只能表示1970-2038空间效率更高五、位数据类型SET------如果需要保持很多true false值可以合并到一个set数据类型缺点是如果要改变列的定义需要用ALTER TABLE这玩意代价高后面讲)4.2 MySQL schema设计中的陷阱MySQL 工作时服务器层和存储引擎层之间通过行缓冲格式拷贝数据。服务器层需要将缓冲中 “编码过的列” 解码转换成 “行数据结构”—— 这个转换操作的代价非常高且代价会随着列的数量增加而上升如果过多使用枚举比如ENUM国家A,B,C…如果 后续要增加国家就要用ALTER TABLE这是一种阻塞操作4.3 范式和反范式4.3.1 概念第一范式------字段拆到不能再拆第二范式-------消除部分函数依赖第三范式-------消除传递函数依赖4.3.2 范式化的优缺点优点更新操作比反范式化更快数据重复少表体积更小更容易存入内存数据冗余少检索时很少需要用 DISTINCT 或 GROUP BY比如部门单独成表直接查询即可无需去重分组**缺点**稍微复杂的查询语句都需要关联可能使索引无效代价高4.3.3 反范式化的优缺点优点数据集中在一张表能避免关联查询能更有效地执行缺点数据冗余多重复数据如果修改不彻底就会导致同信息在不同表有多版本4.3.4 混用范式 反范式最常见的反范式化数据的方法是复制/缓存在不同的表存相同的特定列4.4 缓存表和汇总表通过预存储高配查询结果减少重复计算 / IO开销提升查询性能举例对于实时计算统计量可以通过不严格计数、小范围查询填满间隙这俩者都比直接计算表全部行有效物化视图——预先计算并存储在磁盘上的表这样就用基于物化视图的查询来替换原来复杂的查询4.5 加快ALTER TABLE操作的速度ALTER TABLE慢的原因1、给原表加表级锁创建一个 新的临时表按新结构定义2、把旧表的所有数据写入临时表3、删除旧表将临时表重命名为原表名慢主要来自于加锁、重建表直接 ALTER TABLE锁表 → 建临时新表改结构 → 复制数据 → 删旧表 → 解锁影子表方案建影子表改结构 → 离线复制数据 → 原子切换 → 删旧表快速创建MyISAM索引先禁用索引偷偷把数据装好再重新启用索引。如果这个索引是唯一索引这个方法无效没办法快速创建唯一索引。唯一索引意思是不允许索引列重复那么每插入一行都需要去检查唯一性所以这个快速建索引的方法无效先disable keys 再 enable keys第五章 创建高性能的索引5.1 索引基础5.1.1 索引的类型索引是在存储引擎层面实现的不是所有存储引擎都支持所有类型索引1、B-Tree索引实际是B)InnoDB用的就是B Tree所有值都按顺序存储而且每一个叶子页到根的距离相同效率高的原因不再需要全表扫描获取需要的数据从根开始搜索适用场景全键值、范围查找、键前缀查找索引对多个值进行排序的依据create table中定义的索引顺序比如索引A,B,C)那么就按照先A再B再C排序**索引顺序很重要**B-Tree 联合索引的 “最左前缀限制”要求查询必须从索引的第一个列最左列开始匹配否则索引无法生效。这也是为什么设计联合索引时要把查询最频繁、区分度最高的列放在最左边的原因。2、哈希索引只有Memory引擎显式支持哈希索引哈希索引局限性①只包含哈希值、行指针不存字段值还是要去读取行②哈希索引不是按照索引值顺序存的不能用于排序③不支持缺索引列查找比如索引A,B) 如果缺B则用不了索引④不支持范围查找显然⑤出现哈希冲突只能遍历那个链表3、空间数据索引 R-TreeMyISAM支持空间索引可以用作地理数据存储4、全文索引查找文本关键词类似搜索引擎5.2 索引的优点1、减少了扫描的数据量2、避免排序和临时表比如BTree索引数据有序3、将随机I/O变成顺序I/O对于中大型表索引非常有效对于特大型可以用元数据信息表来代替索引5.3 高性能的索引策略5.3.1 独立的列比如select id from stu whereid 1 5索引列不能是表达式的一部分5.3.2 前缀索引和索引选择性索引的选择性越高查询效率越高因为在查找时可以过滤掉更多的行索引尽可能地覆盖全部数据唯一索引的性能是最好的对于字符类别的列必须用前缀索引不然一个个字符对比效率太低了,为了确定前缀的最合适长度需要找最常见的值的列表5.3.3 多列索引多列索引是将表中「多个字段组合起来创建的单个索引」一个索引管多个字段索引本身是个整体索引合并多个单列索引一起干活”每个索引都是独立的最后合并结果5.3.4 选择合适的索引列顺序将选择性最高的列放在索引最前面根据运行频率、筛选列数调整索引顺序举例A,B索引应该把A放前面还是B放前面呢?如果计数A有1w条数据但是计数B只有300条那么B放前面更合适因为可以筛掉大部分数据索引顺序很重要但where子句中的排序、分组、范围条件也很重要5.3.5 聚簇索引聚簇索引就是索引和数据存在一起**优点**访问数据更快使用覆盖索引扫描的查询可以直接使用页节点的主键值**缺点**更新代价高插入速度严重依赖于插入顺序可能面临表分裂为什么二级索引要两次索引查找因为二级索引存的是行主键值要拿着这个值去 聚簇索引 找对应的行InnoDBVSMyISAM对比InnoDB支持ACID原子性一致性隔离性持久性支持表级锁行级锁支持聚簇索引支持崩溃恢复redo log重做日志undo log回滚日志MyISAM只支持表级锁InnoDB数据和主键存一起聚簇索引—— 主键索引的叶子节点直接存储整行数据二级索引如 name 索引的叶子节点存储主键值。查询时如果查的是主键直接从索引取数据一次 IO如果不是主键就从二级索引的叶子拿到拿到主键再去聚簇索引拿值两次 IO。当然也有可能二级索引包含的内容正好能 满足要查的内容就不用回表去查聚簇索引了这就叫覆盖索引生效。MyISAM数据和索引单独存先拿索引再通过索引去找物理地址进而读数据.MYD 存数据.MYI 存索引在InnoDB中按主键顺序插入行如果表中没有什么数据需要聚集可以定义AUTO_INCREMENT自增列作为主键这样就保证数据行顺序写入最好不要用uuid或者随机聚簇索引自增列主键优缺点**优点**因为自增列主键是顺序的就算新增数据也是插入在末尾有序插入不会导致页分裂缺点每次都插入到索引最后并发插入可能会导致锁竞争5.3.6 覆盖索引**定义**如果一个查询的所有目标字段SELECT 列、WHERE 条件列等都能在 “二级索引的索引列 主键值” 中找到而不需要去聚簇索引中二次查询不需要回表优点避免回表操作如果一个查询的所有目标字段SELECT 列、WHERE 条件列等都能在 “二级索引的索引列 主键值” 中找到MySQL 就可以直接从这个二级索引中获取所有需要的数据无需再去聚簇索引主键索引中二次查询数据行例子假设表 user 有聚簇索引 (id, name, age)还有联合索引 idx_name_age (name, age)查询 SELECT name, age FROM user WHERE name‘张三’;因为 name 和 age 都在联合索引 idx_name_age 中MySQL 可以直接从这个索引中读取数据无需回表查聚簇索引 —— 这就是覆盖索引生效。覆盖索引失效的情况假设索引覆盖了 WHERE 条件中的字段但不是整个查询涉及的字段。比如查询是 SELECT name FROM user WHERE age20若有索引 idx_age (age)它覆盖了 WHERE 条件的 age但没覆盖查询字段 name—— 这时候索引没完全覆盖需要回表5.3.7 使用索引扫描来排序索引排序的前提1、排序字段在同一索引中联合索引需遵循字段顺序和最左前缀2、排序方向统一全 ASC / 全 DESC不混合3、不对排序字段做函数、运算、隐式转换4、有查询条件时条件需匹配联合索引左前缀补充用联合索引A,B,C排序的规则是1、order by 后面的字段需满足最左前缀原则如 A、A,B、A,B,C可直接利用索引排序2、若 order by 只有 B,C不满足完整最左前缀但 where 条件中把A 是等值常数也可以用索引排序如果A是范围也不能用索引排序索引比顺序扫描慢的情况索引不能覆盖全部的列必须回表扫描这种情况下索引比顺序慢5.3.8 压缩索引MyISAM压缩每个索引块的方法先保存索引块中第一个值然后将其他值与第一个值对比得到相同前缀的字节数和剩余的不同后缀部分把这部分存起来**局限**每个值的压缩前缀都依赖前面的值所以没办法用二分查找5.3.9 索引和锁索引可以让查询锁定更少的行因为索引筛掉了一些不需要的行进而锁定的行也更少。锁定超过需要的行会增加锁争用如果索引无法过滤掉无效的行就先获取where条件这可能导致锁住无用的行5.4 索引案例学习总结1、避免为每个查询组合都建独立索引如(sex, country, age)、(sex, country, region, age)而是通过 “IN 技巧” 复用索引2、若列涉及范围查询如age BETWEEN 18 AND 25要将其放在组合索引的最后面。原因是MySQL 对索引的 “最左前缀匹配” 会在遇到第一个范围列时停止把范围列放最后能让前面的列如sex、country尽可能被利用最大化索引的过滤效率3、避免多个范围查找对于范围条件查询范围列后面的索引列失效了5.5 维护索引和表目的找到并修复损坏的表、维护准确的索引统计信息、减少碎片CHECK TABLE可以检查是不是表损坏了REPAIR TABLE修复损坏的表但不是所有存储引擎都支持减少索引碎片行碎片数据行被拆成多个片段存储即便从索引查一行也会降低性能行间碎片逻辑顺序的页 / 行在磁盘上非顺序存储会影响全表扫描、聚簇索引扫描剩余空间碎片数据页里有大量空余空间导致服务器读取无用数据不同存储引擎碎片情况MyISAM 表三类碎片都可能出现InnoDB 表不会出现短小的行碎片会移动短行并重写到一个片段碎片的解决方法通用方法执行 OPTIMIZE TABLE或导出数据后重新导入MyISAM 额外方法通过排序算法重建索引InnoDB老版本无消除碎片方法新版本可利用在线删加索引功能先删索引再重建来消除碎片不支持 OPTIMIZE TABLE 的引擎执行 ALTER TABLE 操作将表的存储引擎改回当前引擎无实际操作来重建表。第六章 查询性能优化查询的生命周期大致可以按照顺序来看从客户端到服务器在服务器上解析完成执行计划执行返回结果优化查询的目的是减少和消除额外操作花费的时间6.1 慢查询基础优化数据访问6.1.1 是否向数据库请求了不需要的数据查询性能低下的最基本原因是------访问数据太多大多数查询都可以通过减少访问的数据量来优化一般通过以下分析①应用程序是否检索了大量超过需要的数据 ②服务器层是否分析大量超过需要的数据案例1、查询不需要的记录MySQL查询出全部结果集客户端接收后抛弃大多数最有效方法是在查询后加LIMIT2、多表关联时返回全部列3、总是获取全部列比如select *4、重复查询相同的数据6.1.2 MySQL是否在扫描额外的记录衡量查询开销的三个指标响应时间、扫描的行数、返回的行数响应时间服务时间排队时间服务时间——数据库处理这个查询真正花费的时间排队时间——服务器因为等待某些资源而没有真正执行查询的时间(比如等I/O、等锁)扫描的行数较短的行访问速度更快内存中行比磁盘中的行访问速度更快返回的行数理想情况下 扫描的行数返回的行数如果查询没有办法找到合适的访问类型可以增加合适的索引提高查找效率MySQL 应用 WHERE 条件的三种方式及其性能优劣排序不同方式对查询性能的影响存储引擎层的索引内过滤在MySQL 存储引擎层完成直接在索引结构中使用 WHERE 条件过滤不匹配的记录无需读取数据表的完整行数据。索引覆盖扫描在Extra 列显示 Using index。在MySQL 服务器层完成利用“索引覆盖”特性即查询所需的所有字段都包含在索引中无需回表查询数据表扫描后过滤在Extra 列显示 Using Where。在MySQL 服务器层完成需要先从数据表读出记录然后过滤越早在“索引层面”过滤数据查询性能越好若需扫描全表后再过滤性能则最差如果发现查询需要扫描大量数据但只返回少数行可以尝试使用索引覆盖扫描把所有需要的列都放到索引中改变库表结构6.2 重构查询的方式6.2.1 切分查询把大查询分成很多小查询比如删除旧数据如果用一个大语句直接一次性完成会一次锁住很多数据、占满整个事务日志但是如果切分成多个小查询则影响小6.2.2 分解关联查询把多表关联JOIN实现的查询拆分为多个单表查询分别执行后再在应用程序中整合结果好处让缓存效率更高减少锁竞争灵活性高应用层可根据业务逻辑按需查询、拼接数据查询本身效率也可能提升6.3 查询执行的基础在向MySQL发送一个请求后查询执行路径1、客户端发送一条查询给服务器2、服务器先检查缓存如果缓存有 且用户权限无问题则立刻返回缓存结果。否则进入下一阶段。3、服务器端进行 SOL解析、预处理再由优化器生成对应的执行计划。4、MySOL根据优化器生成的执行计划调用存储引擎的API来执行查询。5、将结果返回给客户端。6.3.1 MySQL客户端/服务器通信协议MySQL客户端和服务器之间的通信协议是“半双工”的要么是由服务器向客户端发送数据要么是由客户端向服务器发送数据这两个动作不能同时发生。这种协议的缺点是不能流量控制一旦客户端发完数据就得等待结果当服务器开始响应客户端请求时客户端必须完整接收整个返回结果。所以最好在查询中加上LIMIT限制一般情况下默认查询的全部结构缓存到内存中减少服务器压力同时查询也是默认先查缓存查询状态使用SHOW FULL PROCESSLIST① Sleep线程正在等待客户端发送新的请求② Query线程正在执行查询 / 正在将结果发送给客户端③ Locked在MySQL服务器层该线程正在等待表锁。在存储引擎级别实现的锁例如InnoDB的行锁并不会体现在线程状态中④ Analyzing and statistics线程正在收集存储引擎的统计信息并生成查询的执行计划。⑤ Copying to tmp table [on disk]线程正在执行查询并且将其结果集都复制到一个临时表中可能是在做GROUPBY操作、文件排序、UNION操作。如果后面还有“on disk”表示正在将一个内存临时表放到磁盘上⑥ Sorting result线程正在对结果集进行排序⑦ Sending data线程可能在多个状态之间传送数据 / 生成结果集 / 在客户端返回数据6.3.2 查询优化处理1、语法解析器和预处理MySQL通过关键字将SQL语句进行解析并生成对应解析树预处理器则根据一些MySQL规则进一步检查解析树是否合法例如检查数据表和数据列是否存在解析名字和别名是否有歧义2、查询优化器一条查询可以有多种执行方式最后都返回相同结果优化器的作用就是找到其中最好的执行计划。优化策略静态优化、动态优化静态优化直接对解析树分析并优化可以认为这是一种“编译时优化”。例如优化器可以通过一些简单的代数变换将 WHERE条件转换成另一种等价形式。静态优化第一次完成后就一直有效即使使用不同的参数重复执行查询也不会发生变化动态优化与查询的上下文有关也可能和很多其他因素有关运行时优化。例如WHERE条件中的取值、索引中条目对应的数据行数等。这需要在每次查询的时候都重新评估3、MySQL能处理的优化类型①重新定义关联表的顺序、②将外连接转化成内连接、③使用等价变换规则④优化COUNT、MIN、MAX比如要查B-Tree中最大值只需要读最后一条记录⑤预估并转化成常数表达式例子⑥覆盖索引扫描当索引中的列包含所有查询中需要使用的列的时候使用索引返回需要的数据而无须查询对应的数据行⑦子查询优化将子查询转换一种效率更高的形式从而减少多个查询多次对数据进行访问⑧提前终止查询在发现已经满足查询需求的时候MySQL总是能够立刻终止查询比如使用了LIMIT 子句、发现了一个不成立的条件等⑨等值传播。比如使用某个字段等值关联那么一个列的where条件就能传递到另一个列上⑩列表IN的比较。比如MySQL把IN列表中的数据先排序通过二分查找的方式确定列表中的值是否满足条件4、MySQL如何执行关联查询MySQL对任何关联都执行嵌套循环关联操作——先在一个表中循环取出单条数据然后再嵌套循环到下一个表中寻找匹配的行依次下去直到找到所有表中匹配的行为止。然后根据各个表匹配的行返回查询中需要的各个列。MySQL会尝试在最后一个关联表中找到所有匹配的行如果找不到则返回到上一层次关联表再依此类推MySQL总是从一个表开始一直嵌套循环、回溯完成所有表关联执行计划如上一颗左侧深度优先的树5、排序优化当MySQL不能使用索引排序时MySQL需要自己进行排序如果数据量小→在内存中进行如果数据量大→需要使用磁盘 MySQL将这个排序过程都称为文件排序(filesort)如果需要排序的数据量 排序缓冲区MySQL使用内存进行快排。如果内存不够排序那么会把数据分块对每个独立的块使用快排最后合并各个块MySQL有如下两种排序算法:①两次传输排序(旧版本使用)读取行指针和需要排序的字段对其进行排序然后再根据排序结果读取所需要的数据行。这里读了两次成本高②单次传输排序(新版本使用)先读取查询所需要的所有列排序直接返回在关联查询的时候如果需要排序MySQL会分两种情况来处理这样的文件排序如果ORDERBY子句中的所有列都来自关联的第一个表那么在关联处理第一个表的时候就进行文件排序 EXPLAIN结果中Extra字段有“Using filesort”。除此之外的所有情况MySQL都会先将关联的结果存放到一个临时表中等所有关联结束后再排序。EXPLAIN结果的 Extra字段有“Using temporary; Using filesort”。如果查询中有LIMIT的话LIMIT也会在排序之后应用6.3.3 查询执行引擎在解析和优化阶段MySQL将生成查询对应的执行计划查询执行引擎则根据这个执行计划来完成整个查询。这里执行计划是一个数据结构在根据执行计划逐步执行的过程中有大量的操作需要通过调用存储引擎实现的接口来完成称为“handler API”的接口。查询中的每一个表由一个 handler的实例表示。实际上MySQL在优化阶段就为每个表创建了一个handler实例优化器根据这些实例的接口可以获取表的相关信息包括表的所有列名、索引统计信息等等