视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
简单解析MySQL中的cardinality异常
2020-11-09 21:01:04 责编:小采
文档


前段时间,一大早上,就收到报警,警告php-fpm进程的数量超过阈值。最终发现是一条sql没用到索引,导致执行数据库查询慢了,最终导致php-fpm进程数增加。最终通过analyze table feed_comment_info_id_0000 命令更新了Cardinality ,才能再次用到索引。
排查过程如下:
sql语句:

select id from feed_comment_info_id_0000 where obj_id=101 and type=1;

索引信息:

show index from feed_comment_info_id_0000
+---------------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+---------------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| feed_comment_info_id_0000 | 0 | PRIMARY | 1 | id | A | 6216 | NULL | NULL | | BTREE | | 
| feed_comment_info_id_0000 | 1 | obj_type | 1 | obj_id | A | 6216 | NULL | NULL | | BTREE | | 
| feed_comment_info_id_0000 | 1 | obj_type | 2 | type | A | 6216 | NULL | NULL | YES | BTREE | | 
| feed_comment_info_id_0000 | 1 | user_id | 1 | user_id | A | 6216 | NULL | NULL | | BTREE | | 
+---------------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
5 rows in set (0.00 sec)

通过explian查看时,发现sql用的是主键PRIMARY,而不是obj_type索引。通过show index 查看索引的Cardinality值,发现这个值是实际数据的两倍。感觉这个Cardinality值已经不正常,因此通过analyzea table命令对这个值从新进行了计算。命令执行完毕后,就可用使用索引了。

Cardinality解释
官方文档的解释:
An estimate of the number of unique values in the index. This is updated by running ANALYZE TABLE or myisamchk -a. Cardinality is counted based on statistics stored as integers, so the value is not necessarily exact even for small tables. The higher the cardinality, the greater the chance that MySQL uses the index when doing
总结一下:
1、它代表的是索引中唯一值的数目的估计值。如果是myisam引擎,这个值是一个准确的值。如果是innodb引擎,这个值是一个估算的值,每次执行show index 时,可能会不一样
2、创建Index时(primary key除外),MyISAM的表Cardinality的值为null,InnoDB的表Cardinality的值大概为行数;
3、值的大小会影响到索引的选择
4、创建Index时,MyISAM的表Cardinality的值为null,InnoDB的表Cardinality的值大概为行数。
5、可以通过Analyze table来更新一张表或者mysqlcheck -Aa来进行更新整个数据库
6、可以通过 show index 查看其值

您可能感兴趣的文章:

  • MySQL抛出Incorrect string value异常分析
  • MySql存储过程异常处理示例代码分享
  • php更新mysql后获取影响的行数发生异常解决方法
  • MySQL异常处理浅析
  • MySQL存储过程中一些基本的异常处理教程
  • MySQL存储过程的异常处理方法
  • SELinux导致PHP连接MySQL异常Can''t connect to MySQL server的解决方法
  • 如何解决安装MySQL5.0后出现1607异常
  • 分析一个MySQL的异常查询的案例
  • MySQL定义异常和异常处理详解
  • 下载本文
    显示全文
    专题