CREATETABLE`employees`(
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名',
`age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',
`position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位',
`hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间',
PRIMARY KEY (`id`),
KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE
)ENGINE=InnoDBAUTO_INCREMENT=1DEFAULTCHARSET=utf8COMMENT='员工记录表';
INSERTINTOemployees(name,age,position,hire_time)VALUES('LiLei',22,'manager',NOW());
INSERTINTOemployees(name,age,position,hire_time)VALUES('HanMeimei',23,'dev',NOW());
INSERTINTOemployees(name,age,position,hire_time)VALUES('Lucy',23,'dev',NOW());
Mysql如何选择合适的索引
mysql> EXPLAIN select * from employees where name > 'a';
如果用name索引需要遍历name字段联合索引树，然后还需要根据遍历出来的主键值去主键索引树里再去查出最终数据，成本比全表扫描 还高，可以用覆盖索引优化，这样只需要遍历name字段的联合索引树就能拿到所有结果，如下:
mysql> EXPLAIN select name,age,position from employees where name > 'a' ;
mysql> EXPLAIN select * from employees where name > 'zzz' ;
因为sql表中name>'zzz'的数据量非常少
对于上面这两种 name>'a' 和 name>'zzz' 的执行结果，mysql最终是否选择走索引或者一张表涉及多个索引，mysql最 终如何选择索引，我们可以用trace工具来一查究竟，开启trace工具会影响mysql性能，所以只能临时分析sql使用，用 完之后立即关闭
trace工具用法:
. mysql> set session optimizer_trace="enabled=on",end_markers_in_json=on; ‐‐开启trace
. 2 mysql> select * from employees where name > 'a' order by position;
. 3 mysql> SELECT * FROM information_schema.OPTIMIZER_TRACE;
4
5 查看trace字段: 6{7 "steps": [ 8{
. 9 "join_preparation": { ‐‐第一阶段:SQL准备阶段
. 10 "select#": 1,
. 11 "steps": [
. 12 {
. 13 "expanded_query": "/* select#1 */ select `employees`.`id` AS `id`,`employees`.`name` AS `name`,`emp
oyees`.`age` AS `age`,`employees`.`position` AS `position`,`employees`.`hire_time` AS `hire_time` from `employees` where (`employees`.`name` > 'a') order by `employees`.`position`"
. 14 }
. 15 ] /* steps */
. 16 } /* join_preparation */
l
. 17 },
. 18 {
. 19 "join_optimization": { ‐‐第二阶段:SQL优化阶段
. 20 "select#": 1,
. 21 "steps": [
. 22 {
. 23 "condition_processing": { ‐‐条件处理
. 24 "condition": "WHERE",
. 25 "original_condition": "(`employees`.`name` > 'a')",
. 26 "steps": [
. 27 {
. 28 "transformation": "equality_propagation",
. 29 "resulting_condition": "(`employees`.`name` > 'a')"
. 30 },
. 31 {
. 32 "transformation": "constant_propagation",
. 33 "resulting_condition": "(`employees`.`name` > 'a')"
. 34 },
. 35 {
. 36 "transformation": "trivial_condition_removal",
. 37 "resulting_condition": "(`employees`.`name` > 'a')"
. 38 }
. 39 ] /* steps */
. 40 } /* condition_processing */
. 41 },
. 42 {
. 43 "substitute_generated_columns": {
. 44 } /* substitute_generated_columns */
. 45 },
. 46 {
. 47 "table_dependencies": [ ‐‐表依赖详情
. 48 {
. 49 "table": "`employees`",
. 50 "row_may_be_null": false,
. 51 "map_bit": 0,
. 52 "depends_on_map_bits": [
. 53 ] /* depends_on_map_bits */
. 54 }
. 55 ] /* table_dependencies */
. 56 },
. 57 {
. 58 "ref_optimizer_key_uses": [
. 59 ] /* ref_optimizer_key_uses */
. 60 },
. 61 {
. 62 "rows_estimation": [ ‐‐预估表的访问成本
. 63 {
. 64 "table": "`employees`",
. 65 "range_analysis": {
. 66 "table_scan": { ‐‐全表扫描情况
. 67 "rows": 10123, ‐‐扫描行数
. 68 "cost": 2054.7 ‐‐查询成本
. 69 } /* table_scan */,
. 70 "potential_range_indexes": [ ‐‐查询可能使用的索引
. 71 {
. 72 "index": "PRIMARY", ‐‐主键索引
. 73 "usable": false,
. 74 "cause": "not_applicable"
. 75 },
. 76 {
. 77 "index": "idx_name_age_position", ‐‐辅助索引
. 78 "usable": true,
. 79 "key_parts": [
. 80 "name",
. 81 "age",
. 82 "position",
. 83 "id"
. 84 ] /* key_parts */
. 85 }
. 86 ] /* potential_range_indexes */,
. 87 "setup_range_conditions": [
. 88 ] /* setup_range_conditions */,
. 89 "group_index_range": {
. 90 "chosen": false,
. 91 "cause": "not_group_by_or_distinct"
. 92 } /* group_index_range */,
. 93 "analyzing_range_alternatives": { ‐‐分析各个索引使用成本
. 94 "range_scan_alternatives": [
. 95 {
. 96 "index": "idx_name_age_position",
. 97 "ranges": [
. 98 "a < name" ‐‐索引使用范围
. 99 ] /* ranges */,
. 100 "index_dives_for_eq_ranges": true,
. 101 "rowid_ordered": false, ‐‐使用该索引获取的记录是否按照主键排序
. 102 "using_mrr": false,
. 103 "index_only": false, ‐‐是否使用覆盖索引
. 104 "rows": 5061, ‐‐索引扫描行数
. 105 "cost": 6074.2, ‐‐索引使用成本
. 106 "chosen": false, ‐‐是否选择该索引
. 107 "cause": "cost"
. 108 }
. 109 ] /* range_scan_alternatives */,
. 110 "analyzing_roworder_intersect": {
. 111 "usable": false,
. 112 "cause": "too_few_roworder_scans"
. 113 }
. 114 }
. 115 }
. 116 }
. 117 ]
. 118 },
. 119 {
. 120 "considered_execution_plans": [
. 121 {
/* analyzing_roworder_intersect */
/* analyzing_range_alternatives */
/* range_analysis */
/* rows_estimation */
. 122 "plan_prefix": [
. 123 ] /* plan_prefix */,
. 124 "table": "`employees`",
. 125 "best_access_path": { ‐‐最优访问路径
. 126 "considered_access_paths": [ ‐‐最终选择的访问路径
. 127 {
. 128 "rows_to_scan": 10123,
. 129 "access_type": "scan", ‐‐访问类型:为scan，全表扫描
. 130 "resulting_rows": 10123,
. 131 "cost": 2052.6,
. 132 "chosen": true, ‐‐确定选择
. 133 "use_tmp_table": true
. 134 }
. 135 ] /* considered_access_paths */
. 136 } /* best_access_path */,
. 137 "condition_filtering_pct": 100,
. 138 "rows_for_plan": 10123,
. 139 "cost_for_plan": 2052.6,
. 140 "sort_cost": 10123,
. 141 "new_cost_for_plan": 12176,
. 142 "chosen": true
. 143 }
. 144 ] /* considered_execution_plans */
. 145 },
. 146 {
. 147 "attaching_conditions_to_tables": {
. 148 "original_condition": "(`employees`.`name` > 'a')",
. 149 "attached_conditions_computation": [
. 150 ] /* attached_conditions_computation */,
. 151 "attached_conditions_summary": [
. 152 {
. 153 "table": "`employees`",
. 154 "attached": "(`employees`.`name` > 'a')"
. 155 }
. 156 ] /* attached_conditions_summary */
. 157 } /* attaching_conditions_to_tables */
. 158 },
. 159 {
. 160 "clause_processing": {
. 161 "clause": "ORDER BY",
. 162 "original_clause": "`employees`.`position`",
. 163 "items": [
. 164 {
. 165 "item": "`employees`.`position`"
. 166 }
. 167 ] /* items */,
. 168 "resulting_clause_is_simple": true,
. 169 "resulting_clause": "`employees`.`position`"
. 170 } /* clause_processing */
. 171 },
. 172 {
. 173 "reconsidering_access_paths_for_index_ordering": {
. 174 "clause": "ORDER BY",
常见sql深入优化
Order by与Group by优化 Case1:
分析:
. 175 "steps": [
. 176 ] /* steps */,
. 177 "index_order_summary": {
. 178 "table": "`employees`",
. 179 "index_provides_order": false,
. 180 "order_direction": "undefined",
. 181 "index": "unknown",
. 182 "plan_changed": false
. 183 } /* index_order_summary */
. 184 } /* reconsidering_access_paths_for_index_ordering */
. 185 },
. 186 {
. 187 "refine_plan": [
. 188 {
. 189 "table": "`employees`"
. 190 }
. 191 ] /* refine_plan */
. 192 }
. 193 ] /* steps */
. 194 } /* join_optimization */
. 195 },
. 196 {
. 197 "join_execution": { ‐‐第三阶段:SQL执行阶段
. 198 "select#": 1,
. 199 "steps": [
. 200 ] /* steps */
. 201 } /* join_execution */
. 202 }
. 203 ] /* steps */
. 204 }
205206 结论:全表扫描的成本低于索引扫描，所以mysql最终选择全表扫描 207
. 208 mysql> select * from employees where name > 'zzz' order by position;
. 209 mysql> SELECT * FROM information_schema.OPTIMIZER_TRACE;
210211 查看trace字段可知索引扫描的成本低于全表扫描，所以mysql最终选择索引扫描 212213 mysql> set session optimizer_trace="enabled=off"; ‐‐关闭trace
常见sql深入优化
Order by与Group by优化
Case1:
利用最左前缀法则:中间字段不能断，因此查询用到了name索引，从key_len=74也能看出，age索引列用 在排序过程中，因为Extra字段里没有using filesort
Case 2:
分析: 从explain的执行结果来看:key_len=74，查询使用了name索引，由于用了position进行排序，跳过了 age，出现了Using filesort。
Case 3:
分析:
查找只用到索引name，age和position用于排序，无Using filesort。
Case 4:
分析:
和Case 3中explain的执行结果一样，但是出现了Using filesort，因为索引的创建顺序为 name,age,position，但是排序的时候age和position颠倒位置了。
Case 5:
分析:
与Case 4对比，在Extra中并未出现Using filesort，因为age为常量，在排序中被优化，所以索引未颠倒， 不会出现Using filesort。
Case 6:
分析:
虽然排序的字段列与索引顺序一样，且order by默认升序，这里position desc变成了降序，导致与索引的 排序方式不同，从而产生Using filesort。Mysql8以上版本有降序索引可以支持该种查询方式。
Case 7:
分析: 对于排序来说，多个相等条件也是范围查询
Case 8:
优化总结:
1、MySQL支持两种方式的排序filesort和index，Using index是指MySQL扫描索引本身完成排序。index
效率高，filesort效率低。
2、order by满足两种情况会使用Using index。
......order by语句使用索引最左前列。
.......使用where子句与order by子句条件列组合满足索引最左前列。
3、尽量在索引列上完成排序，遵循索引建立(索引创建的顺序)时的最左前缀法则。
4、如果order by的条件不在索引列上，就会产生Using filesort。
5、能用覆盖索引尽量用覆盖索引
6、group by与order by很类似，其实质是先排序后分组，遵照索引创建顺序的最左前缀法则。对于group by的优化如果不需要排序的可以加上order by null禁止排序。注意，where高于having，能写在where中 的限定条件就不要去having限定了。
Using filesort文件排序原理详解 filesort文件排序方式
单路排序:是一次性取出满足条件行的所有字段，然后在sort buffer中进行排序;用trace工具可 以看到sort_mode信息里显示< sort_key, additional_fields >或者< sort_key, packed_additional_fields >
双路排序(又叫回表排序模式):是首先根据相应的条件取出相应的排序字段和可以直接定位行 数据的行 ID，然后在 sort buffer 中进行排序，排序完后需要再次取回其它需要的字段;用trace工具 可以看到sort_mode信息里显示< sort_key, rowid >
MySQL 通过比较系统变量 max_length_for_sort_data(默认1024字节) 的大小和需要查询的字段总大小来 判断使用哪种排序模式。
如果 max_length_for_sort_data 比查询字段的总长度大，那么使用 单路排序模式; 如果 max_length_for_sort_data 比查询字段的总长度小，那么使用 双路排序模式。
我们先看单路排序的详细过程:
- 从索引name找到第一个满足 name = ‘zhuge’ 条件的主键 id 2. 根据主键 id 取出整行，取出所有字段的值，存入 sort_buffer 中 3. 从索引name找到下一个满足 name = ‘zhuge’ 条件的主键 id 4. 重复步骤 2、3 直到不满足 name = ‘zhuge’
- 对 sort_buffer 中的数据按照字段 position 进行排序
- 返回结果给客户端
我们再看下双路排序的详细过程: - 从索引 name 找到第一个满足 name = ‘zhuge’ 的主键id
- 根据主键 id 取出整行，把排序字段 position 和主键 id 这两个字段放到 sort buffer 中 3. 从索引 name 取下一个满足 name = ‘zhuge’ 记录的主键 id
- 重复 3、4 直到不满足 name = ‘zhuge’
- 对 sort_buffer 中的字段 position 和主键 id 按照字段 position 进行排序
- 遍历排序好的 id 和字段 position，按照 id 的值回到原表中取出 所有字段的值返回给客户端
其实对比两个排序模式，单路排序会把所有需要查询的字段都放到 sort buffer 中，而双路排序只会把主键 和需要排序的字段放到 sort buffer 中进行排序，然后再通过主键回到原表查询需要的字段。
如果 MySQL 排序内存配置的比较小并且没有条件继续增加了，可以适当把 max_length_for_sort_data 配 置小点，让优化器选择使用双路排序算法，可以在sort_buffer 中一次排序更多的行，只是需要再根据主键 回到原表取数据。
如果 MySQL 排序内存有条件可以配置比较大，可以适当增大 max_length_for_sort_data 的值，让优化器 优先选择全字段排序(单路排序)，把需要的字段放到 sort_buffer 中，这样排序后就会直接从内存里返回查 询结果了。
所以，MySQL通过 max_length_for_sort_data 这个参数来控制排序，在不同场景使用不同的排序模式， 从而提升排序效率。
注意，如果全部使用sort_buffer内存排序一般情况下效率会高于磁盘文件排序，但不能因为这个就随便增 大sort_buffer(默认1M)，mysql很多参数设置都是做过优化的，不要轻易调整。
