这是我在知乎上抛出的一个问题"我们的应用已经决定采mysql+memcached 的方式，针对的数据库版本是 mysql 5.1，目前已经进行了半个月的编码实现：
1.采用的是 ”memcached 和mysql 独立的实现方式，在编码层控制读 memcached，找不到再去数据库读，写数据库，然后再去更新 memcached，在这个过程发现逻辑复杂度比较高。
2.现在发现 “Using the MySQL memcached User-Defined Functions” 的实现方式，是通过触发器解决以上复杂逻辑的，从我的感觉上来看，应该是降低了代码复杂度。
我想诸位老师帮助我从理论上分析一下这两种方式的利弊，当然最好从实战角度分析两者的利弊，或者两者在使用上有什么值得注意之处，哪种更好，谢谢。"
本文转自永远的朋友博客51CTO博客，原文链接http://blog.51cto.com/yaocoder/1016257如需转载请自行联系原作者
各位老师的回答如下：
1.建议在应用层直接处理，而不要使用MySQL memcached User-Defined Functions
卢钧轶，MySQL DBA
虽然个人没用过memcached UDF，但是做过简单的评估，主要有以下几点觉得不适用于production。
1. 增加了Memcached和MySQL之间的耦合性。
试想如果UDF指向的memcached挂了，trigger方式调用的UDF是不会接收到报错返回的，程序段自然也无法做相应处理。
2. 增加了MySQL的服务器压力。
MySQL本身就是一个对服务器性能要求较高的DBMS，原本简单的App <--> Memcached，现在变成了 App <---> MySQL <---> Memcached ，无形中增加了MySQL不必要的转发压力（网络，CPU的损耗）
3. 运维困难。
某台Memcached如需升级，分离式架构只需要修改APP配置文件。而UDF的方案就需要修改相应的trigger，trigger是很难进行版本控制和批量下发管理的，无形中对运维造成了很大的困难
结合这位老师的思路经过自己的进一步考察，单单对于第一点，我觉得就可以抛弃使用memcached UDF了，作为一个为上万客户提供服务的后台程序，容错，单点故障是必须要考虑并处理的，如果无法准确知道错误的发生，就很难迅速进行补救；
2.给出在应用层简化处理memcached逻辑的思路
范凯，互联网创业者，JavaEye网站创始人
>>在编码层控制读memcached，找不到再去数据库读，写数据库，然后再去更新memcached，在这个过程发现逻辑复杂度比较高。
如果你的应用数据的粒度划分足够细，并且配合良好的ORM层对象缓存，那么没有任何逻辑复杂度，代码根本不需要涉及这些部分，都是ORM层缓存自动处理掉了。
经过我的进一步考察，相关的ORM框架有基于java的，C#的，由于我们的项目是使用C++语言实现，目前我还没有找到与之对应的相关ORM框架。
3.给出在应用层做memcached和mysql结合的使用建议
曹政
我喜欢在应用层做，没觉得逻辑复杂在哪里。
几个要点
1：memcache和mysql的链接时间，如果两个链接同时开启，先开启的会影响后开启的，比如memcache先开启链接，然后开启mysql，如memcache阻塞，程序未及时释放，会连带导致mysql崩溃，这种情况以前遇到过，记住链接必须加超时限制，防止连带阻塞现象。或者，释放memcache连接后，再开启mysql链接（这样不利于程序封装）
2：memcache命中率如不高，不如不用。做memcache应用后，第一件事情是测试命中率情况，不能认为加了缓存就一定可以提高效率。
3：如果数据块较大，放在memcache中读取的效率或许不如mysql。
4：随时监控swap分区占用情况，确保内存使用合理。
5：memcached适合简单的key-value查询，如果涉及结构性内容，或者排名类应用，建议使用redis.
本文转自永远的朋友博客51CTO博客，原文链接http://blog.51cto.com/yaocoder/1016257如需转载请自行联系原作者
yaocoder
