索引并非越多越好，过多低效索引会拖慢写入并占用磁盘空间；应通过EXPLAIN确认索引是否被实际使用，未被使用的索引应及时删除；复合索引需遵循最左前缀原则，等值字段在前、范围字段居中、排序字段靠右；避免对索引字段使用函数，否则导致索引失效。
索引不是加得越多越好
在 PostgreSQL 或 MySQL 中，索引能加速查询，但也会拖慢写入（INSERT/UPDATE/DELETE）并占用磁盘空间。一张表上存在大量低效索引，反而会降低整体性能。判断一个索引是否有效，关键看它是否被查询实际使用——可通过 EXPLAIN 命令查看执行计划。如果某索引在多个常用查询中从未出现在 Index Scan 或 Index Only Scan（PostgreSQL）或 type=ref/range（MySQL）里，就该考虑删除。
复合索引要按“最左前缀”和查询模式排序
例如，你常查 WHERE status = 'active' AND created_at > '2024-01-01' ORDER BY updated_at DESC，那么推荐建立复合索引：
PostgreSQL：CREATE INDEX idx_status_created_updated ON orders (status, created_at, updated_at DESC);
MySQL：CREATE INDEX idx_status_created_updated ON orders (status, created_at, updated_at);
注意顺序：等值条件字段（status）放最左，范围查询字段（created_at）居中，排序字段（updated_at）靠右。若把 updated_at 放第一位，这个索引对上述 WHERE 条件基本无效。
避免在 WHERE 子句中对字段做函数操作
比如写成 WHERE DATE(created_at) = '2024-06-01'，即使 created_at 有索引，数据库也无法直接走索引扫描，只能全表扫描后计算。应改写为范围查询：WHERE created_at >= '2024-06-01' AND created_at <br>
同理，<code>WHERE UPPER(name) = 'JOHN' 应改为添加函数索引（PostgreSQL 支持 CREATE INDEX ON users ((UPPER(name)));），或在应用层统一大小写存储。
定期分析与监控真实慢查询
光靠经验设计索引不够，必须结合生产环境的实际负载：
- PostgreSQL：开启
log_min_duration_statement = 1000，配合pg_stat_statements扩展，找出调用频次高、平均耗时长的 SQL - MySQL：启用慢查询日志（
slow_query_log = ON，long_query_time = 1），用mysqldumpslow或pt-query-digest分析 - 对高频慢查询，先 EXPLAIN 看是否走了索引、是否触发临时表或文件排序（
Using filesort/Using temporary），再针对性优化语句或补索引
