<分区>
我正在设计一个在 SQL Server 中包含 400 多个表的会计应用程序。
这些表中大约有 10% 是操作表，其他表用于解码和引用信息。
例如，Invoice 表(Master 和 details)使用大约 10 个表来解码信息，例如 buyer、item、marketer 和...。
我想知道在 asp.net 缓存中缓存解码表并且不从 SQL Server 查询它们是否可以接受(我知道对缓存项的更改也应该在 SQL Server 上提交)。并使用缓存项进行解码？
我认为它比常规应用程序快得多。
也许几年后它们加起来(缓存表)大约是 500 MB，因为它们不经常更改。
最佳答案
如果您有 RAM，那么使用 500 MB 就可以了。
但是，除非您现在遇到性能问题，否则缓存只会导致问题。不要修复您没有遇到过的问题，针对性能进行设计并仅在您遇到问题时进行优化 - 因为否则优化可能会导致更多它已解决的问题。
因此，我建议通常最好确保您的查询经过优化且结构良好，您在表上拥有正确的索引，并且您发出的查询数量最少。
虽然 500MB 的缓存数据不是很多，但恕我直言，通常 SQL Server 的缓存工作会比您做得更好——前提是您正确使用它。
使用缓存总是会提高性能；以更高的实现复杂性为代价。
对于永不改变的静态数据，缓存很有用；但它仍然需要在线程之间加载和共享，这本身就存在挑战。
对于很少改变的数据，它变得更加复杂，仅仅是因为它可能已经改变了。如果单个应用程序(进程)是缓存的唯一更新程序，那么它并不那么困难，但仍然不是一项简单的任务。
我花了几个月的时间来优化一个离线批处理系统(代码可以在 12 小时内完全控制数据库)。部分优化是使用各种缓存和数据重新投影。所有缓存都是只读的。执行期间内存使用量约为 10gb，数据库约为 170gb，6000 万条记录。
即使使用缓存，底层架构也发生了相当大的变化以提高效率。只读缓存是为了消除处理过程中的读取；允许多线程处理并提高插入性能。
处理速度已从 20 个月前每秒处理 6 个项目增加到每秒约 6000 个项目(昨天)- 但随着要处理的项目数量从 100,000 增加到 800 万，确实需要进行此优化同期。
如果您没有需求，那么就不要优化。
关于c# - 在 .Net 中缓存大量数据是否可以接受？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33980239/