索引是语引查数据库加速查询的利器，但用不对反而拖慢性能。句索我见过太多人建了索引却不生效，询用或者干脆滥用索引把写入搞得奇慢无比。语引查下面直接说用法。句索

最基础的询用场景是等值查询。假设你有张用户表，语引查经常用`where user_id = 10086`来查数据。句索这时候给user_id加个普通索引，询用执行计划就会走索引扫描，语引查从全表几百万行里挑出那一行，句索速度从秒级降到毫秒级。询用写法很简单：`create index idx_user_id on 语引查user(user_id)`。查询语句不用改，句索数据库自动会选索引。询用

但索引不是万能的。有一次我排查慢查询，发现`where name like '%张三%'`这种模糊匹配，即使name上有索引也没用。因为前导通配符让数据库无法利用B+树的排序特性，只能全表扫。改成`where name like '张三%'`就能走索引了。这是很多人栽过的坑。

复合索引的顺序很关键。比如你要按`status`和`created_at`两个条件筛选订单，建索引时得把等值条件放前面，范围条件放后面。`create index idx_status_time on orders(status, created_at)`。如果你反过来建，查询`where status=1 and created_at > '2024-01-01'`时，索引只能用到status部分，created_at部分就浪费了。这个细节直接影响查询效率，我见过线上接口因为索引顺序不对，响应时间从200ms飙到3秒。

覆盖索引是优化神器。如果你查询只需要返回少数几个字段，比如只select id和name，那就建一个包含这两个字段的索引，查询时连回表都省了。`create index idx_name_id on user(name, id)`。这种情况下执行计划显示的是Using index，而不是Using index condition。别小看这个差异，高并发场景下能减少大量磁盘IO。

索引失效的情况得记牢。对索引列做函数运算会失效，比如`where date(created_at) = '2024-01-01'`，即使created_at有索引也不走。应该改成范围查询`where created_at >= '2024-01-01' and created_at < '2024-01-02'`。隐式类型转换也坑人，`where phone = 13800138000`，如果phone是varchar类型，数字会被转成字符串再比较，索引照样失效。得写成`phone = '13800138000'`。

还有联合查询里的索引利用。两个表join，连接字段必须都建索引，否则嵌套循环会变成全表对全表。我优化过一个报表查询，给关联字段补上索引后，执行时间从45秒降到0.8秒，那个开发同事当时就愣住了。

再说说排序。order by的字段如果有索引，可以避免filesort。但前提是排序方向和索引顺序一致，或者排序字段在where条件里被前导使用了。比如`where status=1 order by created_at`，如果索引是(status, created_at)，那排序直接走索引顺序，不用额外排序。要是`order by created_at, status`，索引就帮不上忙了。

最后提醒一句，索引不是越多越好。每个索引都会拖慢insert和update，因为要同步维护索引结构。我见过有人给一张表建了8个索引，结果写入性能惨不忍睹。一般单表索引控制在5个以内，把高频查询的字段组合好就够了。删除那些长期没被使用的冗余索引，用`show index from table_name`看看基数，基数太低的列比如性别字段，建索引纯属浪费空间。

实际调优时，先explain看看执行计划，type字段至少是ref或range，如果是all就得加索引。rows字段估算扫描行数，跟实际返回行数差距过大说明统计信息过期，跑一下analyze table就好。索引这东西，用对了是加速器，用错了是负担，关键还是得多看执行计划。