数据库统计信息的作用
在日常使用数据库的过程中，很多人可能没太注意“统计信息”这四个字。其实它就像汽车的仪表盘，虽然不直接参与驾驶，但能告诉引擎怎么跑最省油、最快。
数据库执行一条查询时，并不是盲目地选择执行方式。比如你查一张上千万条记录的用户表，条件是“年龄大于30”。数据库需要决定：是全表扫描快，还是走索引更快？这个判断依据，很大程度上依赖于统计信息。
统计信息是什么
简单说，统计信息是数据库对表中数据分布情况的“快照”。包括表有多少行、每列不同值的数量（基数）、数据是否均匀分布、最大最小值等。这些数据通常由 ANALYZE 命令或自动任务收集。
比如一张订单表，有100万条数据，其中“支付状态”这一列只有三种值：未支付、已支付、已取消。统计信息会记录每种值的大致比例。如果“已支付”占了95%，那么当你查询“未支付”的订单时，数据库更倾向于使用索引，因为它知道结果集很小。
为什么它影响查询性能
没有准确的统计信息，数据库的执行计划可能严重偏离最优路径。想象你要从一个杂乱无章的仓库找一件货，如果仓库管理员给你的库存表是半年前的，那你大概率会走很多冤枉路。
举个例子，在一个电商后台系统中，促销活动刚结束，大量订单状态从“待发货”变成了“已发货”。如果这时没有更新统计信息，数据库可能还认为“待发货”占大多数，导致相关查询依然选择全表扫描，响应时间从0.1秒变成5秒。
通过下面命令可以手动触发统计信息更新：
ANALYZE TABLE orders;
ANALYZE TABLE users;某些数据库如 PostgreSQL 会在数据变更达到一定比例后自动执行，但频繁写入的场景下，仍建议定期手动干预。
统计信息也会影响索引策略
建索引不是越多越好，数据库优化器会根据统计信息判断某个索引是否值得用。如果某列的值几乎都一样（比如性别字段在员工表中），即使建了索引，优化器也可能忽略它，因为随机IO的成本可能比全表扫描还高。
这时候，查看执行计划（EXPLAIN）就能发现“type: ALL”或者“rows: 1000000”，说明走了全表扫描。结合统计信息检查，往往能找到性能瓶颈的根源。
实际运维中，曾遇到一个报表系统查询缓慢的问题。排查后发现，一张关键表的数据量在三个月内从10万增长到800万，但统计信息一直没更新。执行一次 ANALYZE 后，原本12秒的查询降到了0.8秒，就是因为优化器终于选对了索引路径。
所以，别小看这些“元数据”，它们默默支撑着每一次快速响应。尤其是在数据快速增长或批量导入后，记得顺手更新一下统计信息，可能就避免了一次线上故障。”,"seo_title":"数据库统计信息的作用详解 - 合普知识库","seo_description":"了解数据库统计信息的作用，如何影响查询性能和执行计划选择，提升数据库响应速度的实用指南。","keywords":"数据库统计信息, 统计信息作用, 数据库性能优化, 查询执行计划, ANALYZE TABLE, 数据库优化"}