mysql 缓存优缺点_优化MySQL与使用缓存哪个好？

说起MySQL的查询优化，相信大家收藏了一堆奇淫技巧：不能使用SELECT*、不使用NULL字段、合理创建索引、为字段选择合适的数据类型.....

今天小编想对一个Greenfield项目上可以采用的各种性能优化策略作个对比。换言之，该项目没有之前决策强加给它的各种约束限制，也还没有被优化过。

具体来说，小编想比较的两种优化策略是优化MySQL和缓存。提前指出，这些优化是正交的，唯一让你选择其中一者而不是另一者的原因是他们都耗费了资源，即开发时间。

优化MySQL

优化MySQL时，一般会先查看发送给mysql的查询语句，然后运行explain命令。稍加审查后很常见的做法是增加索引或者对模式做一些调整。

①通过showstatus命令了解各种sql的执行效率

②定位执行效率较低的SQL语句(dql出现问题的概率较dml的大)

③通过explain分析低效率的SQL语句的执行情况

④确定问题并采取相应的优化措施

优点

1、一个经过优化的查询对于所有使用应用的用户来说都是快速的。因为索引通过对数复杂度的速度来检索数据(又名分制，正如你搜索一个电话簿一样，逐步缩小搜索范围)，而且随着数据量的递增也能维持良好的性能。对一个未经索引化的查询的结果做缓存随着数据的增长有时候则可能会表现得更差。随着数据的增长，那些未命中缓存的用户可能会得到很糟糕的体验，这样的应用是不可用的。

2、优化MySQL不需要担心缓存失效或者缓存数据过期的问题。

3、优化MySQL可以简化技术架构，在开发环境下复制和工作会更加容易。

缺点

1、有一些查询不能光通过索引得到性能上的改善，可能还需要改变模式，在某些情况下这对于一些应用可能会很麻烦。

2、有些模式的更改可能用于反规范化(数据备份)。尽管对于DBA来说，这是一项常用的技术，它需要所有权以确保所有的地方都是由应用程序更新，或需要安装触发器来保证这种变化。

3、一些优化手段可能是MySQL所特有的。也就是说，如果底层软件被移植到多个数据库上工作，那么很难确保除了增加索引外一些更复杂的优化技术可以通用。

使用缓存

当你的数据库打开了QueryCache(简称QC)功能后，数据库在执行SELECT语句时，会将其结果放到QC中，当下一次处理同样的SELECT请求时，数据库就会从QC取得结果，而不需要去数据表中查询。

在这个“Cache为王”的时代，我们总是通过不同的方式去缓存我们的结果从而提高响应效率，但一个缓存机制是否有效，效果如何，却是一个需要好好思考的问题。在MySQL中的QueryCache就是一个适用较少情况的缓存机制。在上图中，如果缓存命中率非常高的话，有测试表明在极端情况下可以提高效率238%[1]。但实际情况如何？QueryCache有如下规则，如果数据表被更改，那么和这个数据表相关的全部Cache全部都会无效，并删除之。这里“数据表更改”包括:INSERT,UPDATE,DELETE,TRUNCATE,ALTERTABLE,DROPTABLE,orDROPDATABASE等。举个例子，如果数据表posts访问频繁，那么意味着它的很多数据会被QC缓存起来，但是每一次posts数据表的更新，无论更新是不是影响到了cache的数据，都会将全部和posts表相关的cache清除。如果你的数据表更新频繁的话，那么QueryCache将会成为系统的负担。有实验表明，糟糕时，QC会降低系统13%[1]的处理能力。

如果你的应用对数据库的更新很少，那么QC将会作用显著。比较典型的如博客系统，一般博客更新相对较慢，数据表相对稳定不变，这时候QC的作用会比较明显。

另外，这种优化需要人来分析应用的实际情况，然后将处理代价昂贵的部分从MySQL中剥离出来用第三方缓存替代，比如memcached或Redis。

优点

1、缓存对于一些MySql自身很难优化的查询来说会工作地很好，比如大规模的聚合或者分组的查询。

2、缓存对于提高系统的吞吐率来说可能是个不错的方案。比如对于多人同时访问应用时响应速度很慢的情况。

3、缓存可能更容易构建在另一个应用之上。比如：你的应用可能是另一个用MySQL存储数据的软件包的前端，而要对这个软件包做任何数据库方面的改动都非常难。

缺点

1、如果数据对外提供多种存取范式(例如，在不同的页面上用不同的形式展示)，那么让缓存过期或者更新可能会很难，同时/或者可能需要容忍已过期的数据。一个可行的替代方案是设计一套更加精细的缓存机制，当然它也有缺点，即多次获取缓存会增加时延。

2、缓存一个产生代价昂贵的对象对于那些未命中缓存的用户(见优化MySQL的优势#1)而言可能会产生潜在的性能差异。一些好的性能实践表明你应该尽量缩小用户之间的差异性，而不仅仅是平均化(缓存倾向于这么做)。

3、幼稚的缓存实现无力应对一些微妙的漏洞，比如雪崩效应。就在上周我帮助了一个人，他的数据库服务器被多个试图同时再生同样缓存内容的用户请求冲垮。正确的策略是引入一定级别的锁来将缓存再生的请求序列化。

小编结语：

一般情况下，小编会建议用户先对MySQL进行优化，因为这是小编认为开始阶段最合适的解决方案。但长期来看，大部分应用都会有一些用例需要一定程度上同时实现以上这些方案。

更多内容尽在课课家教育！