基本上，我们的销售人员会请求潜在客户调用。现在，它尝试通过“新线索”查询来获取这些信息。
如果没有任何新的潜在客户，它会继续进行“相对较新”的查询。我们将这些称为“来源”，本质上，更接近者将遍历来源，直到找到可行的线索。
这些查询都是查询同一张表，只是不同组的数据。但是，每个查询以及在查询和插入/更新表(表是 InnoDB)之间有很多复杂的排序，我们经历了很多等待(我很确定没有死锁，因为它们没有显示在 InnoDB 中status) 所以我猜我们的选择速度很慢，加上大量的插入/更新。
现在，最终的问题是:
我们是否应该为每个源查询数据库并获取大约 100ish(显然取决于系统)并将它们缓存在 memcached 中。然后，随着关闭请求的引导，从缓存中发送它们，但更新缓存以反射(reflect)“is_acccepted”标志。通过这种方式，我们只在缓存的潜在客户用完时才调用每个来源，所以在我们用完时只调用一次，而不是每个关闭请求潜在客户一次？
然后我们可以使用 memcached 的模拟锁定 - http://code.google.com/p/memcached/wiki/FAQ#Emulating_locking_with_the_add_command
这看起来是一个可行的解决方案吗？有什么建议吗？我们需要尽量减少拼命快速等待锁的可能性。
最佳答案
听起来可行，但您是否查看过您的索引并且是否在您的选择中使用了适当的隔离级别？
上一个 SO 问题可能会帮助您找到答案:Any way to select without causing locking in MySQL?
如果您在具有完整事务的 SP 中执行选择/更新，由于优化，这也可以大大加快速度。当然，有时 MySQL 中的 SP 会慢得多:(
我会把它作为评论，但还没有达到那个水平:)
我确实阅读了有关 inno-db 的部分，但经验告诉我，即使使用 inno，在使用隔离级别时也会有所改进。
关于php - 这是 Memcached 列表的可行解决方案吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6851186/