执行计划错误—索引统计信息的不准确

  • 时间:
  • 浏览:0
  • 来源:大发欢乐生肖APP下载_大发欢乐生肖APP官网

| innodb_stats_sample_pages | 8     |

root@test 10:57:27>show status like ‘%last_query_cost%’;

而且有已经 你这名 cost并全部都是十分有参考意义:

KEY `ind_user_gmt` (`user_id`,`gmt_create`)

都可不可否 看一遍优化器优化器对比了KEY `ind_user_id`,KEY `ind_user_gmt`,选用cost最低KEY `ind_user_id`来执行;

`user_id` bigint(20) unsigned DEFAULT ‘0’ COMMENT ‘用户id’,

+———————+———+———-+———-+

PRIMARY KEY (`id`),

+—————–+—————+

+—————-+————+——————+————–+————-+———

| recommend_0202 |          1 | ind_review_staus |            1 | review_id   | A         |         210 |     NULL | NULL   |      | BTREE      |         |

+—————-+————+——————+————–+————-+———

+—————————+——-+

root@test 10:53:49>show status like ‘%last_query_cost%’;

`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT ‘自增主键’,

+—-+————-+—————-+——+——————————-+————

+—————-+————+——————+————–+————-+———

| id | select_type | table          | type  | possible_keys            | key          | key_len | ref  | rows | Extra       |

+—————–+—————+

1 row in set (0.00 sec)

+—————–+————-+

+—————–+————-+

+—-+————-+—————-+——+——————————-+————



mysql在生成执行计划的已经 ,需用根据索引的统计信息进行有有好几个 估算,计算出成本最低的索引;

+—-+————-+—————-+——+—————+————-+———+—-

+—-+————-+—————-+——+————————–+————-+—

| recommend_0202 |          1 | index_reivew     |            1 | review_id   | A         |     2219712 |     NULL | NULL   |      | BTREE      |         |

| Variable_name   | Value         |

|  1 | SIMPLE      | recommend | ref  | ind_user_gmt  | ind_user_gmt | 9       | const | 61400 | Using where |

root@test 10:57:25>explain select target_id from recommend  where user_id=0  order by gmt_Create limit 10;

| recommend_0202 |          1 | index_review     |            1 | review_id   | A         |     24001924 |     NULL | NULL   |      | BTREE      |         |

root@test 10:27:52>show  index from recommend;

| Table          | Non_unique | Key_name         | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |

| Last_query_cost | 244144.278570 |

| recommend_0202 |          1 | ind_review_staus |            2 | status      | A         |       210 |     NULL | NULL   | YES  | BTREE      |         |

5.1估算rows estimate的算法发生bug http://bugs.mysql.com/bug.php?id=53761 ,

么你的执行计划很有原因分析分析原因分析分析索引统计信息的不准确,原因分析分析优化不到够正确的选用索引:

+—-+————-+—————-+——+—————+————–+———+—

root@test 10:53:20>explain select target_id from recommend where user_id=44312518  order by gmt_Create limit 10 ;

+—————–+—————+

`gmt_modified` datetime NOT NULL COMMENT ‘记录最后修改时间’,

| test.recommend | analyze | status   | OK       |

+———————+———+———-+———-+

+—-+————-+—————-+——+——————————-+————

+—-+————-+—————-+——-+————————–+————–+-

root@test 10:31:27>show  index from recommend;

1 row in set (0.00 sec)

| Last_query_cost | 7355.999000 |

root@test 10:54:51>explain select target_id from recommend force index(ind_user_id) where user_id=0  order by gmt_Create limit 10;

测试案例,表中的索引加上原因分析分析测试:

1 row in set (0.01 sec)

都可不可否 看一遍优化器原因分析分析都都都可不可否正确选用索引了;

| Variable_name   | Value         |

| recommend_0202 |          1 | ind_review_staus |            1 | review_id   | A     |   2219712 |     NULL | NULL   |      | BTREE      |         |

+—————–+————-+

| Variable_name   | Value       |

| id | select_type | table          | type | possible_keys                 | key              | key_len | ref         | rows | Extra                    |

+—————-+————+——————+————–+————-+———

+—-+————-+—————-+——+——————————-+————

+—————————+——-+

| id | select_type | table          | type | possible_keys | key         | key_len | ref   | rows    | Extra                                    |

root@test 10:55:42>show status like ‘%last_query_cost%’;

+—-+————-+—————-+——-+————————–+————–+———+——+——+————-+

`review_id` varchar(32) NOT NULL COMMENT ‘点评id’,

1 row in set (0.00 sec)

而且mysql索引统计信息的埋点默认8个page:

当大家 来看有有好几个 查询:

KEY `ind_review_staus` (`review_id`,`status`),

`target_id` varchar(32) NOT NULL COMMENT ‘店铺id’,

| id | select_type | table          | type | possible_keys | key          | key_len | ref   | rows | Extra       |

+—————-+————+——————+————–+————-+———

| Table               | Op      | Msg_type | Msg_text |

+—————–+—————+

1 row in set (0.00 sec)

1 row in set (0.00 sec)

root@test 08:48:52>show global variables like ‘%samp%’;

+—————–+————-+

root@test 10:31:35>explain select status from recommend  where review_id=’00000015bf5445a88462ba047aab114c’ and status=1;

+—-+————-+—————-+——+————————–+————-+—

`recommend` varchar(32) NOT NULL COMMENT ‘内容’,

1 row in set (0.00 sec)

root@test 10:52:19>explain select target_id from recommend force index(ind_user_gmt) where user_id=44312518  order by gmt_Create limit 10;

| id | select_type | table          | type | possible_keys                 | key          | key_len | ref   | rows | Extra       |

| id | select_type | table          | type | possible_keys            | key         | key_len | ref   | rows | Extra                                    |

) ENGINE=InnoDB;

select status from recommend  where review_id=’00000015bf5445a88462ba047aab114c’ and status=1;

| recommend_0202 |          0 | PRIMARY          |            1 | id          | A         |     24001924 |     NULL | NULL   |      | BTREE      |         |

+—————–+—————+

| recommend_0202 |          0 | PRIMARY          |            1 | id          | A         |     2219712 |     NULL | NULL   |      | BTREE      |         |

root@test 10:53:09>show status like ‘%last_query_cost%’;

+—-+————-+—————-+——+————————–+————-+—

+—-+————-+—————-+——+——————————-+————

+—————–+————-+

1 row in set (0.00 sec)

+—-+————-+—————-+——+—————+————–+———+—

`gmt_create` datetime NOT NULL COMMENT ‘记录创建时间’,

|  1 | SIMPLE      | recommend | index | ind_user_id,ind_user_gmt | ind_user_gmt | 17      | NULL |   20 | Using where |

+—————-+————+——————+————–+————-+———

root@test 10:31:08>analyze table recommend

+———————+———+———-+———-+

1 row in set (0.00 sec)

|  1 | SIMPLE      | recommend | ref  | index_review,ind_review_staus | index_review | 66      | const |    1 | Using where |

| Last_query_cost | 1243.5840097 |

| Variable_name   | Value       |

+—-+————-+—————-+——+—————+————-+———+—-

|  1 | SIMPLE      | recommend | ref  | ind_user_id   | ind_user_id | 9       | const | 1158435 | Using where; Using index; Using filesort |

+—————–+————-+

`user_id_kb` int(10) unsigned DEFAULT ‘0’ COMMENT ‘用户id’,

mysql生成的每个执行计划全部都是有有好几个 cost,和其他统统关系数据库一样,同样以成本最低的执行计划来运行实际的查询:

这都可不可否 否看一遍优化器选用了index_reivew你这名 索引,而且在回表过滤,而并这样选用reivew_id,status你这名 索引来覆盖查询,这里优化器就这样进行优化的选用了;

|  1 | SIMPLE      | recommend | ref  | ind_user_id,ind_user_gmt | ind_user_id | 9       | const | 5896 | Using where; Using index; Using filesort |

都可不可否 看一遍analyze 后,索引ind_review_staus的统计信息原因分析分析恢复了正常;这样在来看看执行计划:

|  1 | SIMPLE      | recommend | ref  | ind_review_staus,index_reivew | ind_review_staus | 68      | const,const |    1 | Using where; Using index |

| Variable_name             | Value |

CREATE TABLE `recommend` (

+—————————+——-+

+—-+————-+—————-+——+—————+————–+———+—

+—————–+—————+

+—-+————-+—————-+——+—————+————-+———+—-

已经 们看看是全部都是统计信息出来现象:

都可不可否 看一遍ind_review_staus和index_review第有有好几个 字段都同为review_id,而且当大家 的Cardinality相差还是很大的,这也是为哪些优化器选用了index_review 你这名 索引;

第有有好几个 查询强制走:  KEY `ind_user_gmt` (`user_id`,`gmt_create`)

| recommend_0202 |          1 | ind_review_staus |            2 | status      | A        |     2219712 |     NULL | NULL   | YES  | BTREE      |         |

| Table          | Non_unique | Key_name         | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |

+—-+————-+—————-+——-+————————–+————–+-

已经 们来手工分析一把:

第十个 查询,优化器选用:  KEY `ind_user_id` (`user_id`,`status`,`gmt_create`,`target_id`),

root@test 10:27:00>explain select status from recommend  where review_id=’00000015bf5445a88462ba047aab114c’ and status=1;

+—-+————-+—————-+——+——————————-+————

有有好几个 执行计划的cost是一样的,你这名 已经 还是需用有经验的DBA来参与调整;

有已经 当大家 在判断优化器与非 选用了正确的执行计划的已经 ,有有有好几个 情况表变量值,他都可不可否 给当大家 其他信息,而是 每个执行计划的cost,

| Last_query_cost | 244144.278570 |

KEY `ind_user_id` (`user_id`,`status`,`gmt_create`,`target_id`),

`status` tinyint(3) unsigned DEFAULT ‘0’ COMMENT ‘推荐菜情况表’,

KEY `index_reivew` (`review_id`),