mysql的索引有哪些：适配线上开发的各类索引实操用途

前段时间接手老旧业务系统的慢查询优化，翻遍线上数据表结构、拆解数十条卡顿的慢SQL，才算真正摸清楚mysql的索引有哪些，课本上的死板分类根本不落地，能用、适配线上场景的索引类型，只有实操踩过坑才分得清。

最开始入行学数据库，一直刻板觉得MySQL索引无非就简单的两三种，写代码建表的时候也只会机械的添加基础索引，遇到页面查询加载缓慢、接口超时的问题，就无脑新增普通索引，好几次改完配置上线，不仅查询效率没半点提升，反而让数据新增、修改、删除的操作变得异常卡顿，线上还频繁出现短暂的事务阻塞问题。当时完全找不到问题根源，一味的精简SQL语句、优化查询逻辑，反复调试参数折腾了整整两天，依旧没能解决核心问题，只觉得数据库性能优化晦涩又难落地。

后来才反应过来，是索引类型完全用错了。选错索引，比不建索引的危害大得多。

线上开发最基础、优先级最高的就是主键索引，InnoDB引擎的数据表默认强制依赖这个索引，不需要手动创建，每张表只能拥有唯一一个主键索引。它依托主键字段生成结构，检索速度是所有索引里最快的，日常根据主键ID查询单条数据的请求，基本都是毫秒级响应，我做用户系统迭代时，所有核心单条数据查询，全是靠主键索引兜底，从来不会出现性能问题。

日常开发使用率最高、也是最容易被滥用的就是普通索引。它可以搭建在任意非约束字段上，允许字段为空、也允许存在重复数据，适配大部分简单的单条件查询场景。之前踩过最蠢的坑，就是给性别、状态这种基数极低、取值只有两三种的字段建普通索引，百万级数据的表里，这类索引完全不会被数据库优化器识别调用，查询依旧是全表扫描，反而会额外占用磁盘空间，还会增加数据写入、更新时的索引维护成本，折腾好久才搞明白，普通索引只适合字段取值多样、高频作为查询条件的场景。

唯一索引的使用场景很固定。

专门用于手机号、账号、身份证这类需要保证数据唯一性的字段，既可以像普通索引一样加速查询，还能强制约束字段数据不重复，从数据库层面杜绝脏数据的产生。日常做用户注册、账号绑定的业务表，我都会优先给唯一字段加这个索引，稳定性远高于普通索引。

复杂的多条件查询，必须靠联合索引支撑。之前优化订单列表查询，接口需要同时匹配用户ID、订单状态、创建时间三个条件，一开始分别给三个字段建独立普通索引，查询速度依旧卡顿。换成遵循最左前缀原则的联合索引后，多条慢查询直接被优化，多字段联合检索的效率提升特别明显。

还有低频但刚需的全文索引，专门解决长文本模糊查询的问题。普通索引完全适配不了like%%的文本检索，海量文本数据查询会超级慢，换成全文索引后，文章、备注这类长字段的模糊搜索效率会大幅提升，只是短文本字段没必要使用，纯属多余开销。

那天逐一修正完表里所有错误的索引配置，刷新监控面板，看着波动剧烈的接口响应曲线彻底趋于平稳，合上电脑的时候，楼道里的保洁阿姨已经开始打扫楼层了。