在全动态和重数据库网站中使用memcached好吗？
Is it good to use memcached in fully dynamic and heavy database website?
我目前正在从事类似于电子商务网站的项目。数据库 tables 中有数十万条记录。我还必须对它们使用连接操作来获取数据，因为项目中有 query builder 到 select 数据标准。获取数据需要太多时间。所以，我使用限制作为每页的一些记录（例如 10）。现在我开始了解memcached的概念。所以我想在我的项目中使用 memcached，因为它只需要花费太多时间。但还是有些疑惑。
- 缓存文件太多会不会有影响？我的意思是会创建太多文件每个模块的每一页，将有一个缓存文件。所以数字将约为 10000 个缓存文件.
- 假设没有任何文件数量的问题。但是，当 table 的任何行被添加或从 table 的中间删除时，使用 replace() 更新文件 怎么办？在这里，table 几乎每周更新一次。
所以我进退两难，我是否应该选择 memcached？如果哪位大神能指点一下并解释一下，不胜感激
如果您的网站执行许多相同的 MySQL 查询，这些查询经常 return 相同的数据，那么是的，运行ning memcached 可能有一些好处。
问题：
"There are hundreds of thousands of records...It takes too much time to fetch the data".
这可能表明您的架构存在问题。正确索引，即使在使用 JOIN 时，查询也应该能够快速执行（< 0.1 秒）。 运行 EXPLAIN 对花费很长时间的查询的查询运行，看看是否可以改进。
问题 1 的答案
缓存文件过多不会有问题。 Memcached 将所有缓存信息存储在内存中（因此得名），因此不使用磁盘文件。缓存的对象存储在 RAM 中并直接从 RAM 访问。
问题 2 的答案
不太确定你在这里问什么，但如果你的应用程序更新或删除数据库中的信息，那么删除受更新和删除影响的缓存项是至关重要的。如果应用程序不删除受此类操作影响的缓存项，则下次查询数据时，不再有效的缓存结果可能会被 returned。确保缓存的任何数据都设置了适当的过期时间，或者应用程序在数据库中的数据更改时将它们从缓存中删除。
希望对您有所帮助。
我不会从 Memcached 开始，而是从找出瓶颈是什么开始。您的表大约有一百万行。我不知道一行的大小，但我有根据的猜测是它小于 1K，这是基于浏览器 window 容纳来自一条记录的信息这一事实。
所以你的数据库中大概有1G的信息。如果我错了纠正我。如果这是真的，那么整个数据库应该通过 MySQL.
自动缓存在 RAM 中
既然你的数据库完全在 RAM 中，那么通过适当组织索引，查询的复杂性应该与结果集的数量成线性关系，结果集的数量以千字节为单位，因为它适合浏览器 window.
所以我的建议是确定数据库的大小并查看 "top" 命令的结果，以便了解 MySQL 消耗了多少内存。如果您确保您的数据库完全位于内存中，那么 运行 针对您最常用的查询执行解释命令，并根据解释的结果向您的数据库添加一些索引。即使您的数据库大于 RAM 的数量，我仍然建议您查看解释命令的结果，因为它确实有很大帮助。
我目前正在从事类似于电子商务网站的项目。数据库 tables 中有数十万条记录。我还必须对它们使用连接操作来获取数据，因为项目中有 query builder 到 select 数据标准。获取数据需要太多时间。所以，我使用限制作为每页的一些记录（例如 10）。现在我开始了解memcached的概念。所以我想在我的项目中使用 memcached，因为它只需要花费太多时间。但还是有些疑惑。
- 缓存文件太多会不会有影响？我的意思是会创建太多文件每个模块的每一页，将有一个缓存文件。所以数字将约为 10000 个缓存文件.
- 假设没有任何文件数量的问题。但是，当 table 的任何行被添加或从 table 的中间删除时，使用 replace() 更新文件 怎么办？在这里，table 几乎每周更新一次。
所以我进退两难，我是否应该选择 memcached？如果哪位大神能指点一下并解释一下，不胜感激
如果您的网站执行许多相同的 MySQL 查询，这些查询经常 return 相同的数据，那么是的，运行ning memcached 可能有一些好处。
问题：
"There are hundreds of thousands of records...It takes too much time to fetch the data".
这可能表明您的架构存在问题。正确索引，即使在使用 JOIN 时，查询也应该能够快速执行（< 0.1 秒）。 运行 EXPLAIN 对花费很长时间的查询的查询运行，看看是否可以改进。
问题 1 的答案
缓存文件过多不会有问题。 Memcached 将所有缓存信息存储在内存中（因此得名），因此不使用磁盘文件。缓存的对象存储在 RAM 中并直接从 RAM 访问。
问题 2 的答案
不太确定你在这里问什么，但如果你的应用程序更新或删除数据库中的信息，那么删除受更新和删除影响的缓存项是至关重要的。如果应用程序不删除受此类操作影响的缓存项，则下次查询数据时，不再有效的缓存结果可能会被 returned。确保缓存的任何数据都设置了适当的过期时间，或者应用程序在数据库中的数据更改时将它们从缓存中删除。
希望对您有所帮助。
我不会从 Memcached 开始，而是从找出瓶颈是什么开始。您的表大约有一百万行。我不知道一行的大小，但我有根据的猜测是它小于 1K，这是基于浏览器 window 容纳来自一条记录的信息这一事实。
所以你的数据库中大概有1G的信息。如果我错了纠正我。如果这是真的，那么整个数据库应该通过 MySQL.
自动缓存在 RAM 中既然你的数据库完全在 RAM 中，那么通过适当组织索引，查询的复杂性应该与结果集的数量成线性关系，结果集的数量以千字节为单位，因为它适合浏览器 window.
所以我的建议是确定数据库的大小并查看 "top" 命令的结果，以便了解 MySQL 消耗了多少内存。如果您确保您的数据库完全位于内存中，那么 运行 针对您最常用的查询执行解释命令，并根据解释的结果向您的数据库添加一些索引。即使您的数据库大于 RAM 的数量，我仍然建议您查看解释命令的结果，因为它确实有很大帮助。