Mysql选错索引 ANALYZE TABLE

最新推荐文章于 2025-08-18 15:36:33 发布
原创 最新推荐文章于 2025-08-18 15:36:33 发布 · 387 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

博客指出MySQL选错索引是由于explain的rows统计不正确，可通过执行ANALYZE TABLE xx来解决该问题，聚焦于信息技术领域的数据库相关问题。

Mysql选错索引是 因为 explain 的 rows 统计不正确，ANALYZE TABLE xx 即可。

小黑客xhk
关注
MySQL——选错索引导致的线上慢查询事故
庄小焱
04-07 569
采样统计的时候，InnoDB默认会选择N个数据页，统计这些页面上的不同值，得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数。所以在不加强制索引的情况下，优化器选择了主键索引，因为它觉得主键索引扫描行数少，而且不需要额外的排序操作，主键索引天生有序。这样也有一定的弊端，比如我这个表到了8000w数据，建立索引非常耗时，而且通常索引就有3.4个g，如果无限制的用索引解决问题，可能会带来新的问题。高耦合，这种语句写在代码里，会变得难以维护，如果索引名变化了，或者没有这个索引了，代码就要反复修改。
MySQL定期分析检查与优化表的方法小结
12-15
定期分析表 ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] 本语句用于分析和存储表的关键字分布。在分析期间，使用一个读取锁定对表进行锁定。这对于MyISAM, BDB和InnoDB表有作用。对于MyISAM表，本语句与使用myisamchk -a相当。 MySQL使用已存储的关键字分布来决定，当您对除常数以外的对象执行联合时，表按什么顺序进行联合。 mysql> analyze table a; +——–+———+———-+—————————–+ | Table  | Op      | Msg_type | M
[MySQL]ANALYZE TABLE 更新索引基数
Unknowncheats的博客
11-22 276
MySQL使用存储的键分布基数来确定表连接顺序在决定对查询中的特定表使用哪些索引时，也会使用使用键分布基数 ANALYZE TABLE 表名 可以更新表的索引基数，使其更接近非重复的记录数，记录数可以使用show index from 表 来查询cardinality字段 mysql> show index from index_test; +------------+------------+--------------------+--------------+------------...
mysql有时候使用主键查询都很慢的原因（mysql优化Analyze Table）
taisuiyu6397的博客
11-06 2388
转载 https://blog.youkuaiyun.com/e421083458/article/details/19907097 Analyze Table MySQL 的Optimizer（优化元件）在优化SQL语句时，首先需要收集一些相关信息，其中就包括表的cardinality（可以翻译为“散列程度”），它表示某个索引对应的列包含多少个不同的值——如果cardinality大大少于数据的实际散列程度，那么索引就基本失效了。 我们可以使用SHOW INDEX语句来查看索引的散列程度： SHOW INDEX FR
mysql analyze index_MYSQL优化 Analyze Table
weixin_36204513的博客
02-07 571
Analyze Table(分析表)MySQL 的Optimizer(优化元件)在优化SQL语句时，首先需要收集一些相关信息，其中就包括表的cardinality(散列程度)，它 表示某个索引对应的列包含多少个不同的值——如果cardinality大大少于数据的实际散列程度，那么索引就基本失效了。我们可以使用SHOW INDEX语句来查看索引的散列程度：SHOW INDEX FROM TABLE;...
通过Analyze Table语句来修复索引 --mysql中
dipi2338的博客
04-20 268
下面我们通过Analyze Table语句来修复索引：ANALYZE TABLE PLAYERS;SHOW INDEX FROM PLAYERS;结果是：TABLE KEY_NAME COLUMN_NAME CARDINALITY------- -------- ----------- -----------PLAYERS PRIMARY PLAYERNO 100...
【MySQL实战45讲10】MySQL为什么有时候会选错索引
RuaaaHaHa的博客
11-25 909
优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。如果使用索引 b 进行查询，那么就是扫描索引 b 的最后 50001 个值，与上面的执行过程相同，也是需要回到主键索引上取值再判断，所以需要扫描 50001 行。采样统计的时候，InnoDB 默认会选择 N 个数据页，统计这些页面上的不同值，得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数。MySQL是通过采样统计来得到索引的基数的，虽然把整张表一行行统计，可以得到精确的结果，但是代价太高了，索引选择了采样统计。
MYSQL查询优化器选错了索引怎么办
有时间就写写代码
02-22 767
使用强制指定索引。使用USE INDEX或来影响索引选择。更新表的统计信息或重建索引。优化查询结构，确保相关的列有索引。使用EXPLAIN分析查询计划，了解优化器选择索引的原因。
MySQL编程进阶之：`ANALYZE TABLE`和`OPTIMIZE TABLE`：维护数据库统计信息的常用命令。
最新发布
weixin_41455464的博客
08-18 522
使用 MySQL 的性能监控工具，例如 Performance Schema 或 Prometheus，可以监控数据库的性能指标，及时发现潜在的问题。刚买来的时候，那叫一个流畅，加速迅猛，过弯利索。有时候，即使表的数据没有变化，你也可能需要强制重新分析，以确保统计信息是最新的。的结果显示MySQL没有使用索引，或者使用了错误的索引，可能是因为统计信息不准确。别看它们名字酷炫，其实干的活儿都是默默奉献，为了让你的数据库跑得更快，更稳。命令的主要作用是整理表的数据和索引，减少碎片，并回收未使用的空间。
10.MySQL为什么有时候会选错索引？1
08-03
MySQL数据库在执行SQL查询时，会根据查询条件和表结构来选择最合适的索引，以提高查询效率。...当发现优化器选错索引时，应深入分析原因，可能需要调整统计信息、优化查询语句或者考虑更合适的数据库设计和操作策略。
MySQL之ANALYZE TABLE
热门推荐
爪哇岛咖啡种植农场
11-04 1万+
ANALYZE TABLE介绍
mysql analyze table_MySQL:Analyze table导致'waiting for table flush'
weixin_31264565的博客
02-07 410
一、问题描述问题如下：mysql> show processlist;+----+-----------------+-----------+------+---------+-------+-------------------------+----------------------------------+| Id | User | Host | db ...
mysql analyze table t与 OPTIMIZE TABLE t
weixin_44143668的博客
04-11 467
"OPTIMIZE TABLE"命令用于回收未使用的空间并对表的数据文件进行碎片整理。这可以通过减少存储开销和优化数据存储来提高表的性能。它会对表的数据存储进行物理重组，有助于提高表的性能。"ANALYZE TABLE"命令用于更新表的统计信息，这些信息可以帮助查询优化器在生成查询执行计划时做出更好的决策。它不会对表的数据存储进行物理重组或回收未使用的空间。
Mysql ANALYZE TABLE的使用
Kun_112114的博客
01-22 1575
简介：数据库使用information_schema查询表数据，部分有一条数据统计值为零的处理方式。
MySQL EXPLAIN ANALYZE
老叶茶馆
10-31 7705
本文转载自“MySQL解决方案工程师”公众号，由徐轶韬翻译作者：Norvald H. Ryeng 译：徐轶韬MySQL8.0.18刚刚发布，它包含一个全新的功能EXPL...
技术分享 | MySQL EXPLAIN ANALYZE
ActionTech的博客
10-25 647
作者：Norvald H. Ryeng  译：徐轶韬 本文转载自公众号：MySQL解决方案工程师 MySQL 8.0.18 刚刚发布，它包含一个全新的功能 EXPLAIN ANALYZE，用来分析和理解查询如何执行。**EXPLAIN ANALYZE 是什么？**EXPLAIN ANALYZE 是一个用于查询的分析工具，它向用户显示 MySQL 在查询上花费的时间以及原因。它将产生...
MySQl查询分析工具 EXPLAIN ANALYZE
vonlinee的博客
09-26 2779
摘自：https://hackmysql.com/book-2/
mysql执行计划缓存在哪_怎么去看懂mysql的执行计划
weixin_36414025的博客
02-28 220
mysql的查看执行计划的语句很简单，explain+你要执行的sql语句就OK了。举一个例子EXPLAIN SELECT * from employees where employees.gender='M'返回的结果如下： 这些结果都代表什么？id是一组数字，表示查询中执行select子句或操作表的顺序。如果id相同，则执行顺序从上至下。如果是子查询，id的序号会递增，id越大则优先级越高，越...
【MySQL】explain analyze简介
qq_38396859的博客
01-04 3662
通过主键索引(聚簇索引)扫描表，仅进行单行扫描，预计消耗0.35ms并返回1行，实际读取第一行平均花费0.084ms，返回所有行平均花费0.084ms，共循环调用该迭代器1次。：进行嵌套表连接，预计消耗0.70ms并返回1行，实际读取第一行平均花费0.085ms，返回所有行平均花费0.085ms，共循环调用该迭代器1次，返回0行。：扫描d1全表，预计消耗0.35ms并返回1行，实际读取第一行平均花费0.084ms，返回所有行平均花费0.084ms，共循环调用该迭代器1次，返回0行。
MySQL会选错索引，如何解决
03-11
<think>嗯，用户想解决MySQL查询优化器选择错误索引的问题。首先我得回忆一下MySQL是怎么选择索引的。根据引用[1]，优化器是基于成本模型来选择索引的，但有时候它可能选错，导致查询变慢。用户需要知道具体的方法和建议来纠正这种情况。 首先，可能要考虑强制使用索引。我记得FORCE INDEX或者USE INDEX可以在查询中指定索引，但用户需要知道具体的语法和适用场景。不过要提醒他们不能滥用，因为索引可能随着数据变化而不再合适。 然后，优化统计信息也很重要。ANALYZE TABLE可以更新统计信息，这可能会帮助优化器做出更好的选择。引用[3]提到key_len显示使用的键长度，统计信息不准确的话，key_len可能有问题，导致优化器误判。 接下来是调整索引结构。可能需要添加更合适的索引，或者删除冗余的，减少优化器的选择困难。比如联合索引或者覆盖索引，这样优化器可能会更倾向于使用它们。 另外，查询重写可能有效。比如将子查询改成连接查询，引用[4]中的例子就是这种情况。或者调整WHERE条件的顺序，让索引更有效。 还有优化器提示，比如像/*+ INDEX() */这样的提示，但需要确认MySQL版本是否支持。同时，调整优化器参数，比如optimizer_switch，可能会有帮助，但需要谨慎处理。 监控和分析执行计划是必须的，用EXPLAIN和EXPLAIN ANALYZE查看实际使用的索引和成本。如果发现选错，就需要进一步分析。 数据分布的问题也很关键。如果某些值的数据分布不均匀，优化器可能错误估计行数，这时候可能需要用直方图或者手动干预。 最后，极端情况下可以删除误导性的索引，或者调整隔离级别，减少锁竞争对索引选择的影响。不过这些都是最后的手段，需要测试后再实施。 用户可能需要具体的步骤，比如如何强制索引，如何分析统计信息，或者如何调整查询语句。还要考虑不同情况下的适用方法，比如数据量大的时候可能需要不同的策略。要确保建议全面且实用，同时引用相关的内容来支持每个建议。</think>### 解决 MySQL 查询优化器选择错误索引的方法和建议 #### 一、问题根源分析 MySQL 查询优化器选择索引时基于成本模型，会评估全表扫描和索引扫描的成本，选择成本最低的方式[^1]。但在以下场景可能出错： 1. **统计信息不准确**：索引的基数（Cardinality）或数据分布统计不更新，导致成本估算偏差[^3]。 2. **复杂查询条件**：涉及多列、范围查询或函数时，优化器难以准确估算过滤性。 3. **索引冗余或冲突**：存在多个候选索引时，优化器可能误判最优选择[^2]。 --- #### 二、解决方案与建议 ##### 1. **强制指定索引** 通过 `FORCE INDEX` 或 `USE INDEX` 显式指定索引： ```sql SELECT * FROM table_name FORCE INDEX (index_name) WHERE condition; ``` - **适用场景**：明确知道某个索引更优且长期稳定。 - **风险**：数据分布变化后可能失效，需定期验证。 ##### 2. **更新统计信息** 手动更新表的统计信息： ```sql ANALYZE TABLE table_name; ``` - **原理**：优化器依赖 `STATISTICS` 表中的数据分布信息，更新后可能修正成本估算。 ##### 3. **优化索引结构** - **删除冗余索引**：减少优化器的选择干扰。 - **创建覆盖索引**：包含查询所需的所有字段，减少回表操作。例如： ```sql CREATE INDEX idx_covering ON table_name (col1, col2, col3); ``` ##### 4. **查询重写优化** - **简化条件**：避免在 WHERE 子句中使用函数或复杂表达式。 - **拆分复杂查询**：将子查询转换为连接查询（如引用[4]中的优化方法）。 ##### 5. **使用优化器提示** 通过注释语法提示优化器： ```sql SELECT /*+ INDEX(table_name index_name) */ * FROM table_name WHERE condition; ``` - **注意**：需确认 MySQL 版本支持（8.0 及以上）。 ##### 6. **调整优化器参数** 修改 `optimizer_switch` 参数，关闭某些优化策略： ```sql SET optimizer_switch = 'index_merge=off'; ``` - **适用场景**：优化器错误选择索引合并（Index Merge）时。 ##### 7. **监控与验证** 使用 `EXPLAIN` 和 `EXPLAIN ANALYZE` 对比不同索引的执行计划： ```sql EXPLAIN SELECT * FROM table_name WHERE condition; ``` - **关注字段**：`possible_keys`（候选索引）、`key`（实际选择索引）、`rows`（估算扫描行数）[^3]。 ##### 8. **处理数据倾斜** - **直方图统计**（MySQL 8.0+）： ```sql ANALYZE TABLE table_name UPDATE HISTOGRAM ON column_name; ``` - **手动干预**：对分布不均的字段使用条件过滤或分片查询。 --- #### 三、关键操作流程图 ``` 更新统计信息 → 分析执行计划 → 优化索引/查询 → 验证性能提升 ``` #### 四、注意事项 - **谨慎删除索引**：先通过 `EXPLAIN` 确认索引是否被使用。 - **隔离测试**：在非生产环境验证优化效果。 - **长期监控**：数据量变化后重新评估索引策略。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值