您的位置:首页 > 数据库

数据库应用优化(1)

2017-03-14 23:24 246 查看
PDO(PHP DATA OBJECT),PHP支持几乎市面上所有的数据库,但抽象度不免访问接口不够统一,所以PDO出现了,它提供了一个通用接口访问多种数据库,即抽象的数据库模型支持连接多种数据库,PDO扩展只是一个抽象层,本身不能实现数据库操作,必须使用一个特定的数据库PDO驱动访问数据库,从语法上PDO更接近MySQLi,之前学过PDO就不在这贴笔记了,只写一引起之前没学过的。
PDO效率:PDO的CRUD效率比MYSQL直连大概低5%-15%,并且方差大于MYSQL直连,如果项目对运行效率要求严格则应MYSQL或MYSQLI,PDO负载方面,PDO开启长连接后负载高于MYSQL且比较稳定,PDO连接MYSQL/ORACLE速度比直连有优势。
数据库应用优化

基本语句优化10个原则:

1.尽量避免在列上进行运算,这样会导致索引失败,select * from t where YEAR(d) >= 2011 优化为select * from t where d >= '2011-01-01'

2.使用JOIN时,应用用小结果集驱动大结果集。同时把复杂的JOIN查询拆分成多个Query,因为JOIN多个表时可能导致更多的锁定和堵塞。

3.注意LIKE模糊查询的使用,避免%%

4.仅列出需要查询的字段,这对速度不会有明显影响,主要考虑内在节省。

5.使用指插入语句节省交互

6.limit的基数比较大时使用between,between限定比limit快,所以在海量数据访问时建议用between或是where替换掉limit,但是between的缺陷是如果中间有断行或部分不读取的情况则总读取的数量会少于预计数量!在取比较后面的数据时,通过desc方式把数据反射查找,以减少对前段数据的扫描,让limit的基数越小越好。

7.不要使用rand函数获取多条随机记录

8.避免使用NULL

9.不要使用count(id)而应该是count(*)

10.不要做无谓的排序操作而尽可能在索引中完成排序
索引与性能分析

分析执行效率:set @@profiling=1;select * from tableName where condition;show profiles;或者show profile for query n;得到某次查询的详细性能报告以定位性能瓶颈,同一条语句的第二次查询明显比第一次查询要快是因为SQL缓存的结果。

MYSQL索引建立和使用基本原则:

合理设计和使用索引

在关键字段的索引上,建与不建索引查询速度相差近100倍

差的索引和没有索引效果一样

维护索引需要成本,不是越多越好

每个表索引应在5个以下,就合理利用部分索引和联合索引

不在结果集中的结果单一的列上建索引,比如性别只有0和1两种在这个字段上建索引并不会有太多帮助

建索引的字段结果集最好分布均匀,或者符合正太分布
服务器和配置的优化

MYSQL常用的引擎对比

-------------MyISAM-------Memory---------------InnoDB

用途----------快读--------内存数据------------完整的事务支持

锁------------全表锁定----全表锁定------------多种隔离级别的行锁

持久性--------基于表恢复---无磁盘IO无可持久性---基于日志的恢复

事务支持------不支持-------不支持--------------支持

索引类型---B-tree/FullText/R-tree---Hash/B-tree---Hash/B-tree

MYSQL在高并发下的性能瓶颈很明显,主要原因就是锁定机制导致的堵塞,而InnoDB在锁定机制上采用了行级锁,不同于MyISAM的表级锁,行级锁在锁定上带来的大于表级锁,但是在系统并发访问量较高时,InnoDB整体性能远高于MyISAM,同时InnoDB的索引不仅缓存索引本身,也缓存数据,所以InnoDB需要更大的内在,而现在内存是很廉价的。

选择最适合的索引引擎是优化的第一步;

1.存储引擎的选择方法

首先了解读写比(R/W)的概念,在数据库中执行show global status得到系统当前状态,在这些变量中形如Com_XXX的语句表示XXX的语句执行的次数,通过计算读类型和写类型语句的比例,即可确定一个粗糙的读写比例。理想的读写比例为100:1,当读写比例达到10:1的时候就认为是以写为主的数据库了,一般来说这个值在30:1左右,选择存储引擎的基本原则如下:

(1)采用MyISAM引擎:R/W大于100:1且update相对较少;并发不高不需要事务;表数据量小;硬件资源有限;

(2)采用InnoDB引擎:R/W比较小,频繁更新大字段;表数据量超过1000万,并发高;安全性和可用性要求高;

(3)采用Memory引擎:有足够的内存;对数据一致性要求不高,如在线人数和SESSION等应用;需要定期归档的数据;

2.MYSQL服务器调整优化措施

1)关闭不必要的二进制日志和慢查询日志,仅在内存足够或开发高度时打开它们,show variables like '%slow%' 或者 show global status like '%slow%'来查看慢查询的是否开启和条数,但慢查询也会带来一些CPU消耗,建议间断性打开慢查询日志来定位性能瓶颈;

2)适度使用Query Cache

3)增加MYSQL允许的最大连接数(连接复用),show variables like 'max_connections'查看;

4)对于MyISAM表适当增加key_buffer_size,当然这需要根据key_cache的命中率来进行计算,show global status like 'key_read%';key_cache_miss_rate = Key_reads / Key_read_requests * 100%,当key_cache_miss_rate值大于1%时就需要适当增加key_buffer_size了;对MyISAM表还需要注意table_cache的设置,当table_cache不够用的时候就会采用LRU(Least
Reference Used)算法踢掉最长时间 没有使用的表,所经table_cache的值要设置合理,防止因太小而造成性能损失和太大造成消耗很多CPU资源;而对InnoDB,需要重点注意innodb_buffer_pool_size参数

5)从表中删除大量行后,可运行OPTIMIZE TABLE TableName进行碎片整理
MYSQL瓶颈及应对措施

1)增加MYSQL配置中buffer和cache的数值,增加服务器CPU数量和内存大小,这能很大程度上应对MYSQL的性能瓶颈,性能优化中效果最显著成本最低的当属硬件和服务器优化,就优先考虑;

2)使用第三方引擎或衍生版本;

3)迁移到其他数据库;

4)对数据库进行分区、分表操作,减少单表体积;

5)使用NoSQL等辅助解决方案,如Memcached,Redis;

6)使用中间件做数据拆分和分布式部署;

最后,一个工具能不能用好,人的因素占很大的比重。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  mysql