数据库性能优化方案---缓存和结构

除了索引和锁优化之外，还有很多种优化方案
比如本篇所学习的查询缓存、线程池和临时表
这些都是依靠配置MySQL来逐步优化性能直至最佳
除此之外，还有反范式设计，使用NoSQL以及数据仓库等方案
下面就来一一了解这些小技巧

查询缓存

在show variables里面可以查询缓存是否开启，在my.cnf里面可以查询默认配置

?

my.cnf

1 2 3 4

# * Query Cache Configuration # query_cache_limit   = 1 M query_cache_size        = 16 M

再连续查询时，就可以对查询进行加速
使用mysqlreport可以监控它的状况
mysqlreport -user root -password
__ Query Cache _________________________________________________________
Memory usage 10.59k of 16.00M %Used: 0.06
Block Fragmnt 25.00%
Hits 1 0.0/s
Inserts 1 0.0/s
Insrt:Prune 1:1 0/s
Hit:Insert 1.00:1

临时表容量

在mysqlreport中，可以观察临时表的情况
__ Created Temp ________________________________________________________
Disk table 54 0.0/s
Table 221 0.0/s Size: 16.0M
File 5 0.0/s
如果这个表不够用了，我们需要在mysql配置中修改tmp_table_size
在命令行中输入show variables;可以找到该变量

线程池

__ Threads _____________________________________________________________
Running 1 of 2
Cached 0 of 8 %Hit: 97.70
Created 2 0.0/s
Slow 0 0/s
在my.cnf中找到变量thread_cache_size
关注report的结果，确定在并发多的时候，thread由一个良好的命中率
可以根据实际情况调整值的大小并进行磨合
虽然对性能的提升并不是很显著，但是也是一个可以入手优化的点

反范式化

在搞程序一段时间的人，以抽象思维所造出的表格都是符合标准范式的
但是很多时候，遵循这些范式反而带来了过多的多表查询
比如下面两张表
订单表:order_id user_id order_time order_price
用户表:user_id user_name
我们在显示表格时，经常需要将订单号和用户名一起显示
但是这样就涉及到多表查询或者是in查询
现在随便一个电商企业，订单表就要上百万的数据
很明显费时又费力
这个时候，我们修改订单表
订单表:order_id user_id user_name order_time order_price
这样就成了单表查询
现在服务器的磁盘空间都很大，这么一点的冗余根本不算什么，但是它能对性能有很大的帮助

不过反范式化所带来的就是信息更新所带来的差异，用户改了自己的名字，但是订单里依旧显示以前的名字
这里可以通过定时更新的办法来解决
如果你的系统还没有开发，那么使用MVC分层的方式，将用户资料的更新封装起来，使其在更新用户名称时，自动在订单表更新名字，也是不错的选择
当然，你不管它，过去的订单，又有什么问题呢？

NoSQL

在这个博客已经有很多NoSQL的东西了
我们在特定情况下，选择NoSQL绝对是明智的选择
虽然会有更多的冗余，或者是有更大数据量的副本
但是对查询却有着很好的帮助
想像facebook，你那么多好友，却能瞬间得到好友的所有新鲜事儿，多么赞
Memcache，Redis，MongoDB等技术都已经比较成熟
可以在工作实践中采用