一. MySQL内部如何选索引
数据准备：
用到的还是employees表，name-age-position为联合索引。
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='员工记录表';
1. 案例1
EXPLAIN select * from employees where name > 'a';
执行计划如下：
分析：如果用name索引需要遍历name字段联合索引树，然后还需要根据遍历出来的主键值去主键索引树里再去查出最终数据，成本比全表扫描 还高，所以mysql优化器直接选择使用全表扫描。
2. 案例2
EXPLAIN select name,age,position from employees where name > 'a' ;
执行计划如下：
分析：使用覆盖索引优化，这样只需要遍历name字段的联合索引树就能拿到所有结果。
3. 案例3
EXPLAIN select * from employees where name > 'zzz' ;
执行计划如下：
分析：对于上面这两种 name>'a' 和 name>'zzz' 的执行结果，mysql最终是否选择走索引或者一张表涉及多个索引，mysql最终如何选择索引，我们可以用trace工具来一查究竟，开启trace工具会影响mysql性能，所以只能临时分析sql使用，用 完之后立即关闭。
Trace工具分析
1 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`,`empl 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 */ 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 } /* analyzing_roworder_intersect */ 114 } /* analyzing_range_alternatives */ 115 } /* range_analysis */ 116 } 117 ] /* rows_estimation */ 118 }, 119 { 120 "considered_execution_plans": [ 121 { 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", 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 } 205 206 结论：全表扫描的成本低于索引扫描，所以mysql最终选择全表扫描 207 208 mysql> select * from employees where name > 'zzz' order by position; 209 mysql> SELECT * FROM information_schema.OPTIMIZER_TRACE; 210 211 查看trace字段可知索引扫描的成本低于全表扫描，所以mysql最终选择索引扫描 212 213 mysql> set session optimizer_trace="enabled=off"; ‐‐关闭trace
二. Order By 和 Group By
1. 案例分析
案例1
explain select * from employees where name='LiLei' and position='dev' order by age;
执行计划：
分析：
利用最左前缀法则：中间字段不能断，因此查询用到了name索引，从key_len=74也能看出，age索引列用在排序过程中，因为Extra字段里没有using filesort的出现。
案例2
explain select * from employees where name='LiLei' order by position;
执行计划：
分析：
从explain的执行结果来看：key_len=74，查询使用了name索引，由于用了position进行排序，跳过了 age，出现了Using filesort。
案例3
explain select * from employees where name='LiLei' order by age,position;
执行计划：
分析：
查找只用到索引name，age和position用于排序，无Using filesort。
案例4
explain select * from employees where name='LiLei' order by position,age;
执行计划：
分析：
出现了Using filesort，因为索引的创建顺序为 name,age,position，但是排序的时候是先排position，后排age，显然根据B+Tree的结构，索引无法达到目的，所以用到了filesort。
案例5
explain select * from employees where name='LiLei' and age=18 order by position,age;
执行计划：
分析：
在Extra中并未出现Using filesort，因为age为常量，在排序中被优化，所以索引未颠倒， 不会出现Using filesort。
案例6
explain select * from employees where name='zhuge' order by age asc,position desc;
执行计划：
分析：
虽然排序的字段列与索引顺序一样，且order by默认升序，这里position desc变成了降序，导致与索引的排序方式（联合索引每个字段都是升序排列）不同，从而产生Using filesort。Mysql8以上版本有降序索引可以支持该种查询方式。
案例7
explain select * from employees where name in ('LiLei','zhuge') order by age,position;
执行计划：
分析：
对于排序来说，多个相等条件也是范围查询。
案例8
(1).
explain select * from employees where name > 'a' order by name;
(2). 用覆盖索引优化
explain select name,age,position from employees where name > 'a' order by name;
2. 优化总结
(1). MySQL支持两种方式的排序filesort和index，Using index是指MySQL扫描索引本身完成排序。index 效率高，filesort效率低。
(2). order by满足两种情况会使用Using index。
A. order by语句使用索引最左前列。
B. 使用where子句与order by子句条件列组合满足索引最左前列。
(3). 尽量在索引列上完成排序，遵循索引建立（索引创建的顺序）时的最左前缀法则。
(4). 如果order by的条件不在索引列上，就会产生Using filesort。
(5). 能用覆盖索引尽量用覆盖索引
(6). group by与order by很类似，其实质是先排序后分组，遵照索引创建顺序的最左前缀法则。对于group by的优化如果不需要排序的可以加上order by null禁止排序。注意，where高于having，能写在where中 的限定条件就不要去having限定了。
3. Using filesort文件排序原理详解
(1). 文件排序方式
A. 单路排序：是一次性取出满足条件行的所有字段，然后在sort buffer中进行排序；用trace工具可 以看到sort_mode信息里显示< sort_key, additional_fields >或者< sort_key, packed_additional_fields >
B. 双路排序（又叫回表排序模式）：是首先根据相应的条件取出相应的排序字段和可以直接定位行 数据的行 ID，然后在 sort buffer 中进行排序，排序完后需要再次取回其它需要的字段；用trace工具 可以看到sort_mode信息里显示< sort_key, rowid >
PS: MySQL 通过比较系统变量 max_length_for_sort_data(默认1024字节) 的大小和需要查询的字段总大小来 判断使用哪种排序模式。
如果 max_length_for_sort_data 比查询字段的总长度大，那么使用 单路排序模式；
如果 max_length_for_sort_data 比查询字段的总长度小，那么使用 双路排序模式。
(2). 文件排序过程
我们先看单路排序的详细过程：
1. 从索引 name 找到第一个满足 name = ‘zhuge’ 条件的主键 id
2. 根据主键 id 取出整行，取出所有字段的值，存入 sort_buffer 中
3. 从索引 name 找到下一个满足 name = ‘zhuge’ 条件的主键 id
4. 重复步骤 2、3 直到不满足 name = ‘zhuge’
5. 对 sort_buffer 中的数据按照字段 position 进行排序
6. 返回结果给客户端
我们再看下双路排序的详细过程：
1. 从索引 name 找到第一个满足 name = ‘zhuge’ 的主键id
2. 根据主键 id 取出整行，把排序字段 position 和主键 id 这两个字段放到 sort buffer 中
3. 从索引 name 取下一个满足 name = ‘zhuge’ 记录的主键 id
4. 重复 3、4 直到不满足 name = ‘zhuge’
5. 对 sort_buffer 中的字段 position 和主键 id 按照字段 position 进行排序
6. 遍历排序好的 id 和字段 position，按照 id 的值回到原表中取出 所有字段的值返回给客户端
(3). 剖析
其实对比两个排序模式，单路排序会把所有需要查询的字段都放到 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很多参数设置都是做过优化的，不要轻易调整。
三. 分页查询优化
数据准备：
用到的还是employees表，下面增加10w条数据， name-age-position为联合索引
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语句，表示从表 employees 中取出从 10001 行开始的 10 行记录。看似只查询了 10 条记录，实际这条 SQL 是先读取 10010 条记录，然后抛弃前 10000 条记录，然后读到后面 10 条想要的数据。因此要查询一张大表比较靠后的数据，执行效率 是非常低的。
select * from employees limit 10000,10;
1. 根据自增且连续的主键排序的分页查询
(1). 下面两句SQL语句查询结果一致
--，没添加单独 order by，表示通过主键排序 select * from employees limit 9000,5; select * from employees where id > 9000 limit 5;
(2). 分析这两句话的执行计划
-- 全表扫描 EXPLAIN select * from employees limit 9000,5; -- range级别 EXPLAIN select * from employees where id > 9000 limit 5;
剖析：一旦删除数据，这种优化模式就不要用了，上面两条sql语句查询出来的结果不一致。
所以这种优化的前提是：① 主键自增且连续 ② 查询结果根据主键排序。
2. 根据非主键字段排序的分页查询
(1).案例
A. 运行下面语句
select * from employees ORDER BY name limit 9000,5;
B. 查看执行计划
explain select * from employees ORDER BY name limit 9000,5;
剖析：这里我们发现，并没有用到name索引，根据前面的讲解，我们知道这是因为：由于是select *，扫描整个索引并查找到所有的行(可能要遍历多个索引树)的成本比扫描全表的成本更高，所以优化器放弃使用索引。
(2) 优化
思路：是让排序时返回的字段尽可能少，所以可以让排序和分页操作先查出主键，然后根据主键查到对应的记录，如下：
select * from employees e inner join (select id from employees order by name limit 9000,5) ed on e.id = ed.id;
剖析：查询结果和上面结果一致，执行时间减少了1半多，而且用到了索引，还用到了索引排序。
四. Join关联查询优化
数据准备：
有t1和t2两张结构完全相同的表，t1表插入1万条数据，t2表插入100条数据。a字段上有索引。
--t1表 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 AUTO_INCREMENT=10001 DEFAULT CHARSET=utf8; --t2表 create table t2 like t1; --往t1表插入1万行记录，往t2表插入100行记录 drop procedure if exists insert_t1; delimiter ;; create procedure insert_t1() begin declare i int; set i=1; while(i<=10000)do insert into t1(a,b) values(i,i); set i=i+1; end while; end;; delimiter ; call insert_t1(); drop procedure if exists insert_t2; delimiter ;; create procedure insert_t2() begin declare i int; set i=1; while(i<=100)do insert into t2(a,b) values(i,i); set i=i+1; end while; end;; delimiter ; call insert_t2();
补充：
mysql的表关联常见有两种算法 ，① Nested-Loop Join 算法（NLJ） ② Block Nested-Loop Join 算法 （BNL）
1. 嵌套循环连接 Nested-Loop Join(NLJ) 算法
补充：驱动表和被驱动表概念
1次一行一行循环地从第一张表（称为驱动表，驱动表一般是关联数据较少的那张表）中读取行，在这行数据中取到关联字段，根据关联字段在另一张表（被驱动 表）里取出满足条件的行，然后取出两张表的结果合集。
案例：
EXPLAIN select * from t1 inner join t2 on t1.a= t2.a; EXPLAIN select * from t2 inner join t1 on t1.a= t2.a;
(1). 分析执行计划
A. 驱动表是 t2，被驱动表是 t1。先执行的就是驱动表(执行计划结果的id如果一样则按从上到下顺序执行sql)；优化器一般会优先选择小表做驱动表。所以使用 inner join 时，排在前面的表并不一定就是驱动表。
B. 使用了 NLJ算法。一般 join 语句中，如果执行计划 Extra 中未出现 Using join buffer 则表示使用的 join 算 法是 NLJ。
PS：上面两条SQL语句，无论怎么t1和t2是否颠倒顺序，都是t2表为驱动表，这个是mysql内部优化器决定的，选择小表作为驱动表。
(2). SQL的执行流程
A. 从表 t2 中读取一行数据；
B. 从第 1 步的数据中，取出关联字段 a，到表 t1 中查找；
C. 取出表 t1 中满足条件的行，跟 t2 中获取到的结果合并，作为结果返回给客户端；
D. 重复上面 3 步。
分析：
整个过程会读取 t2 表的所有数据(磁盘IO扫描100行)，然后遍历这每行数据中字段 a 的值，根据 t2 表中 a 的值索引扫描 t1 表 中的对应行 (扫描100次 t1 表的索引，1次扫描可以认为最终只扫描 t1 表一行完整数据，也就是总共 t1 表也扫描了100 行)，因此整个过程扫描了 200 行。
注：去t1表中索引扫描，假设B+Tree的高度为3，而根节点通常存在内存中，所有每找一条数据，两次IO就可以找到，上面写的t1表扫描100行，是忽略了B+Tree前两层，只算叶子节点。
抛砖引玉：
如果被驱动表的关联字段没索引，使用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;
(1). 分析执行计划
(2). SQL执行顺序
A. 把 t2 的所有数据放入到 join_buffer 中
B. 把表 t1 中每一行取出来，依次跟 join_buffer 中的每行数据做对比
C. 返回满足 join 条件的数据
分析：
整个过程对表 t1 和 t2 都做了一次全表扫描，因此磁盘IO扫描的总行数为10000(表 t1 的数据总量) + 100(表 t2 的数据总量) = 10100。并且 join_buffer 里的数据是无序的，因此对表 t1 中的每一行，都要做 100 次判断，所以内存中的判断次数是 100 * 10000= 100 万次（内存判断100w次速度还是很快的）。
3. 灵魂拷问
被驱动表的关联字段没索引为什么要选择使用 BNL 算法而不使用 Nested-Loop Join 呢？
答：如果使用 Nested-Loop Join，那么扫描行数为 100 * 10000 = 100万次，这个是磁盘IO扫描。很显然，用BNL磁盘扫描次数少很多，相比于磁盘扫描，BNL的内存计算会快得多。 因此MySQL对于被驱动表的关联字段没索引的关联查询，一般都会使用 BNL 算法。如果有索引一般选择 NLJ 算法，有 索引的情况下 NLJ 算法比 BNL算法性能更高。
4. 关联sql的优化
(1). 关联字段加索引，让mysql做join操作时尽量选择NLJ算法。
(2). 小表驱动大表，写多表连接sql时如果明确知道哪张表是小表可以用straight_join写法固定连接驱动方式，省去 mysql优化器自己判断的时间 。
PS：
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已经代表指 定了表的执行顺序，left join 左边的为驱动表，right join 右边的为驱动表） 尽可能让优化器去判断，因为大部分情况下mysql优化器是比人要聪明的。
使用straight_join一定要慎重，因 为部分情况下人为指定的执行顺序并不一定会比优化引擎要靠谱。
5. in和exsits优化
原则：小表驱动大表，即小的数据集驱动大的数据集。
(1). 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 }
(2). exists：当A表的数据集小于B表的数据集时，exists优于in 将主查询A的数据，放到子查询B中做条件验证，根据验证结果（true或false）来决定主查询的数据是否保留.
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 }
PS:
A、EXISTS (subquery)只返回TRUE或FALSE,因此子查询中的SELECT * 也可以用SELECT 1替换,官方说法是实际执行时会 忽略SELECT清单,因此没有区别
B、EXISTS子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比
C、EXISTS子查询往往也可以用JOIN来代替，何种最优需要具体问题具体分析
五. Count(*)查询优化
1. 案例
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的执行计划一样，说明这四个sql执行效率应该差不多，区别在于 count里面如果是辅助索引，或者是一个不含索引的字段，则不会统计该字段对应的值为null的记录。
灵魂拷问：
为什么mysql最终选择辅助索引而不是主键聚集索引？
答：因为辅助索引相对主键索引存储数据更少，检索性能应该更高。
最终耗费的时间大约应该是：count(1)>count(name) ≈ count(*) > count(id) , 在mysql5.7及后续版本中，这4个count耗费的时间已经很相近了。
2. 如何优化
(1). MyIsam存储引擎特有的
对于myisam存储引擎的表做不带where条件的count查询性能是很高的，因为myisam存储引擎的表的总行数会被 mysql存储在磁盘上，查询不需要计算。
注：对于innodb存储引擎的表mysql不会存储表的总记录行数，查询count需要实时计算。
(2). show table status
如果只需要知道表总行数的估计值可以用如下sql查询，性能很高。
show table status like 'employees';
(3). 将总数维护到Redis中
插入或删除表数据行的时候同时维护redis里的表总行数key的计数值(用incr或decr命令)，但是这种方式可能不准，很难 保证表操作和redis操作的事务一致性。
(4). 增加计数表
插入或删除表数据行的时候同时维护计数表，让他们在同一个事务里操作。
!
- 作 者 : Yaopengfei(姚鹏飞)
- 博客地址 : http://www.cnblogs.com/yaopengfei/
- 声 明1 : 如有错误，欢迎讨论，请勿谩骂^_^。
- 声 明2 : 原创博客请在转载时保留原文链接或在文章开头加上本人博客地址，否则保留追究法律责任的权利。