我正在开发一个需要用户表的快速项目，我希望他们能够存储配置文件数据。当我意识到用户永远只有一个配置文件时，我已经开始使用 ASP.NET 配置文件提供程序了。
我意识到频繁更改数据会影响诸如索引和其他内容的性能，但频率太频繁了？
如果我每个用户每个月有一次个人资料更改，比如说 1000 个用户，那是不是很多？
或者我们所说的更像是用户每小时更改个人资料数据？
我意识到这不是一门精确的科学，但我正试图衡量阈值在什么时候开始达到峰值，并且因为如果我应该打扰额外的工作或等待几十年，我的用户个人资料数据可能很少会改变成为一个问题。
要考虑的一件事是向表中添加大文本列将如何影响行的布局。一些数据库将存储与其他固定大小列内联的大列；这将使行的大小可变，这意味着当数据库需要从磁盘中拉出一行时，它需要做更多的工作。其他数据库（如 PostgreSQL）将大文本列存储在固定大小的列之外；这导致在表扫描等期间可以快速访问固定大小的行，但需要额外的工作来提取文本列。
就数据库而言，1000 个用户并不算多，因此可能无需担心任何一种方式。OTOH，小的一次性项目有一个讨厌的习惯，当你不希望从一开始就这样做时，它会变成真正的关键任务项目是一个好主意。
我认为 Justin Cave 已经很好地涵盖了索引问题。
只要您正确构建数据访问（即对用户表的所有访问都通过一堆孤立的代码），那么为用户更改数据模式无论如何都不会做太多工作。
档案信息真的需要被索引吗？还是您只是要根据USER_ID表或其他索引USER列来检索它？如果配置文件数据没有被索引，这在我看来很可能，那么对表上的其他索引没有性能影响。
我能想到的担心将配置文件信息放入表中的唯一原因是，与定义用户的必要信息相比是否存在大量数据，以及是否USER出于某种原因需要对表进行全面扫描。在这种情况下，增加表的大小会对表扫描的性能产生不利影响。假设您没有定期对USERS表进行全面扫描的用例，并且鉴于该表只有 1000 行，这可能没什么大不了的。