Mysql性能优化需要考虑的因素

对于程序员来说数据库就是操作非常方便的数据存储中心，希望什么数据都存放在数据库中，不论是需要持久化的数据，还是临时存放的过程数据，不论是普通的纯文本格式的字符数据，还是多媒体的二进制数据，都喜欢全部塞如数据库中。因为对于应用服务器来说，数据库很多时候都是一集中式的存储环境，不像应用服务器那样可能有很多台；而且数据库有专门的DBA 去帮忙维护，而不像应用服务器很多时候还需要开发人员去做一些维护；还有一点很关键的就是数据库的操作非常简单统一，不像文件操作或者其他类型的存储方式那么复杂。

其实正因为很多数据库提供了丰富的存储功能，反而一些不了解数据库的程序员将一些不适合存储在数据库中的数据存放在数据库中

以下几种数据库是不适合在数据库中存放的

1.二进制多媒体数据

2. 流水队列数据：需要频繁的向数据库中

3. 超大文本数据



什么数据适合被缓存？变更较少，访问频繁的数据

在web应用中有些活跃的数据是不经常改变的，既然不经常改变，我们就应该考虑是否每次都有必要去查询数据库，答案是没有必要的，下面这几类数据适合被缓存

1.系统配置信息和规则数据

2.活跃用户的基本信息，用户登录之后很少去修改自己的基本信息

3.用户的个性化等值数据

4.准实时的统计信息数据：就是基于一定时间段做一次更新操作



下面大概列举了一些较为常见的架构设计实现不当带来的性能问题和资源浪费情况。

1、Cache 系统的不合理利用导致Cache 命中率低下造成数据库访问量的增加，同时也浪费了Cache

系统的硬件资源投入；

2、过度依赖面向对象思想，对系统

3、对可扩展性的过渡追求，促使系统设计的时候将对象拆得过于离散，造成系统中大量的复杂Join

语句，而MySQL Server 在各数据库系统中的主要优势在于处理简单逻辑的查询，这与其锁定的机制也有

较大关系；

4、对数据库的过渡依赖，将大量更适合存放于文件系统中的数据存入了数据库中，造成数据库资源

的浪费，影响到系统的整体性能，如各种日志信息；

5、过度理想化系统的用户体验，使大量非核心业务消耗过多的资源，如大量不需要实时更新的数据

做了实时统计计算。



不同的sql语句被解释器分析后执行的效率和占用的资源是不同的

必要的时候数据库设计可以用空间换时间




上面两个表（贴子基本信息表，和贴子内容表）是用来存储用户提交的贴子，我们从表中可以看到里面有一个user_id 和author字段，二者是对应的，有人说了，通过user_id级联到user表中可以得到姓名啊，那么要author不是多余么? 因为一般情况下我们查看贴子的内容都是只看姓名,如果又该字段就不用表之间的级联了，对于大数据量访问，提高的性能是很可观的

另一种是将一个表拆分成两个表，我们观察一下第二个表，只有两个字段，有些人觉得把把这两个表合在一起也行啊，我们知道贴子的内容一般很多的，这样的话查找帖子的时候我们需要遍历每个条帖子的内容，如果贴子的数量成百上千万，开销是很大的，如果把帖子单独放在一个表中的话，我们可以通过基本信息表的到贴子ID，不需要遍历复杂的内容字段，然后根据帖子ID直接定位到内容表去查询内容即可。