文章目录一、高频出现在 WHERE 条件中的字段为什么适合典型例子重要补充二、JOIN 关联查询中的关联字段外键字段为什么适合典型例子注意三、ORDER BY / GROUP BY 后面的字段为什么适合典型例子补充技巧四、区分度高的字段Cardinality 大为什么适合判断标准对应你的表五、需要保证唯一性的业务字段为什么适合典型例子六、适合做「覆盖索引」的高频查询为什么适合典型例子反向补充这些情况不建议建索引新手建索引优先级参考一、高频出现在 WHERE 条件中的字段这是索引最核心、最常用的场景。为什么适合查询时如果字段没有索引就必须逐行扫描整张表全表扫描有了索引就能通过 B 树快速定位到符合条件的行数据量越大提速越明显。典型例子业务中经常按「员工姓名」「邮箱」「部门ID」查员工信息这些字段就适合建索引。对应你的employees表department_id、job_id这类经常作为筛选条件的字段建索引就是合理的。重要补充如果多个字段经常组合在一起做查询条件优先建联合索引而不是给每个字段单独建单列索引。比如经常用name age筛选建idx_name_age(name, age)的收益远高于两个单列索引。二、JOIN 关联查询中的关联字段外键字段联表查询的关联字段几乎是必建索引的场景。为什么适合两张表关联查询时比如employees JOIN departments ON employees.department_id departments.id如果关联字段没有索引每次关联匹配都要做一次全表扫描数据量上来后性能会极差。典型例子你的employees表里的department_id、job_id、manager_id都属于这类department_id关联部门表job_id关联职位表manager_id关联上级员工自连接这也是为什么你这张表的这三个字段都已经建了索引是非常标准的建法。注意关联字段的类型、长度、字符集必须完全一致否则会触发隐式类型转换导致索引失效。三、ORDER BY / GROUP BY 后面的字段排序 和 分组是索引的第二大适用场景。为什么适合B 树索引本身就是排好序的结构ORDER BY直接用索引的顺序输出不用再做「文件排序Using filesort」速度提升非常明显GROUP BY索引有序分组时不用再生成临时表Using temporary避免额外的内存/磁盘开销典型例子经常按「入职时间倒序」查询员工列表 →hire_date适合建索引经常按「部门分组统计人数」 →department_id适合建索引补充技巧如果查询同时有WHERE和ORDER BY优先建联合索引把 WHERE 字段放最左边排序字段放后面符合最左前缀原则既能过滤又能排序。比如WHERE department_id 10 ORDER BY hire_date建idx_dept_hire(department_id, hire_date)四、区分度高的字段Cardinality 大索引的效率很大程度取决于字段的「区分度」。为什么适合区分度越高索引一次能过滤掉的数据就越多查询效率提升越明显反之如果字段值大量重复索引过滤不了几行优化器会觉得还不如全表扫直接放弃索引。判断标准看SHOW INDEX里的Cardinality值值越接近表总行数区分度越好。✅ 适合邮箱、工号、身份证号几乎不重复区分度拉满❌ 不适合性别、状态只有 0/1 两种值、是否删除等低基数字段对应你的表employee_id、email基数 107和表总行数一致 → 区分度极好建索引收益最高department_id基数 12 → 区分度一般数据量小的时候还行百万级数据下收益会很低五、需要保证唯一性的业务字段业务上要求不重复的字段直接建唯一索引一举两得。为什么适合数据约束由数据库层面保证字段值不重复比代码判断更可靠能避免并发导致的重复数据查询加速唯一索引同时具备普通索引的所有加速能力等值查询性能极高典型例子员工邮箱、工号、身份证号对应你表里的emp_email_uk就是非常标准的唯一索引设计六、适合做「覆盖索引」的高频查询这是进阶优化场景用得好性能提升非常显著。为什么适合如果一条查询要取的字段在索引里就全部包含了就不需要回表去聚簇索引里查完整数据直接从二级索引里就能拿到结果这就是覆盖索引省去了回表的IO开销。典型例子业务高频执行SELECTname,ageFROMemployeesWHEREname张三;建联合索引idx_name_age(name, age)查询时直接从索引里取 name 和 age完全不用回表性能接近主键查询。反向补充这些情况不建议建索引知道什么时候建也要知道什么时候别乱建数据量很小的表几百几千行全表扫描比走索引还快建了反而浪费空间写操作远多于读操作的表增删改都要维护索引会大幅拖慢写入性能区分度极低的字段如性别、状态索引收益几乎为0频繁更新的字段索引维护成本很高冗余、重复的索引比如你表里的emp_emp_id_pk和主键索引完全重复纯纯浪费空间新手建索引优先级参考按重要性从高到低主键自动创建不用管业务唯一键 → 建唯一索引所有 JOIN 关联字段 → 建普通索引高频出现在 WHERE 中的字段 → 按需建单列/联合索引经常排序、分组的字段 → 结合 WHERE 建联合索引高频慢查询 → 用覆盖索引做专项优化
郑州网站建设
网页设计
企业官网
![2026论文查重避坑指南[特殊字符]90%毕业生都会踩的隐形重复坑](http://pic.xiahunao.cn/yaotu/2026论文查重避坑指南[特殊字符]90%毕业生都会踩的隐形重复坑)
)
