数据库优化总结

对于一个以数据为中心的应用,数据库的好坏直接影响到程序的性能,因此数据库性能至关重要。一般来说,要保证数据库的效率,要做好以下四个方面的工作: 数据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统,这个顺序也表现了这四个工作对性能影响的大小

一、数据库设计
我们都知道三范式(第一范式:无重复的列、第二范式:属性完全依赖于主键、第三范式:属性不能传递依赖于主属性(属性不依赖于其它非主键属性)),基于三范式建立的模型是最有效保存数 据的方式,也是最容易扩展的模式。我们在开发应用程序时,设计的数据库要最大程度的遵守三范式,特别是对于OLTP型的系统,三范式是必须遵守的规则。当 然,三范式最大的问题在于查询时通常需要join很多表,导致查询效率很低。所以有时候基于性能考虑,我们需要有意的违反三范式,适度的做冗余,以达到提 高查询效率的目的。注意这里的反范式是适度的,必须为这种做法提供充分的理由。

适当建立索引
  说起提高数据库性能,索引是最物美价廉的东西了。不用加内存,不用改程序,不用调sql,只要执行个正确的’create index’,查询速度就可能提高百倍千倍,这可真有诱惑力。可是天下没有免费的午餐, 查询速度的提高是以插入、更新、删除的速度为代价的,这些写操作,增加了大量的I/O。由于索引的存储结构不同于表的存储,一个表的索引所占空间比数据所占空间还大的情况经常发生。这意味着我们在写数据库的时候做了很多额外的工作,而这个工作只是为了提高读的效率。因此,我们建立一个索引,必须保证这个索引不会“亏本”。一般需要遵守这样的规则:

  索引的字段必须是经常作为查询条件的字段;

  如果索引多个字段,第一个字段要是经常作为查询条件的。如果只有第二个字段作为查询条件,这个索引不会起到作用;

  索引的字段必须有足够的区分度;

  Mysql 对于长字段支持前缀索引;

对表进行水平划分
   如果一个表的记录数太多了,比如上千万条,而且需要经常检索,那么我们就有必要化整为零了。如果我拆成100个表,那么每个表只有10万条记录。当然这 需要数据在逻辑上可以划分。一个好的划分依据,有利于程序的简单实现,也可以充分利用水平分表的优势。比如系统界面上只提供按月查询的功能,那么把表按月 拆分成12个,每个查询只查询一个表就够了。如果非要按照地域来分,即使把表拆的再小,查询还是要联合所有表来查,还不如不拆了。所以一个好的拆分依据是 最重要的。

对表进行垂直划分
  有些表记录数并不多,可能也就2、3万条,但是字段却很长,表占用空间很大,检索表时需要执行大量I/O,严重降低了性能。这个时候需要把大的字段拆分到另一个表,并且该表与原表是一对一的关系。

选择适当的字段类型,特别是主键
  选择字段的一般原则是保小不保大,能用占用字节小的字段就不用大字段。比如主键, 我们强烈建议用自增类型,不用guid,为什么?省空间啊?空间是什么?空间就是效率!按4个字节和按32个字节定位一条记录,谁快谁慢太明显了。涉及到 几个表做join时,效果就更明显了。值得一提的是,datetime和timestamp,datetime占用8个字节,而timestamp占用4 个字节,只用了一半,而timestamp表示的范围是1970—2037,对于大多数应用,尤其是记录什么考试时间,登录时间这类信息,绰绰有余啊。

   文件、图片等大文件用文件系统存储,不用数据库

   不用多说,铁律!!!数据库只存储路径。

  外键表示清楚,方便建立索引

  我们都知道,在powerdesigner里为两个实体建立关系,生成物理模型时会自动给外键建立索引。所以我们不要怕建立关系把线拉乱,建立个ShortCut就好了。

二、SQL语句优化
http://blog.csdn.net/csh624366188/article/details/8457749

三、数据库参数配置
最重要的参数就是内存,我们主要用的innodb引擎,所以下面两个参数调的很大

  # Additional memory pool that is used by InnoDB to store metadata

  # information. If InnoDB requires more memory for this purpose it will

  # start to allocate it from the OS. As this is fast enough on most

  # recent operating systems, you normally do not need to change this

  # value. SHOW INNODB STATUS will display the current amount used.

  innodb_additional_mem_pool_size = 64M

  # InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and

  # row data. The bigger you set this the less disk I/O is needed to

  # access data in tables. On a dedicated database server you may set this

  # parameter up to 80% of the machine physical memory size. Do not set it

  # too large, though, because competition of the physical memory may

  # cause paging in the operating system. Note that on 32bit systems you

  # might be limited to 2-3.5G of user level memory per process, so do not

  # set it too high.

  innodb_buffer_pool_size = 5G

  对于myisam,需要调整key_buffer_size

  当然调整参数还是要看状态,用show status语句可以看到当前状态,以决定改调整哪些参数

  Cretated_tmp_disk_tables 增加tmp_table_size

  Handler_read_key 高表示索引正确 Handler_read_rnd高表示索引不正确

  Key_reads/Key_read_requests 应小于0.01 计算缓存损失率,增加Key_buffer_size

  Opentables/Open_tables 增加table_cache

  select_full_join 没有实用索引的链接的数量。如果不为0,应该检查索引。

  select_range_check 如果不为0,该检查表索引。

  sort_merge_passes 排序算法已经执行的合并的数量。如果该值较大,应增加sort_buffer_size

  table_locks_waited 不能立即获得的表的锁的次数,如果该值较高,应优化查询

  Threads_created 创建用来处理连接的线程数。如果Threads_created较大,要增加 thread_cache_size值。

  缓存访问率的计算方法Threads_created/Connections。


四、合理的硬件资源和操作系统

  如果你的机器内存超过4G,那么毋庸置疑应当采用64位操作系统和64位mysql

  读写分离

  如果数据库压力很大,一台机器支撑不了,那么可以用mysql复制实现多台机器同步,将数据库的压力分散。  

  Master

  Slave1

  Slave2

  Slave3

   主库master用来写入,slave1—slave3都用来做select,每个数据库分担的压力小了很多。

   要实现这种方式,需要程序特别设计,写都操作master,读都操作slave,给程序开发带来了额外负担。当然目前已经有中间件来实现这个代理,对程 序来读写哪些数据库是透明的。官方有个mysql-proxy,但是还是alpha版本的。新浪有个amobe for mysql,也可达到这个目的



你可能感兴趣的:(数据库优化)