单列索引和复合索引不是“选一个就好”，而是要根据查询模式、数据分布和写入成本综合权衡。用错索引不仅不加速，还拖慢写入、浪费存储。
优先为高频过滤字段建单列索引
当某个字段经常单独出现在 WHERE 条件中（如 WHERE status = 'active' 或 WHERE user_id = 123），且选择性较好（重复值不多），单列索引就是最直接有效的选择。
- 避免为低选择性字段（如性别、开关状态）盲目建单列索引——优化器很可能不走索引，反而增加维护开销
- 对高基数字段（如手机号、订单号、邮箱）建单列索引效果通常明显
- 注意区分“常用于排序”和“常用于过滤”：仅用于 ORDER BY 但不参与 WHERE 的字段，单列索引收益有限
复合索引要严格遵循“最左前缀原则”
复合索引 (a, b, c) 可以支持 WHERE a = ?、WHERE a = ? AND b = ?、WHERE a = ? AND b = ? AND c = ?，但无法支持 WHERE b = ? 或 WHERE a = ? AND c = ?（缺少 b）。
迅易年度企业管理系统开源完整版
下载
系统功能强大、操作便捷并具有高度延续开发的内容与知识管理系统，并可集合系统强大的新闻、产品、下载、人才、留言、搜索引擎优化、等功能模块，为企业部门提供一个简单、易用、开放、可扩展的企业信息门户平台或电子商务运行平台。开发人员为脆弱页面专门设计了防刷新系统，自动阻止恶意访问和攻击；安全检查应用于每一处代码中，每个提交到系统查询语句中的变量都经过过滤，可自动屏蔽恶意攻击代码，从而全面防止SQL注入攻击
- 把等值查询字段放前面，范围查询（
>、BETWEEN、LIKE 'abc%'）字段放中间或靠后 - 如果存在
WHERE a = ? AND b > ? ORDER BY c，索引(a, b, c)可同时满足过滤与排序，避免额外排序开销 - 多个查询共用同一张表时，优先合并——比如已有
(user_id, created_at)，新查询是WHERE user_id = ? AND status = ?，可考虑扩展为(user_id, status, created_at)，而非新增单列索引
警惕冗余索引和隐式类型转换
MySQL 和 PostgreSQL 都会因隐式类型转换导致索引失效。例如字段是 VARCHAR，但查询写成 WHERE mobile = 13800138000（传入数字），数据库可能放弃索引做全表扫描。
- 检查
EXPLAIN输出中的 key 和 Extra 列，确认是否真实命中索引 - 用
SHOW INDEX FROM table_name检查是否存在功能重叠的索引，如已有(a, b)，又建了(a)——后者大概率冗余 - 联合索引中字段顺序不合理也会造成“伪冗余”，比如
(b, a)对WHERE a = ?完全无效，但容易被误认为“覆盖了 a”
写多读少场景要控制索引总数
每个索引都会在 INSERT/UPDATE/DELETE 时同步更新。一张表超过 5–6 个索引，写入延迟和锁竞争会显著上升，尤其在高并发事务中。
- 日志类、流水类表（如操作记录、支付明细）优先保证主键和核心查询路径，其他查询尽量走归档或异步聚合
- 用
information_schema.STATISTICS统计各索引的使用频次（MySQL 8.0+ 支持performance_schema.table_io_waits_summary_by_index_usage） - 定期清理长期未被使用的索引，比盲目添加更有效
