数据库索引优化与慢查询分析开发短记先看访问路径再决定是否建索引慢查询出现时最容易犯的错是看到WHERE条件就补一列索引。索引是否有用取决于过滤选择性、排序方式、回表代价和写入频率。先保存慢日志里的真实 SQL、绑定参数、执行时间和扫描行数再用同一版本的统计信息查看执行计划。对于包含user_id、status与created_at的列表查询我会分别确认三件事user_id是否足够筛选排序是否能由索引顺序满足以及SELECT *是否带来大量回表。EXPLAIN ANALYZE的实际行数与预估行数差距较大时先排查统计信息或参数分布不急着增加复合索引。索引设计也要考虑写路径。新建索引会增加插入、更新和页分裂成本对大表执行 DDL 前应确认数据库版本支持的在线能力、锁定范围和可用磁盘空间。影子库上的测试要包含典型读写混合流量而非只跑那一条慢 SQL。发布时把索引名称、SQL 版本、回滚 SQL 和观察窗口写清楚。观察查询扫描行数、锁等待、复制延迟和写入耗时。若读取变快但写入队列持续增长应暂停推广重新评估覆盖索引、分页方式或查询拆分。索引优化是一次取舍不是给表“补药”。当查询涉及租户或时间范围时样本也要覆盖冷热数据。某个用户的执行计划好看并不能代表历史分区或低选择性租户发布记录应注明这类未覆盖的边界。对于分页接口还要核对翻页深度。偏移量增大后的扫描方式可能与首页不同不能只用第一页的计划判定索引效果。必要时将读模型和写模型的目标分开评审。索引名要能表达字段顺序和用途方便后续从计划中识别命名不清会让重复索引长期留在表中。