储存年龄有意义吗
不。
我不必计算每个年龄的飞行和浪费cpu资源？
事实上，每天的更新方法会浪费更多的“cpu资源”（其中你的想法太模糊了，不必担心）。
有没有更好的方法来完成这一切？
存储出生日期并计算选定时间的年龄
如果你想找出所有年龄在25岁以上30岁以下的人呢？
这是一个非常琐碎的问题

WHERE birth_date BETWEEN date_sub(curdate(), INTERVAL 25 YEAR) 
                     AND date_sub(curdate(), INTERVAL 30 YEAR)

查询将使用索引（如果有的话），因此速度非常快，没有任何[不必要的]非规范化

简单的答案是不要；千万不要把人藏起来。它每年都会为每个人而改变，但正如你所说的，你必须检查它是否适合每个人每天。
只存储出生日期，然后从数据库中选择时计算年龄。只是 today - date of birth 所以几乎不需要CPU。
编辑：
我在曼苏克的回答中的评论也有失败的可能性。如果服务器/数据库关闭，会发生什么情况？或者更新无法在指定的时间运行？或者有人来手动运行更新后，已经运行了该日期？或者有人关闭了你的计划？如果你计算一下，就不会有这样的危险 Age 从数据库中选择。
选择年龄在25到30岁之间的位置，并假设有一个日期列 dateofbirth 您的查询类似于：

select *
  from users
 where dateofbirth between date_add( curdate(), interval -30 year )
                       and date_add( curdate(), interval -25 year )

确保 users 索引在 dateofbirth .

我要反对大多数人的答案。
我会把它们都储存起来。。。
更新年龄是快速和简单的-一个单一的mysql查询可以每天运行和完成它
当你有很多页面浏览量的时候，计算年龄是很费时的——浏览的次数远远超过了修改的次数
想象一下一个表格场景-一个有100或1000行的表格，显示一个人的年龄。。。这要花多长时间来计算？？？
我一直认为stackoverflow是动态计算信誉的，但是你可以在stackoverflow数据资源管理器上看到，他们没有看到右边模式中的用户对象。它的记录和更新，每次它的变化-我想这纯粹是因为它的浏览次数远远超过了变化的数量

我不认为计算时代动态地占用大量内存是完全正确的。为什么不为一年中的每一天创建一个365行的日历呢。并存储一个对应于他们生日的userid列表。对于每一天，只需引用该天的表条目，并只刷新那些选定用户的年龄。这将大大降低复杂性，即使用户基数增加。

不，不存储年龄，只在查询中计算年龄。至于生日，我更喜欢所有的日期/时间都用unix时间戳（因为我不喜欢处理跨日期格式的可移植性和更改区域设置）