mysql添加索引反而速度变慢

最新推荐文章于 2025-06-23 15:35:04 发布

原创最新推荐文章于 2025-06-23 15:35:04 发布 · 1.9k 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#sql #mysql

本文探讨了导致数据库索引失效的几种情况，包括使用'in'、'not in'操作符，OR条件下的索引选择，非最左前缀索引，LIKE模糊匹配百分号使用，函数和表达式计算，以及字段类型不匹配等。了解这些情况有助于优化数据库查询性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

索引失效几种情况

1.使用in、not in，会导致索引失效

失效的原因和 Mysql 的版本以及表中的数据量有关系，在 8.0 之后的版本是走索引的

2.or 分割的条件，如果 or 左边的条件存在索引，而右边的条件没有索引，不走索引

因为 OR 的含义就是两个只要满足一个即可，因此只有一个条件列进行了索引是没有意义的，只要有条件列没有进行索引，就会进行全表扫描，因此索引的条件列也会失效。

3.索引字段不是联合索引字段的最左字段

4.like 使用了 ‘%’模糊匹配

5.被索引字段使用了内置函数

使用了SUM(), MIN(), MAX(), COUNT(), and so forth

6.被索引字段使用了表达式计算

7.字段类型不匹配导致的索引失效

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

Aoeding

关注关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

MySQL设置了索引可还是很慢怎么分析并解决

longgelaile的博客

02-17

1099

查询未能有效利用索引，或者索引设计不合理。数据量过大，导致查询慢。数据库配置不当，缓存、内存不足，导致查询性能差。查询语句设计不合理，导致不必要的计算或数据加载。使用EXPLAIN分析查询执行计划，确认是否使用了索引。优化索引设计，确保索引适合查询条件。使用覆盖索引减少回表，优化查询性能。优化数据库配置，增加缓存和连接池。使用分区、数据归档等方式处理大数据量。通过硬件优化提升查询性能，尤其是在高并发场景下。

mysql 索引变慢_mysql添加索引，查询反而变慢

weixin_31900373的博客

02-18

3297

1.表结构，time1添加普通索引：CREATE TABLE `time_table` (`time1` INT(11) NULL DEFAULT NULL,`time2` INT(11) NULL DEFAULT NULL,INDEX `time1` (`time1`))ENGINE=MyISAM;2.蠕虫复制创建200万条数据insert into time_table select * fr...

参与评论您还未登录，请先登录后发表或查看评论

mysql加了索引为什么还很慢

A_qsmy的博客

07-26

1658

虽然索引可以提高查询速度，但过多的索引会降低写操作的性能，并增加存储空间的需求。同时，MySQL在查询时需要评估所有索引，过多的索引可能会导致查询优化器选择错误的执行计划。：查询语句可能没有按照索引的方式来执行，比如使用了函数、计算或者连接条件不正确，导致MySQL无法利用已有的索引。：如果查询的列没有全部被索引覆盖，MySQL可能需要额外的查找来获取其他列的数据，这会增加查询的时间。：如果索引列的数据分布非常不均匀，比如某个值占据了大部分的行，那么索引的效果会大打折扣。

mysql索引问题，查详细数据，为什么走索引速度反而更慢

David_bdqn的博客

01-08

2070

like模糊搜索前通配（like ‘%name’ ）不走索引，而后通配走索引（like ‘name%’ ），进行测试，过程如下：准备数据：使用python在window10机器上的mysql插入1000万条数据，表结构如下：针对content字段建索引字段值很小，content不超过4个汉子，如下: 场景：1、统计数据量：索引加块了统计速度 select count(1) from test_index where content like '%群众%'; 执行时间48...

Mysql 建立索引之后反而变慢（已解决）

最新发布

🚩 Flag：今年绝不写屎山代码（去年也是这么说的）

06-23

827

在MySQL的性能优化中，索引是最常用且有效的手段之一。但“索引不是万能药”——盲目添加索引可能导致写操作变慢、存储空间浪费，甚至引发索引失效问题。

MySQL面试题--最全面-索引

Timebro的博客

03-21

3432

自适应哈希索引是Innodb引擎的一个特殊功能，当它注意到某些索引值被使用的非常频繁时，会在内存中基于B-Tree所有之上再创建一个哈希索引，这就让B-Tree索引也具有哈希索引的一些优点，比如快速哈希查找。这是一个完全自动的内部行为，用户无法控制或配置。使用命令：查看INSERT BUFFER AND ADAPTIVE HASH INDEX；多叉树（multiway tree）允许每个节点可以有更多的数据项和更多的子节点。2-3树，2-3-4树就是多叉树，多叉树通过。

MySQL 之INDEX 索引（Index Index of MySQL）

Linux运维老纪的博客

02-15

2161

在MySQL中，INDEX 关键字用于创建索引，以提高数据库表中数据的检索速度。索引是数据库管理系统中一个常用的概念，用于快速定位数据。在英语中，INDEX 直接翻译为“索引”。本章详细介绍mysql之INDEX索引。

玩转MySQL：如何正确应用索引

Java_LingFeng的博客

11-05

2502

至此，MySQL索引应用篇，也就是索引中篇就结束了，相信大家认真看完本篇之后，对于索引的掌握性、熟练程度绝对会更上一层楼，因为本章中从索引的优劣分析，到建立索引的原则、索引失效的情景、使用索引的正确姿势、MySQL对于索引的优化机制等各方面，对索引进行了进一步阐述。

mysql索引添加缓慢_mysql 中创建索引很慢，怎么解决

weixin_30806145的博客

01-18

7243

引用如题，我现在有一张表。。。里面的数据大概就是 800w 条左右，当然以后也可能会更多，这个表会频繁的更新！我现在的处理是：每次更新都会先truncate 这张表(因为里面的数据已经不需要了)，然后我会 drop index ！这样之后我会去 insert 数据。。。。(这些数据量有可能过千万。。级别的) ，之后就是为数据建立索引！建立索引的过程很慢。。。800w 数据现在执行了半...

MySQL用了索引还是慢？这几种场景你避坑了吗？

qq_45438032的博客

02-10

1286

这篇文章详细介绍了 Mysql 索引失效的场景，并给出了解决方案和注意事项

数据库中 SQL 语句使用索引，还是很慢？可能是这几点原因

2401_83915812的博客

04-12

890

3）索引过滤性不好；4）频繁回表的开销。那如果我们在更深层次的看这个问题，其实他还潜藏了一个问题需要澄清，就是什么叫做使用了索引。我们都知道，InnoDB是索引组织表，所有的数据都是存储在索引树上面的。比如上面的表t，这个表包含了两个索引，一个主键索引和一个普通索引。在InnoDB里，数据是放在主键索引里的。

为什么使用了索引，查询还是慢

Jmayday

01-15

1105

经常有同学问我，我的一个SQL语句使用了索引，为什么还是会进入到慢查询之中呢？今天我们就从这个问题开始来聊一聊索引和慢查询。另外插入一个题外话，个人认为团队要合理的使用ORM，可以参考ORM的权衡和抉择(http://rrd.me/f9jCg)。合理利用的是ORM在面向对象和写操作方面的优势，避免联合查询上可能产生的坑(当然如果你的Linq查询能力很强另当别论)，因为ORM屏蔽了太...

mysql 添加索引慢_你写的Sql为什么那么慢？你的mysql索引为什么失效了？

jj1130050965的博客

01-24

1799

文章来自：php自学中心链接：http://www.startphp.cn/front/sql/0225147.html 作者：fengzi 商务合作:请加微信(QQ)：2230304070 视频教程推荐以下视频教程的网址：http://blog.startphp.cn 已经更改为：http://www.mano100.cn 请知悉！ 1Restful接口开发实战教程(18集) 2 最全Go语言教程零基础入门到进阶实战 3 Golang语言快速上手到综合实战高并发聊天室 ...

为何加索引后反而更慢

luckyman100的专栏

06-22

9024

一个大表（约3千万数据量）有个status字段，只有不同的几个值。我在这个字段加了索引，结果执行计划仍是全表扫描，但是执行时间比之前没加索引的全表扫描更加慢了！！！这是为什么了，执行计划没有用到索引而是全表扫描，这个好理解，因为status上不同值占总数据量的比列很小，用索引显然是需要更高的代价，所以选择了全表扫描。。。。这里同样的是全表扫描，加索引后更加慢的原因，我是这样理解的：因为加了索引

mysql查询速度慢(创建索引解决)

小橙子的博客

01-24

826

每个表的数据上万条，使用left join很慢，一直查不出来。通过查询大量资料，尝试给所需要的字段设置成索引，速度立马就上来了。

Mysql索引慢解决

爱喝星冰乐的博客

06-01

768

type：访问类型排序system>const>eq_ref>ref>range>index>All。eq_ref：唯一性索引扫描，对每一个索引键，表中只有一条记录与之对应，常见于主键或唯一索引扫描。（衍生）是FROM列表中包含的子查询，Mysql会递归这些子查询，结果存放在临时表中；都存在时，id相同理解为一组，从上往下顺序执行，所有组中，id值越大优先级越高。id不同，如果是子查询id序号会递增，id值越大优先级越高；index：从索引树中遍历，和all都是读全表，但all是从硬盘读取。

mysql加索引，数据库卡死

6个日的博客

06-06

2055

公司的一个内部项目，由于突然导入了几十万的数据，数据量翻了一倍，导致了某个页面打开很慢。通过sql日志看到主要是由于慢查询引起的，通过explain这个sql，发现主要是由于这个SQL没有命中索引，进行了全表扫描，慢是肯定了的。还好有show processlist，可以查看哪些线程正在执行，也可以查看锁表的线程。但是面对增加索引，突然页面就在那转，感觉卡死，而且表也不能使用。加索引要考虑，1是不是已经有很多索引，不然写入表后，写入会变慢。果然，杀死了，这张表立马就可以用了。

请告诉我mysql如何对索引进行优化

03-18

<think>嗯，用户问的是MySQL如何对索引进行优化。首先，我需要回忆一下索引优化的各种方法。索引优化是数据库性能调优的重要部分，正确的索引可以显著提升查询速度，但设计不当的索引反而会影响性能。首先，应该考虑选择合适的索引类型。比如，B-Tree索引适用于大多数情况，尤其是范围查询。而全文索引适用于文本搜索，空间索引处理地理数据，哈希索引则适合等值查询。用户可能需要根据不同的场景选择合适的类型。接下来，覆盖索引的概念很重要。如果查询只需要索引中的字段，就可以避免回表，减少I/O操作。比如SELECT id, name FROM users WHERE age=25，如果索引包含(age, name, id)，就能直接使用索引返回结果，不需要访问数据行。索引列的顺序也很关键，最左前缀原则决定了索引的使用情况。比如复合索引(a,b,c)，查询条件中必须包含a才能有效使用这个索引。如果用户经常用a和b作为条件，那么索引的顺序应该按查询频率和选择性来排列，选择性高的列放在前面可能更好。避免冗余索引也很重要，比如已经有了(a,b)索引，再创建(a)就是多余的，因为最左前缀已经覆盖了。需要检查现有索引是否有重叠，删除不必要的可以减少存储和维护开销。索引选择性是指索引列不同值的比例，高选择性的列（比如唯一ID）更适合作为索引。低选择性的列（比如性别）建立索引效果不大，可能全表扫描更快。这里可能需要用计算公式：选择性=不同值的数量/总行数，值越高越好。还有，对于长字符串列使用前缀索引，可以减少索引大小，提升效率。比如ALTER TABLE users ADD INDEX idx_name(name(10))，只索引前10个字符。不过需要平衡前缀长度和选择性，避免重复太多。另外，索引下推是MySQL5.6后的优化，可以在存储引擎层过滤数据，减少回表次数。比如WHERE a=1 AND b=2，索引是(a,b)，存储引擎会直接过滤a和b，而不是先回表再过滤。定期分析慢查询日志，找出执行效率低的SQL，用EXPLAIN分析执行计划，查看是否用到了合适的索引。如果发现全表扫描或者临时表，可能需要增加或调整索引。还有，索引列不要参与运算或函数，否则无法使用索引。比如WHERE YEAR(create_time)=2023应该改为范围查询，而不是使用函数。对于排序和分组操作，如果ORDER BY或GROUP BY的列有索引，可以避免filesort。需要确保排序顺序和索引一致，或者考虑覆盖索引。主键索引使用自增ID可以避免页分裂，提升写入性能。而UUID这类随机值会导致插入效率下降，因为数据页需要频繁调整。最后，定期维护索引，删除未使用的，重建碎片化的索引，比如使用OPTIMIZE TABLE。同时监控索引的使用情况，通过performance_schema或SHOW INDEX来查看索引的选择性和使用频率。总结的时候，可能需要分点列出，结构清晰，让用户容易理解。还要注意用户可能遇到的常见问题，比如索引失效的情况，如何选择复合索引的顺序，如何分析慢查询等。可能用户的实际场景中有不同的数据量和查询模式，需要根据具体情况调整优化策略。比如OLTP系统和高并发的写入，可能需要更谨慎地添加索引，避免写操作变慢。而读多写少的系统可以适当增加索引提升查询速度。</think>MySQL索引优化是提升查询性能的关键手段，需结合数据结构、查询模式和索引特性进行综合设计。以下是分步骤的优化策略： --- ### 一、索引设计原则 1. **选择合适索引类型** - **B-Tree索引**：默认类型，支持范围查询（`>`、`<`、`BETWEEN`）和排序。 - **全文索引（FULLTEXT）**：针对文本内容的模糊查询（`MATCH...AGAINST`）。 - **哈希索引**：仅支持等值查询（`=`），内存表默认索引。 - **空间索引（SPATIAL）**：地理数据查询。 2. **覆盖索引（Covering Index）** - 索引包含查询所需所有字段时，避免回表操作。 - 示例： ```sql -- 索引 (age, name) SELECT name FROM users WHERE age = 25; ``` --- ### 二、索引优化策略 1. **复合索引的最左前缀原则** - 索引 `(a, b, c)` 可支持 `WHERE a=1`、`WHERE a=1 AND b=2`，但无法支持 `WHERE b=2`。 - **选择性高的列放左侧**：区分度高的列（如用户ID）优先。 2. **避免冗余索引** - 已有 `(a, b)` 时，单独创建 `(a)` 是冗余的。 3. **索引列不参与计算** - **错误写法**：`WHERE YEAR(create_time) = 2023` - **优化写法**：`WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'` 4. **利用索引下推（Index Condition Pushdown, ICP）** - MySQL 5.6+ 支持，在存储引擎层过滤数据。 ```sql -- 索引 (a, b) SELECT * FROM table WHERE a = 1 AND b > 10; ``` --- ### 三、索引使用监控 1. **通过 `EXPLAIN` 分析执行计划** - 关注 `key`（使用索引）、`rows`（扫描行数）、`Extra`（是否出现 `Using filesort` 或 `Using temporary`）。 2. **慢查询日志分析** - 启用慢查询日志，定位低效SQL： ```sql SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2; -- 超过2秒的查询 ``` --- ### 四、常见优化场景 1. **排序和分组优化** - 对 `ORDER BY` 或 `GROUP BY` 字段建索引，避免 `filesort`。 - 示例： ```sql -- 索引 (age) SELECT * FROM users ORDER BY age; ``` 2. **前缀索引（Prefix Index）** - 针对长字符串（如VARCHAR(255)），节省存储空间： ```sql ALTER TABLE users ADD INDEX idx_email(email(10)); ``` 3. **索引选择性计算** - 公式：`选择性 = COUNT(DISTINCT column) / COUNT(*)` - 选择性 > 0.1 时适合建索引。 --- ### 五、维护与注意事项 1. **定期重建索引** - 删除碎片化索引： ```sql ALTER TABLE table_name ENGINE=InnoDB; -- 重建表 OPTIMIZE TABLE table_name; -- 优化表 ``` 2. **避免过多索引** - 单表索引数量建议不超过5个，过多索引会降低写入性能。 3. **主键设计** - 使用自增整型主键，避免页分裂。 --- ### 六、示例：复合索引优化 ```sql -- 原始查询（未优化） SELECT * FROM orders WHERE user_id = 100 AND status = 'paid' ORDER BY create_time DESC; -- 优化步骤： -- 1. 创建复合索引 (user_id, status, create_time) ALTER TABLE orders ADD INDEX idx_user_status_time(user_id, status, create_time); ``` --- 通过以上策略，可显著提升查询性能，但需结合实际业务场景和数据分布进行调整。建议通过监控工具（如Percona Toolkit）持续分析索引有效性。