困顿-2026/1/31
因为每天花了太长时间与自己进行对话
逐渐地陷入到了更加紧绷的一种状态
终于我老公要回家了
我也许太注重自己的时候，就会轻易地滑道我执这个端点
无我的状态 心流的状态
应该多和事情本身产生深度链接
而不是人
数据库的可爱之举！！- 趁大家不注意记小本本
每日之想 这个行为也太可爱了吧！！👅👅👅👅 如果每次查询前，优化器都要真刀真枪地去把目录（Index）数一遍，再把表（Table）数一遍，那光是“数数”这个动作就已经慢死了，还查什么数据？ 所以，它依靠的是一份**“作弊小抄”**，专业术语叫： 数据库统计信息 (Database Statistics) 。 1. 它的“作弊小抄”里记了什么？ 数据库会定期（比如每天夜里，或者数据变动很大时）悄悄去抽查你的表，然后在一个小本本上记下这些信息： 行数 (Row Count)： 表里大概有多少行？（比如：100万行）。 区分度 (Cardinality)： 这一列大概有多少个不同的值？（比如： status 列只有 3 个值）。 分布图 (Histogram/Distribution)： 数据的分布是不均匀的吗？（比如：99% 是 False ，1% 是 True ）。 重点来了： 当你查询时，优化器 不读原表，也不读索引 ，它只是 瞄了一眼这个小本本 。 2. 它是怎么做“预计”的？（模拟计算过程） 假设你发来一条 SQL： SELECT * FROM users WHERE city = 'Beijing'; 优化器开始掐指一算： 步骤 A：看小抄 总行数： 1000 万。 city 列的统计信息： 北京的用户占比约为 5% （这是之前抽查记录下来的）。 步骤 B：算成本 (Cost Estimation) 预计行数： $1000万 \times 5\% = 50万行$ 。 方案一（走索引）： * 读取 50 万个索引节点 + 回表（随机跳跃读取）50 万次。 成本分： 假设是 500 分（回表很累）。 方案二（全表扫描）： 直接从头读到尾，顺序读 1000 万行。 成本分： 假设是 1000 分（虽然顺路，但路太长）。 步骤 C：做决定 500 < 1000， 决定走索引！ 3. 既然是“预计”，那会出错吗？ 会！而且经常出错。 这就是所谓的“统计信息过期”或者“统计信息不准”。 情况一：数据突然暴增 昨天表里只有 100 行数据，优化器觉得“全表扫描最快”。今天你突然导入了 1000 万行数据，但小本本还没来得及更新。优化器还以为只有 100 行，继续傻乎乎地用全表扫描，结果数据库直接卡死。 情况二：抽样误...
评论
发表评论