PostgreSQL与MySQL索引优化实战教程

本篇文章向大家介绍《Python数据库优化教程：PostgreSQL与MySQL索引实战》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

索引并非越多越好，过多低效索引会拖慢写入并占用磁盘空间；应通过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
同理，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），再针对性优化语句或补索引

今天关于《PostgreSQL与MySQL索引优化实战教程》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！