MySQL如何修改索引_MySQL索引添加、删除与优化教程

添加标签： 使用 CREATE INDEX 或 ALTER TABLE。
示例：在用户（电子邮件）上创建唯一索引 idx_email。
要删除标签： 使用 DROP INDEX 或 ALTER TABLE。
例如：对用户删除 INDEX idx_email 优化技巧： 1 . 避免对列进行操作（例如WHERE DATE(col)=...）。
2 、使用有效的索引（只有索引字段才能满足查询）。
示例： ALTER TABLE users ADD INDEX idx_id_name(id, name); 监控： 使用 SHOW INDEX FROM table_name 检查索引使用频率。
实用警告： 定期使用EXPLAIN来分析慢查询并调整索引。

【黄啊码】MySQL入门—12、优化道路千万条，优化索引了解一下？

说实话，我在MySQL索引方面遇到过很多陷阱。
这些优化建议都比较实用，但实际使用还要根据具体情况而定。
让我给你们讲一下我走进陷阱时的真实经历。
可能有点极端，但绝对是事实。

我们先来说一下约束的独特领域。
理论上可以通过创建唯一索引来完成，但是有一个真实的案例特别有趣。
我们系统中有一个用户表，它使用ID号作为唯一索引。
结果我们发现数据库多次被阻塞。
后来查看日志，发现不是并发写冲突，而是更新批次ID号的定时任务。
我当时真的很生气。
这显然违反了使用唯一索引的基本原则。
说白了，唯一索引不是随机添加的，必须检查更新操作。

高频度WHERE查询条件字段不出错。
在我之前负责的电商系统中，订单表是通过用户ID来索引的。
优化前，查询耗时1 .2 秒，添加索引后，直接变成了0.03 秒。
在这种情况下，指数效应就像作弊一样。
但有一个细节需要注意。
索引越多越好。
一个团队向我提到，他们向表中添加了十几个索引，结果，写入操作像垃圾一样卡住了。
监控显示，每次更新都会扫描整个表和所有索引。
我自己没有运行过这个，但我记得的数据是，索引数量每增加一倍，写入延迟就会增加大约 5 0%。

我在 GROUPBY/ORDERBY 函数字段中有一个特殊的词。
我们有一个报告系统，可以对日期字段建立索引，查询速度提高一倍。
但有一个问题。
如果 GROUPBY 子句是函数，则索引将为空。
比如统计查询需要GROUP BY YEAR(data_order)，这显然会让索引失效。
我调试了好久，最后发现必须把函数放在SELECT中，直接用order_date来分组。

JOIN操作优化，建议再添加一个案例。
当我接手一个项目时，该表与五个表相关联，结果查询速度慢得离谱。
分析执行计划后发现JOIN条件没有索引。
说实话，当时我很困惑。
这显然违反了最左前缀原则。
后来改成了在相应字段上添加索引，查询速度立刻提升了9 0%。
但一个教训是共享索引不能随意添加。
为了优化，团队为表中的所有字段添加了索引。
结果，写入操作速度慢了三倍。
监控显示，每次更新都会重建所有索引。

在索引失败的情况下，LIKE 查询中的前导通配符对我来说是最令人沮丧的方面。
有一个客服系统，通过输入LIKE'%王%'来搜索客户姓名，直接跨表扫描结果。
后来我把它改成了LIKE'王%'，速度变得更快了。
但有一个细节需要注意。
如果数据量特别大，这种搜索还是会很慢。
我有一个项目，有几千万的数据。
这模糊题型实际上需要1 秒多。
最后只能通过添加全文索引来完成。

在维护实践中，监控索引的效率尤为重要。
我有一个客户端系统，表中添加了十个索引，但常用的只有三个。
请求和更新结果很慢。
后来我用SHOW INDEX分析并删除了这7 个不正常的，系统性能直接翻倍。
但一个陷阱是，一些数据库优化器会自动对某些字段建立索引，从而导致冗余。
例如，在项目中，查询条件中经常使用年龄字段。
导致数据库索引增大，写操作变慢。
后来发现优化器太聪明了，把age作为单独的索引添加了，导致和其他索引冲突。
最后，唯一的选择是删除年龄索引并使用最常用字段的组合。

总的来说，索引优化不是照搬手册，应该结合实际场景。
我建议每个项目至少优化三次：第一次使用手册随机添加，第二次使用EXPLAIN分析，第三次根据业务进行调整。
说实话，这项工作很累，但结果绝对是值得的。

MySQL索引处理技巧大于等于的优化mysql大于等于索引

那天，我正在公司的小会议室里和同事讨论一个项目。
项目中有一张表，有几百万条记录。
每个问题都需要几分钟的时间，效率极低。
我打开MySQL，输入查询语句。
屏幕上出现问题的时间让我皱起了眉头——9 秒！这仍然是一个简单的问题。

“这个表上的索引是如何放置的？”我问。

“哦，我设置了主键索引。
”同事回答道。

“主键索引？”我疑惑地重复道：“你确定这是最优解吗？”
“嗯，应该没问题。
”他不确定。

我立即打开数据库并开始分析。
我检查了表结构，然后开始尝试不同的索引优化技术。
首先我尝试了模糊搜索索引，我修改了语句并添加了索引：
sql CREATE INDEX idx_name ON 表名（字段名）;
再次运行查询，时间变成了5 秒，略有改善，但还不够。

“尝试跳过索引。
”我告诉我的同事。

我们修改了索引创建语句：
sql CREATE INDEX idx_name ON 表名(field1 ,field2 ,...);
这次查询时间缩短到了2 秒，效果明显。

“那怎么样？”我自豪地问道。

“嗯，那很好。
”同事点点头。

但我还不满意，我再次尝试了 Hash:
sql 索引 CREATE INDEX idx_name ON 表名 USING HASH(fieldname);
这次查询时间直接缩短到1 秒，效率显着提升。

“这是战胜力指数。
”我告诉我的同事。

“哇，太棒了！” - 打电话给我的同事。

我笑着想，这就是科技进步的魅力。
等等，还有一件事，我突然想到，如果这个表中的数据更新得太频繁，这些索引会影响写操作的性能。
我需要重新思考如何平衡读写性能。