您的位置:首页 > 数据库 > MySQL

MySQL数据库优化技巧

2015-05-08 23:30 513 查看

1. 优化数据类型

(1)使用小类型的数据类型。小类型的数据在磁盘寻址的时候占用更少的资源,也减少了CPU的运算时间,这样在io wait的时候就不会因为大字段而消耗过多资源。

(2)简单类型优先。比如使用整型存储时间戳;用整型存储IP地址;用整型存储货币浮点,在应用层,再用乘除法换算小数点的精度。

(3)尽量不要使用NULL。对于优化索引,如果字段是NULL,无法对其NULL进行索引排列。不过InnoDB对于NULL是做了特殊的bit位存储。

2. 主键类型的选择

(1)单点使用自增类型的无符号整型。而使用字符串,尤其是随即字符串——UUID,读写性能下降都比较大。

(2)集群中要根据场景视情况而决定是用整型还是UUID。整型比UUID多的步骤就是需要知道全局的主键标示是什么,也就是需要加锁(无论是排他还是读写锁),免不了锁的开销。其他多余的逻辑开销基本没有,而从底层存取来说,随着数据量的增大,整型的优势明显,如果并发量很大,而又是追求吞吐量,UUID优势略微明显。如果数据量也很大,并发量有很大,读多写少的情况,基本上采用整型。如果读写频率相当一致,就该考虑要牺牲一下数据的一致性和准确性保证吞吐量了,那么UUID和整型,基本上在此场景下都差不多了。

3. 字段个数尽量少

存储引擎要想将数据返回给Mysql服务层需要经过数据行缓冲,服务器层要将缓冲的内容解码(因为数据是从存储引擎返回的)为固定的各个列。如果列的个数很多,那么呢,这个数据行转换的代价,比较高!尤其是变长结构——特指myisam和innodb的变长结构,最具代表性,使用频率最高的的——varchar。

4. 关联尽量少

Mysql每个主表关联的操作,只能深到61个从表深度(记住,这里是深度,有点像Java的栈深度,不是广度哦)。《高性能Mysql》的作者们提倡一般关联深度是12层以内。

5. 反范式化

符合范式的优点:

(1)查询的时候,只查询你所关心的表的局部字段数据,而不需要关联的多次IO,去别的表查询关联数据

(2)对于更新操作,只需要关心更改的数据,而不是将整个大表中的某个记录进行行锁定进行更新,其实这里面已经蕴含着分桶,分堆管理的读写分离思想了。

(3)基本上表都是小表,如果不是全局数据集的话,基本上可以放置在数据库的查询缓存中,也就是内存中进行缓存了。

(4)范式化的表,基本上都是按照某种外键进行了分组,相当于在表设计的时候就进行了group by操作。那么查询SQL语句的复杂度,就可以简简单单的根据一个where 外键 = 某值,进行查询。

符合范式的缺点:

(1)其实也是第一个优点的反面case,当一个查询需求需要全字段的数据的时候,不得不多次地随机IO的去关联表去查询整体的实体信息,比如SNS中的用户的profile信息。而反范式的话,那么都在一个表内,基本上都是(小部分不是)顺序IO,磁盘读取数据很快。

(2)关联表越多,索引的工地不过关,那么可能造成关联索引,或者聚合索引失效。

不符合范式的优点与缺点正好是符合范式的颠倒,在此不赘述。

混合范式

实际开发中基本是:根据项目业务场景,范式+反范式=混合范式使用。在产品、项目的不同阶段、数据量不同、用户量不同、并发量不同,会采取不同的混合策略。

6. 牺牲数据时效性,换来高性能

查询一个表的多条记录,用于grid列表展示,那么每个业务基本包含了两个查询事务,一个是用于分页的查询select count记录;另一个用于查询记录的普通select * from操作。随着记录增加,两次查询成本过高,虽然在同一个业务,但是却是两个事务,那么此时数据隐含着已经是有不一致的情况了,所以笔者干脆将count的记录放到了缓存表——memroy中,表名tableinfo,里面仅仅记录了表名,总记录数两个字段,定时任务定时执行select count语句,将结果赋值给该表的记录。

CREATE TABLE
tableinfo
(

tablename
varchar(40) NOT NULL,

datacount
int(10) DEFAULT NULL,

PRIMARY KEY (
tablename
),

UNIQUE KEY
tablename
(
tablename
) USING HASH

) ENGINE=MEMORY DEFAULT CHARSET=utf8;

该引擎是memroy,索引键是表名,索引类型,hash。每次启动应用的时候,也会扫描一遍业务表的总记录数,将最新的总记录数赋值给该表的记录。这样,每次执行count就可以从该表进行查询了,只要数据库服务不重启,该汇总表都是有效的。需要说明的是,该汇总信息肯定是牺牲数据的时效性的。

7. 分桶的思想

其实分桶的思想在程序界处处可见,比如Java并发包的并发HashMap。将此思想应用到数据库理论中呢,其实就是读写分离的思想。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: