我目前正在使用用 Python 编写的 Web 应用程序（并使用 SQLAlchemy）。为了处理身份验证，应用程序首先检查会话中的用户 ID，如果它存在，则将整个用户记录从数据库中提取出来，并将其存储用于该请求的其余部分。还会运行另一个查询来检查它存储的用户的权限。
我对 Web 应用程序开发世界还很陌生，但据我了解，在每个请求上访问数据库以获取类似的东西效率不高。或者这被认为是正常的事情吗？
到目前为止，我唯一想到的就是提取这些数据一次，并存储相关的内容（甚至每个请求都不需要大多数数据）。但是，这会带来一个问题，即如果此用户记录恰好在此期间被删除，将会发生什么。关于如何最好地管理这个的任何想法？
“在每次请求时都在数据库中查找类似的东西效率不高。”
错误的。而且，您假设没有缓存，这也是错误的。
大多数 ORM 层完全能够缓存行，从而节省一些数据库查询。
大多数 RDBMS 具有广泛的缓存，从而可以非常快速地响应常见查询。
所有 ORM 层都将使用一致的 SQL，进一步帮助数据库优化重复操作。（具体来说就是缓存了SQL语句，节省了解析和规划的时间。）
“或者这被认为是正常的事情？”
真的。
在您可以证明您的查询是应用程序中最慢的部分之前，请不要担心。构建真正有效的东西。然后优化你能证明是瓶颈的部分。
对于简单Web 应用程序中的用户登录和基本权限令牌，我肯定会将其存储在基于 cookie 的会话中。确实，每个请求的几个 SELECT 根本不是什么大问题，但是如果您可以从缓存数据中执行部分/全部 Web 请求而根本没有 DB 命中，那只会增加更多的可伸缩性一个计划接收大量负载的应用程序。
在数据库上更改用户令牌的问题有两种处理方式。一个是，忽略它——对于很多用例来说，用户注销并重新登录以获得在其他地方授予的新权限并不是什么大问题（以 unix 为例）。另一个是通过一种方法过滤用户行的所有突变，该方法也重置基于 cookie 的会话中的状态，但这仅在用户他/她自己是通过浏览器界面发起更改的人时才有效。
如果 OTOH 上述用例都不适用于您，那么您可能需要坚持在每个请求中内置一点数据库访问权限。
您基本上是在谈论缓存数据作为性能优化。与往常一样，过早优化是一个坏主意。事先很难知道瓶颈在哪里，如果应用程序域对您来说是新的，则更是如此。优化增加了复杂性，如果你优化了错误的东西，你不仅浪费了精力，而且使必要的优化变得更加困难。
请求用户数据通常是一个非常简单的查询。您可以为自己构建一个简单的基准，看看它会引入什么样的开销。如果它不占您时间预算的很大一部分，那就别管它了。
如果您仍然想在应用服务器上缓存数据，那么您必须提出一个缓存失效方案。
可能的方案是检查数据库中的更改。如果您没有大量数据要缓存，那么这实际上并没有比重新加载它更有效。
另一种选择是让缓存数据超时。如果更改的即时可见性不重要，这是一个不错的选择。
另一种选择是主动使更改的缓存无效。这取决于您是否仅通过应用程序修改数据库，以及您是否有单个应用程序服务器或集群解决方案。
它是一个数据库，因此经常“点击”数据库以提取所需数据是很常见的。如果您建立联接或存储过程，您可以减少单个查询。