性能调优03-Mysql索引优化实战

Mysql如何选择合适的索引

CREATE TABLE `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 = INNODB AUTO_INCREMENT = 4 DEFAULT CHARSET = utf8 COMMENT = '员工记录表';

INSERT INTO employees ( NAME, age, position, hire_time )
VALUES
	( 'LiLei', 22, 'mana ger', NOW( ) ),
	( 'HanMeimei', 23, 'dev', NOW( ) ),
	( 'Lucy', 23, 'dev', NOW( ) );

mysql> EXPLAIN select * from employees where name > ‘a’;

如果用name索引需要遍历name字段联合索引树，然后还需要根据遍历出来的主键值去主键索引树里再去查出最终数据，成本比全表扫描还高，可以用覆盖索引优化，这样只需要遍历name字段的联合索引树就能拿到所有结果，如下：

还高，可以用覆盖索引优化，这样只需要遍历name字段的联合索引树就能拿到所有结果，如下：

mysql> EXPLAIN select name,age,position from employees where name > ‘a’ ;

mysql> EXPLAIN select * from employees where name > ‘zzz’ ;

select * from employees where name > ‘a’;
select * from employees where name > ‘zzz’；

对于上面这两种 name>’a’ 和 name>’zzz’ 的执行结果，mysql最终是否选择走索引或者一张表涉及多个索引，mysql最终如何选择索引，我们可以用trace工具来一查究竟，开启trace工具会影响mysql性能，所以只能临时分析sql使用，用完之后立即关闭

trace工具用法

set session optimizer_trace="enabled=on",end_markers_in_json=on; -- 开启trace
select * from employees where name > 'a' order by position; 
SELECT * FROM information_schema.OPTIMIZER_TRACE;
-- 结论：全表扫描的成本低于索引扫描，所以mysql最终选择全表扫描 
查看trace字段：
{
  "steps": [
    {
      "join_preparation": {  -- 第一阶段：SQL准备阶段 10
        "select#": 1,
        "steps": [
          {
            "expanded_query": "/* select#1 */ select `employees`.`id` AS `id`,`employees`.`name` AS `name`,`employees`.`age` AS `age`,`employees`.`position` AS `position`,`employees`.`hire_time` AS `hire_time` from `employees` where (`employees`.`name` > 'a') order by `employees`.`position`"
          }
        ] /* steps */
      } /* join_preparation */
    },
    {
      "join_optimization": {  -- 第二阶段：SQL优化阶段
        "select#": 1,
        "steps": [
          {
            "condition_processing": { -- 条件处理
              "condition": "WHERE",
              "original_condition": "(`employees`.`name` > 'a')",
              "steps": [
                {
                  "transformation": "equality_propagation",
                  "resulting_condition": "(`employees`.`name` > 'a')"
                },
                {
                  "transformation": "constant_propagation",
                  "resulting_condition": "(`employees`.`name` > 'a')"
                },
                {
                  "transformation": "trivial_condition_removal",
                  "resulting_condition": "(`employees`.`name` > 'a')"
                }
              ] /* steps */
            } /* condition_processing */
          },
          {
            "substitute_generated_columns": {
            } /* substitute_generated_columns */
          },
          {
            "table_dependencies": [ -- 表依赖详情
              {
                "table": "`employees`",
                "row_may_be_null": false,
                "map_bit": 0,
                "depends_on_map_bits": [
                ] /* depends_on_map_bits */
              }
            ] /* table_dependencies */
          },
          {
            "ref_optimizer_key_uses": [
            ] /* ref_optimizer_key_uses */
          },
          {
            "rows_estimation": [ -- 预估表的访问成本
              {
                "table": "`employees`",
                "range_analysis": {
                  "table_scan": { -- 全表扫描情况
                    "rows": 3, -- 扫描行数
                    "cost": 3.7 -- 查询成本(相对值，同一个trace内部比较才有意义)
                  } /* table_scan */,
                  "potential_range_indexes": [ -- 查询可能使用的索引
                    {
                      "index": "PRIMARY", -- 主键索引
                      "usable": false, -- 不采用
                      "cause": "not_applicable"
                    },
                    {
                      "index": "idx_name_age_position", -- 其他辅助索引
                      "usable": true, -- 采用
                      "key_parts": [
                        "name",
                        "age",
                        "position",
                        "id"
                      ] /* key_parts */
                    },
                    {
                      "index": "idx_age",
                      "usable": false,
                      "cause": "not_applicable"
                    }
                  ] /* potential_range_indexes */, 
                  "setup_range_conditions": [
                  ] /* setup_range_conditions */,
                  "group_index_range": {
                    "chosen": false,
                    "cause": "not_group_by_or_distinct"
                  } /* group_index_range */,
                  "analyzing_range_alternatives": { -- 分析各个索引使用成本
                    "range_scan_alternatives": [
                      {
                        "index": "idx_name_age_position",
                        "ranges": [
                          "a < name"
                        ] /* ranges */,
                        "index_dives_for_eq_ranges": true,
                        "rowid_ordered": false, -- 使用该索引获取的记录是否按照主键排序
                        "using_mrr": false,
                        "index_only": false, -- 是否使用覆盖索引
                        "rows": 3, -- 索引扫描行数
                        "cost": 4.61,-- 索引使用成本
                        "chosen": false, -- 是否选择该索引
                        "cause": "cost" -- 原因：耗时成本
                      }
                    ] /* range_scan_alternatives */,
                    "analyzing_roworder_intersect": {
                      "usable": false,
                      "cause": "too_few_roworder_scans"
                    } /* analyzing_roworder_intersect */
                  } /* analyzing_range_alternatives */
                } /* range_analysis */
              }
            ] /* rows_estimation */
          },
          {
            "considered_execution_plans": [
              {
                "plan_prefix": [
                ] /* plan_prefix */,
                "table": "`employees`",
                "best_access_path": { -- 最优访问路径
                  "considered_access_paths": [ -- 最终选择的访问路径 
                    {
                      "rows_to_scan": 3, -- 访问类型：为scan，全表扫描
                      "access_type": "scan",
                      "resulting_rows": 3,
                      "cost": 1.6,
                      "chosen": true,  -- 确定选择
                      "use_tmp_table": true
                    }
                  ] /* considered_access_paths */
                } /* best_access_path */,
                "condition_filtering_pct": 100,
                "rows_for_plan": 3,
                "cost_for_plan": 1.6,
                "sort_cost": 3,
                "new_cost_for_plan": 4.6,
                "chosen": true
              }
            ] /* considered_execution_plans */
          },
          {
            "attaching_conditions_to_tables": {
              "original_condition": "(`employees`.`name` > 'a')",
              "attached_conditions_computation": [
              ] /* attached_conditions_computation */,
              "attached_conditions_summary": [
                {
                  "table": "`employees`",
                  "attached": "(`employees`.`name` > 'a')"
                }
              ] /* attached_conditions_summary */
            } /* attaching_conditions_to_tables */
          },
          {
            "clause_processing": {
              "clause": "ORDER BY",
              "original_clause": "`employees`.`position`",
              "items": [
                {
                  "item": "`employees`.`position`"
                }
              ] /* items */,
              "resulting_clause_is_simple": true,
              "resulting_clause": "`employees`.`position`"
            } /* clause_processing */
          },
          {
            "reconsidering_access_paths_for_index_ordering": {
              "clause": "ORDER BY",
              "index_order_summary": {
                "table": "`employees`",
                "index_provides_order": false,
                "order_direction": "undefined",
                "index": "unknown",
                "plan_changed": false
              } /* index_order_summary */
            } /* reconsidering_access_paths_for_index_ordering */
          },
          {
            "refine_plan": [
              {
                "table": "`employees`"
              }
            ] /* refine_plan */
          }
        ] /* steps */
      } /* join_optimization */
    },
    {
      "join_execution": {
        "select#": 1,
        "steps": [
          {
            "filesort_information": [
              {
                "direction": "asc",
                "table": "`employees`",
                "field": "position"
              }
            ] /* filesort_information */,
            "filesort_priority_queue_optimization": {
              "usable": false,
              "cause": "not applicable (no LIMIT)"
            } /* filesort_priority_queue_optimization */,
            "filesort_execution": [
            ] /* filesort_execution */,
            "filesort_summary": {
              "rows": 3,
              "examined_rows": 3,
              "number_of_tmp_files": 0,
              "sort_buffer_size": 200704,
              "sort_mode": "<sort_key, packed_additional_fields>"
            } /* filesort_summary */
          }
        ] /* steps */
      } /* join_execution */
    }
  ] /* steps */
}

select * from employees where name > 'zzz' order by position; 
SELECT * FROM information_schema.OPTIMIZER_TRACE; 
-- 查看trace字段可知索引扫描的成本低于全表扫描，所以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：

可以用覆盖索引优化

也可以用 force index 强制使用索引

优化总结

1、MySQL支持两种方式的排序filesort和index，Using index是指MySQL扫描索引本身完成排序。index 效率高，filesort效率低。

2、order by满足两种情况会使用Using index。

​ 1) order by语句使用索引最左前列。

​ 2) 使用where子句与order by子句条件列组合满足索引最左前列

3、尽量在索引列上完成排序，遵循索引建立（索引创建的顺序）时的最左前缀法则。

4、如果order by的条件不在索引列上，就会产生Using filesort。

5、能用覆盖索引尽量用覆盖索引 （即查询的所有列被组合索引的字段包含）

6、group by与order by很类似，其实质是先排序后分组，遵照索引创建顺序的最左前缀法则。对于group by的优化如果不需要排序的可以加上order by null禁止排序。注意，where高于having，能写在where中 的限定条件就不要去having限定了。

1、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 >

max_length_for_sort_data

​ MySQL 通过比较系统变量 max_length_for_sort_data(默认1024字节) 的大小和需要查询的字段总大小来判断使用哪种排序模式。
​ 如果 max_length_for_sort_data 比查询字段的总长度大，那么使用 单路排序模式；
​ 如果 max_length_for_sort_data 比查询字段的总长度小，那么使用 双路排序模式。

set session optimizer_trace="enabled=on",end_markers_in_json=on; -- 开启trace 
select * from employees where name = 'zhuge' order by position; 
select * from information_schema.OPTIMIZER_TRACE;
trace排序部分结果： 

"join_execution": { --Sql执行阶段 
"select#": 1, 
"steps": [ 
{ 
 "filesort_information": [ 
 { 
 "direction": "asc", 
 "table": "`employees`", 
 "field": "position" 
 } 
 ] /* filesort_information */, 
 "filesort_priority_queue_optimization": { 
 "usable": false, 
 "cause": "not applicable (no LIMIT)" 
 } /* filesort_priority_queue_optimization */, 
 "filesort_execution": [ 
 ] /* filesort_execution */, 
 "filesort_summary": { --文件排序信息 
 "rows": 10000, --预计扫描行数 
 "examined_rows": 10000, --参数排序的行 
 "number_of_tmp_files": 3, --使用临时文件的个数，这个值如果为0代表全部使用的sort_buffer内存排序，否则使用的 磁盘文件排序 
 "sort_buffer_size": 262056, --排序缓存的大小 
 "sort_mode": "<sort_key, packed_additional_fields>" --排序方式，这里用的单路排序 
} /* filesort_summary */ 
 } 
] /* steps */ 
} /* join_execution */ 


set max_length_for_sort_data = 10; --employees表所有字段长度总和肯定大于10字节 
select * from employees where name = 'zhuge' order by position; 
select * from information_schema.OPTIMIZER_TRACE;

trace排序部分结果： 
"join_execution": { 
"select#": 1,
"steps": [ 
{ 
"filesort_information": [ 
{ 
"direction": "asc", 
"table": "`employees`", 
"field": "position" 
} 
] /* filesort_information */, 
"filesort_priority_queue_optimization": { 
"usable": false, 
"cause": "not applicable (no LIMIT)" 
} /* filesort_priority_queue_optimization */, 
"filesort_execution": [ 
] /* filesort_execution */, 
"filesort_summary": { 
"rows": 10000, 
"examined_rows": 10000, 
"number_of_tmp_files": 2, 
"sort_buffer_size": 262136, 
"sort_mode": "<sort_key, rowid>" --排序方式，这里用的双路排序 
} /* filesort_summary */ 
} 
] /* steps */ 
} /* join_execution */ 


set session optimizer_trace="enabled=off"; --关闭trace

2、分页查询优化

DROP TABLE
IF
	EXISTS employees;
CREATE TABLE `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 = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT = '员工记录表';
DROP PROCEDURE
IF
	EXISTS insert_emp;
delimiter;;
CREATE PROCEDURE insert_emp ( ) BEGIN
DECLARE
		i INT;	
	SET i = 1;
	WHILE
			( i <= 100000 ) DO
			INSERT INTO employees ( NAME, age, position )
		VALUES
			( CONCAT( 'zhuge', i ), i, 'dev' );	
		SET i = i + 1;		
	END WHILE;
	END;;
delimiter;
CALL insert_emp ( );

很多时候我们业务系统实现分页功能可能会用如下sql实现
select * from employees limit 10000,10;
表示从表 employees 中取出从 10001 行开始的 10 行记录。看似只查询了 10 条记录，实际这条 SQL 是先读取 10010 条记录，然后抛弃前 10000 条记录，然后读到后面 10 条想要的数据。因此要查询一张大表比较靠后的数据，执行效率 是非常低的。

1、根据自增且连续的主键排序的分页查询

select * from employees limit 90000,5;

select * from employees where id > 90000 limit 5;

显然改写后的 SQL 走了索引，而且扫描的行数大大减少，执行效率更高。 但是，这条改写的SQL 在很多场景并不实用，因为表中可能某些记录被删后，主键空缺，导致结果不一致，如下图试验 所示（先删除一条前面的记录，然后再测试原 SQL 和优化后的 SQL）：

​ 两条 SQL 的结果并不一样，因此，如果主键不连续，不能使用上面描述的优化方法。 另外如果原 SQL 是 order by 非主键的字段，按照上面说的方法改写会导致两条 SQL 的结果不一致。所以这种改写得满 足以下两个条件：

​ 1、主键自增且连续

​ 2、结果是按照主键排序的

2、根据非主键字段排序的分页查询

EXPLAIN select * from employees ORDER BY name limit 90000,5;

Explain select * from employees e inner join (select id from employees order by name limit 90000,5) ed on e.id = ed.id;
发现并没有使用 name 字段的索引（key 字段对应的值为 null），具体原因上文讲过：扫描整个索引并查找到没索引的行(可能要遍历多个索引树)的成本比扫描全表的成本更高，所以优化器放弃使用索引。 知道不走索引的原因，那么怎么优化呢？ 其实关键是让排序时返回的字段尽可能少（索引覆盖），所以可以让排序和分页操作先查出主键，然后根据主键查到对应的记录

原SQL 使用的是 filesort 排序，而优化后的 SQL 使用的是索引排序。

3、Join关联查询优化

CREATE TABLE `t1` (
`id` INT ( 11 ) NOT NULL AUTO_INCREMENT,
`a` INT ( 11 ) DEFAULT NULL,
`b` INT ( 11 ) DEFAULT NULL,
PRIMARY KEY ( `id` ),
KEY `idx_a` ( `a` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8;
CREATE TABLE t2 LIKE t1;
-- 往t2表插入100行记录
truncate t2;
DROP PROCEDURE
IF
	EXISTS insert_emp;
delimiter;;
CREATE PROCEDURE insert_emp ( ) BEGIN
DECLARE
		i INT;	
	SET i = 1;
	WHILE
			( i <= 100 ) DO
			INSERT INTO t2 ( a, b )
		VALUES
			( i, i*i );	
		SET i = i + 1;		
	END WHILE;
	END;;
delimiter;
CALL insert_emp ( );
-- 往t1表插入1万行记录
truncate t1;
DROP PROCEDURE
IF
	EXISTS insert_emp;
delimiter;;
CREATE PROCEDURE insert_emp ( ) BEGIN
DECLARE
		i INT;	
	SET i = 1;
	WHILE
			( i <= 100 ) DO
			INSERT INTO t1 ( a, b )
		VALUES
			( i, i*i );	
		SET i = i + 1;		
	END WHILE;
	END;;
delimiter;
CALL insert_emp ( );

1、mysql的表关联常见有两种算法

1、Nested-Loop Join 算法

2、Block Nested-Loop Join 算法

1、 嵌套循环连接 Nested-Loop Join(NLJ) 算法

​ 一次一行循环地从第一张表（称为驱动表）中读取行，在这行数据中取到关联字段，根据关联字段在另一张表（被驱动表）里取出满足条件的行（走索引所以很快，再从磁盘中读取目标行，所以当做只做一次磁盘IO），然后取出两张表的结果合集。

EXPLAIN select * from t1 inner join t2 on t1.a= t2.a;

​ 从执行计划中可以看到这些信息： 驱动表是t2，被驱动表是t1。先执行的就是驱动表(执行计划结果的id如果一样则按从上到下顺序执行sql)；优 化器一般会优先选择小表做驱动表。所以使用 inner join时，排在前面的表并不一定就是驱动表。 使用了 NLJ算法。一般 join 语句中，如果执行计划 Extra 中未出现 Using join buffer 则表示使用的 join 算 法是 NLJ。

上面sql的大致流程如下：

1、从表 t2 中读取一行数据；

2、从第1步的数据中，取出关联字段 a，到表 t1中查找；

3、取出表t1中满足条件的行，跟t2中获取到的结果合并，作为结果返回给客户端；

4、重复上面 3 步

​ 整个过程会读取t2 表的所有数据(扫描100行)，然后遍历这每行数据中字段 a 的值，根据 t2 表中 a 的值索引扫描 t1 表 中的对应行(扫描100次 t1 表的索引，1次扫描可以认为最终只扫描 t1 表一行完整数据，也就是总共 t1 表也扫描了100 行)。因此整个过程扫描了200行。 如果被驱动表的关联字段没索引，使用NLJ算法性能会比较低(下面有详细解释)，mysql会选择Block Nested-Loop Join 算法。

2、基于块的嵌套循环连接 Block Nested-Loop Join(BNL)算法

把驱动表的数据读入到 join_buffer 中，然后扫描被驱动表，把被驱动表每一行取出来跟 join_buffer 中的数据做对比。

EXPLAIN select*from t1 inner join t2 on t1.b= t2.b;

Extra 中 的Using join buffer (Block Nested Loop)说明该关联查询使用的是 BNL 算法。

上面sql的大致流程如下：

1、 把 t2 的所有数据放入到 join_buffer 中

2、把表 t1 中每一行取出来，跟 join_buffer 中的数据做对比

3、返回满足 join 条件的数据

整个过程对表 t1 和 t2 都做了一次全表扫描，因此扫描的总行数为10000(表 t1 的数据总量) + 100(表 t2 的数据总量) = 10100。并且 join_buffer 里的数据是无序的，因此对表 t1 中的每一行，都要做 100 次判断，所以内存中的判断次数是 100 * 10000= 100 万次。 被驱动表的关联字段没索引为什么要选择使用 BNL 算法而不使用 Nested-Loop Join呢？

​ 如果上面第二条sql使用 Nested-Loop Join，那么扫描行数为 100 * 10000 = 100万次，这个是磁盘扫描。很显然，用BNL磁盘扫描次数少很多，相比于磁盘扫描，BNL的内存计算会快得多。

​ 因此MySQL对于被驱动表的关联字段没索引的关联查询，一般都会使用 BNL 算法。如果有索引一般选择 NLJ 算法，有索引的情况下NLJ 算法比 BNL算法性能更高

2、对于关联sql的优化

1、关联字段加索引，让mysql做join操作时尽量选择NLJ算法

2、小标驱动大表，写多表连接sql时如果明确知道哪张表是小表可以用straight_join写法固定连接驱动方式，省去mysql优化器自己判断的时间（注意left join 已经决定了驱动表是左边，同理right join,使用inner join时myslq优化器才能自动优化）

​ straight_join：straight_join功能同join类似，但能让左边的表来驱动右边的表，能改表优化器对于联表查询的执行顺序。

比如：select * from t2 straight_join t1 on t2.a = t1.a; 代表制定mysql选着 t2 表作为驱动表。

​ straight_join只适用于inner join，并不适用于left join，right join。（因为left join，right join已经代表指

定了表的执行顺序）

​ 尽可能让优化器去判断，因为大部分情况下mysql优化器是比人要聪明的。使用straight_join一定要慎重，因

为部分情况下人为指定的执行顺序并不一定会比优化引擎要靠谱。

4、in和exsits优化

原则：小表驱动大表，即小的数据集驱动大的数据集

in：当B表的数据集小于A表的数据集时，in优于exists

select * from A where id in (select id from B) 
# 等价于：
for(select id from B){ 
	select * from A where A.id = B.id 
}

exists：当A表的数据集小于B表的数据集时，exists优于in

select * from A where exists (select 1 from B where B.id = A.id) 
#等价于: 
for(select * from A){ 
 select * from B where B.id = A.id 
} 
#A表与B表的ID字段应建立索引

1、EXISTS (subquery)只返回TRUE或FALSE,因此子查询中的SELECT * 也可以用SELECT 1替换,官方说法是实际执行时会 忽略SELECT清单,因此没有区别

2、EXISTS子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比

3、EXISTS子查询往往也可以用JOIN来代替，何种最优需要具体问题具体分析

5、count(*)查询优化

EXPLAIN select count(1) from employees;
EXPLAIN select count(id) from employees;
EXPLAIN select count(name) from employees;
EXPLAIN select count(*) from employees;

​ 四个sql的执行计划一样，说明这四个sql执行效率应该差不多，区别在于根据某个字段count不会统计字段为null值的数 据行为什么mysql最终选择辅助索引而不是主键聚集索引？因为二级索引相对主键索引存储数据更少，检索性能应该更高

常见优化方法

1、查询mysql自己维护的总行数

​ 对于myisam存储引擎的表做不带where条件的count查询性能是很高的，因为myisam存储引擎的表的总行数会被mysql存储在磁盘上，查询不需要计算

对于innodb存储引擎的表mysql不会存储表的总记录行数，查询count需要实时计算

2、show table status

​ 如果只需要知道表总行数的估计值可以用如下sql查询，性能很高

1、ANALYZE table employees;
2、show table status where name = “employees”

3、将总数维护到Redis里

​ 插入或删除表数据行的时候同时维护redis里的表总行数key的计数值(用incr或decr命令)，但是这种方式可能不准，很难 保证表操作和redis操作的事务一致性

4、增加计数表

​ 插入或删除表数据行的时候同时维护计数表，让他们在同一个事务里操作