MySQL进阶实战 3，mysql索引详解，上篇

哎哟，说起来MySQL的索引啊，那可真是数据库性能优化里的大法宝。
2 02 2 年，我在一个城市里，那会儿我就懵了，看着那一堆数据，怎么查起来这么慢。
后来我慢慢才反应过来，得用索引啊。

首先得说说B-Tree索引，这玩意儿就像一棵树，数据都按顺序排好，从根到叶子，一路比对，效率挺高。
全键值匹配、键值范围查询、前缀匹配，还有排序，它都能干。
不过不同存储引擎有差别，MyISAM和InnoDB就不一样，一个用前缀压缩，一个直接存储原格式。

这索引啊，有三个大优势：减少扫描数据量，避免额外操作，优化I/O效率。
听起来是不是很厉害？
再说说哈希索引，它就像一个哈希表，存哈希值和数据指针，查询快得不得了。
但缺点也明显，只支持等值查询，不支持范围查询，排序和分组也不行。

前缀索引呢，针对长字符串，可以节省空间。
但是，用前缀索引的时候，你得先算算全列选择性，再测试前缀长度，最后创建索引，验证效果。

索引使用啊，有几个原则：独立列，选择性优先，前缀长度权衡。
B-Tree索引是最常用的，哈希索引适合等值查询，前缀索引可以优化长字段。

总之，得结合查询模式、数据分布和存储引擎特性来设计索引。
我当时也是边学边实践，可能有点偏激，但真的，索引用得好，查询速度就能提升不少。

MySQL索引怎么用？秒懂只需四个点！

说实话，聊MySQL索引这事儿，我当年刚入行时也头大。
但摸爬滚打几年，发现它就像给数据库做"导航"，用好了能省下大把时间。
下面是我总结的几个关键点，都是实打实的踩坑经验：
索引就像图书馆的索引卡 记得第一次给客户系统加索引时，我把所有字段都加上了。
结果？写入速度掉到蜗牛爬，客户直接炸毛。
后来我才明白，索引这东西，得会挑。
就像图书馆，你要是啥都放索引卡，读者找东西反而更慢。

我看过一个电商案例，用户搜索"红色连衣裙"时，直接用LIKE '%红色%'查询，结果整个商品表被扫了一遍，2 00万条数据直接CPU飙到2 00%。
改用全文索引后，搜索响应时间从5 秒降到8 0毫秒。
这就是为啥MySQL5 .6 后才推全文索引，早年间用MyISAM引擎时，这招根本行不通。

创建索引要像做菜选调料 在employees表上创建索引时，别盲目用CREATE INDEX。
我有个项目里，给first_name加了索引，结果发现用户9 0%用last_name+department_id组合查询。
正确的做法是： sql CREATE INDEX idx_name_dept ON employees(last_name, department_id);
这就像做菜，别把所有调料都往里扔。
当时有个客户表，加了1 0个单列索引，结果写入延迟从5 0ms涨到8 00ms。
后来只保留最常用的3 个复合索引，性能直接回弹。

索引类型的选择比数量重要 有次维护客户系统时，发现他们给email列加了1 0个唯一索引。
结果？每次更新用户资料，索引重建把服务器CPU占满。
后来改成主键索引+普通索引的组合，性能提升6 0%。
记住：
普通索引：日常查询主力
唯一索引：记得加条件ON DUPLICATE KEY UPDATE
复合索引：顺序是关键！要是查询总写WHERE last_name LIKE 'Smith%'，那还不如不加索引
索引维护是持续工作 有个项目我每周用OPTIMIZE TABLE，结果客户投诉查询变慢。
后来查了信息表发现，他们表里有3 000万条记录，居然每个小时都在插入数据！这让我悟了：索引维护得看业务场景。
我建议：
大表每月优化一次
实时写入系统用在线DDL（MySQL 5 .7 +）
别用ALTER TABLE方式，太消耗资源
最绝的是有个客户，把全文索引用在了订单表上。
结果？查询"苹果"会匹配所有"苹果手机""苹果派"的订单，最后只能重建索引。
这就是为啥全文索引要加FULLTEXT前缀，别乱用！
说到底，索引就像给数据库做健身。
练多了效率高，练少了反应慢。
关键是要知道什么时候该举铁，什么时候该吃蛋白粉。