标签：配置 ref 日志 uri The 开发 系统配置 就是 read
我们在做性能测试的目的是什么，就是要测出一个系统的瓶颈在哪里，到底是哪里影响了我们系统的性能，找到问题，然后解决它。当然一个系统由很多东西一起组合到一起，应用程序、数据库、服务器、中中间件等等很多东西。那我们测试的时候上面这些东西里面任何一个环节都可能会出问题，都可能会影响我们系统的性能。这篇博客主要讲下mysql数据库咱们在做性能测试的时候应该监控什么东西，又有哪些需要优化的地方。
硬件就指的是数据库服务器的配置，服务器说白了就是一台电脑而已，如果电脑的配置高，cpu处理能力强，内存大，硬盘是ssd的，那肯定性能好。当然这种方式成本也是最高的，要花钱的嘛。
系统配置一个指的是操作系统的配置，有一些操作系统的配置会影响mysql的性能，现在咱们大多数服务器都是用的linux服务器，linux上面一切东西都是基于文件的，mysql数据里面的表、数据等等都是文件存在磁盘上的。
linux系统有一个系统配置是文件打开的数量，默认是1024，也就是最多只能打开1024个文件，那在数据库里面表比较多、并发大的情况下，这1024就不够用了，要想获取数据就得打开文件，但是打开文件的数量最多就1024个，就会导致有一些数据获取不到，就得等待别的文件关闭之后，才能打开。那就要修改系统的配置，在/etc/security/limits.conf文件里面可以修改最大打开文件的数量。
|
1
2
3
|
vi /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
|
还有一些mysql配置参数会影响mysql的性能。
mysql的连接数是提前配置好的，如果程序里面代码写的不好，有一些数据库操作没有及时关闭数据库，那这个链接就不会释放会一直占用链接，这样子并发大的情况下，就会导致数据库连接数不够用了，就连接不上数据库了。mysql默认8小时不操作数据库才会自动关闭链接，所以这个sleep的超时时间会影响mysql的性能。
|
1
2
|
set global wait_timeout=600; 设置sleep的超时间，单位是秒
show variables like ‘%wait_timeout%‘; 查询超时时间
|
|
1
2
|
set global innodb_file_per_table =ON; 设置独立表空间打开
show variables like ‘%per_table%‘; #查询是否打开独立表空间
|
在mysql5.5之后读、写的进程数是可以配置的。默认读和写的进程数都是4个。
当然我们都知道，人多好干活嘛。进程多就是干活的人多，具体配置根据cpu的核数和业务逻辑来配置这两个值。
假如cpu是32核的，那么就是同时可以有32个进程在运行，就可以把这两个值给调大。
假如说是系统是一个内容类的网站，大多数操作都是读操作，那么就可以把读的进程数设置大一点，写的进程数设置的小一点。
怎么修改呢，找到mysql的配置文件，在[mysqld]节点下加入下面参数的即可
|
1
2
|
innodb_read_io_threads =5 读进程数
innodb_write_io_threads =3 写进程数
|
在说缓存配置之前咱们先了解清楚，计算机在处理任务的时候是怎么处理的，先从磁盘上读取数据，然后放到内存里面，cpu去内存里面拿数据，然后处理。
在写的时候正好相反，cpu处理完之后，把数据放到内存里面，内存再放到磁盘里。
那从上面，我们发现，如果数据直接从内存里面拿的话，那速度就快很多了，我们看下面的图，读1M的数据，内存里面比从磁盘上快多少。
从上面这个图我们发现从内存里面读数据比从磁盘里面取数据快了N倍。
那到mysql里面，如果取数据的时候，mysql先把一些数据缓存到内存里面的话，取数据直接从内存里面取不就快很多了。
咱们在说mysql缓存之前，先说下mysql在执行一条查询语句的时候都做了什么。
从上面的图我们发现，mysql是有两个地方检查了内存的。如果内存里面找到我们想要的数据，那么就不去磁盘上查询数据了。那么这两个缓存都是什么，怎么配置呢。
开启查询缓存对于读写都增加了额外的开销。对于读，在查询开始前需要先检查缓存；对于写，在写入后需要更新缓存。
一般情况这些开销相对较小，所以查询缓存一般还是有好处的。但也要根据业务特征权衡是否需要开启查询缓存。
怎么配置呢，找到mysql的配置文件，在[mysqld]节点下加入下面参数的即可
|
1
2
3
4
5
6
7
8
|
query_cache_size = 200M
分配给查询缓存的总内存，一般建议不超过256M
query_cache_limit = 1M
这个选项限制了MySQL存储的最大结果。如果查询的结果比这个大，那么就不会被缓存。
下面是查看qcache的状态的语句
SHOW VARIABLES LIKE ‘%query_cache%‘;#查看qcache状态
|
mysql里面还有一个缓存配置就是innodb_buffer_pool的配置，innodb是现在mysql的默认存储引擎，存储引擎说白了就mysql存数据的时候到底是怎么存的。
就是一个仓库里面怎么摆放货物的。
buffer pool是innodb存储引擎带的一个缓存池，查询数据的时候，它首先会从内存中查询，如果内存中存在的话，直接返回，从而提高查询响应时间。
innodb buffer pool和qcache的区别是：qcacche缓存的是sql语句对应的结果集，buffer pool中缓存的是表中的数据。buffer pool一般设置为服务器物理内存的70%。
怎么配置呢，找到mysql的配置文件，在[mysqld]节点下加入下面参数的即可
|
1
2
3
4
5
|
innodb_buffer_pool_size=50M #Innodb_buffer_pool的大小
innodb_buffer_pool_dump_now=on #停止MySQL服务时，InnoDB将InnoDB缓冲池中的热数据保存到本地硬盘。
innodb_buffer_pool_load_at_startup =on #启动MySQL服务时，MySQL将本地热数据加载到InnoDB缓冲池中。
SHOW VARIABLES LIKE ‘%innodb_buffer_pool%‘;#查看buffer_pool的大小
|
读写分离
多点写入
当然系统在设计表结构的时候，一般都是架构师和一帮开发已经把表结构设计好了，咱们没达到那个级别架构上的东西咱也不懂，就在设计表结构的时候需要注意的一些东西。
索引是什么呢，就和字典的目录一样。有目录了，那咱们查数据就快了。
最适合建索引的列是出现在where子句后面的列。
唯一索引的效果最好，因为是唯一的。
利用最左前缀。
索引并不是越多越好。
mysql索引有4种类型
1、普通索引
最普通的索引，所有列都可以加
|
1
|
create index index_name on table_name (col);
|
2、主键索引
建表的时候加的主键
3、组合索引
|
1
|
create index index_name on table_name (col,col2);
|
4、唯一索引
|
1
2
|
CREATE UNIQUE INDEX index_name
ON table_name (column_name);
|
因为每个开发的水平都不一样，不可避免的的会出现一些重复索引的问题。那我们怎么来查找有一些冗余的索引呢。
就要借助percona-toolkit这个工具了，它里面有pt-duplicate-key-checker这个工具可以帮咱们找出来哪些表里面有冗余的索引，并给出修改索引的语句。
|
1
|
pt-duplicate-key-checker -uroot -pxxx -dxx#-u指的是用户 -p是密码 -d是数据库
|
这个能帮咱们找出来重复的索引，那还有一些根本就没有必要用的索引，虽然索引建立的并不是重复，但是实际上并没用查询语句用到它，怎么办呢，percona-toolkit这个工具里还有一个工具是pt-index-usage，它可以读取慢查询日志，帮咱们找到那些没用的索引。
|
1
|
pt-index-usage /opt/data/slow.log #后面是慢查询日志
|
什么是慢查询日志呢，它这个就是个神器了，对咱们测试特别有帮助，它会记录执行时间长的sql语句，这样咱们找问题的时候就比较方便了。
|
1
2
3
4
5
6
7
|
set global slow_query_log=on;#打开慢查询日志
set global long_query_time=1;#设置记录查询超过多长时间的sql
set global slow_query_log_file=‘/tmp/slow_query.log‘;#设置mysql慢查询日志路径，此路径需要有写权限
set global log_queries_not_using_indexes=ON; #设置没有使用索引的sql记录下来
SHOW VARIABLES LIKE ‘%slow%‘;#查看慢查询配置
|
mysql记录的日志里面，咱们看着比较不清晰，咱们使用pt-query-digest这个工具帮咱们解析慢查询日志，它会把所有的sql的执行时间以及具体sql，执行了多少次都帮咱们统计出来。
下面是pt-query-digest的用法
|
1
2
3
|
pt-query-digest --filter=‘$event->{fingerprint} =~ m/^select/i‘ slow.log #查看包含select语句的慢查询
pt-query-digest --since=12h slow.log #最近12小时的
pt-query-digest --since ‘2017-12-01 09:30:00‘ --until ‘2017-12-02 10:00:00‘ --filter=‘$event->{fingerprint} =~ m/^select/i‘ slow.log #指定时间段
|
如果想实时的获取有没有执行时间长的sql，用下面这个sql语句
|
1
|
select id,`user`,`host`,DB,command,`time`,state,info from information_schema.PROCESSLIST where TIME>=60;
|
通过慢查询日志我们可以找到有问题的sql语句，那我们怎么看这个sql哪有问题呢，就要使用explain了，只要在你要执行sql语句前面加上explain即可
all<index<range<ref<eq_ref<const,system sql执行type列里最差到最优
sql优化时候需要注意的
查询条件使用索引列，排序使用索引列
避免select *，一般select * 都会造成全表扫描
尽量避免子查询，MySQL 的子查询执行计划一直存在较大的问题，虽然这个问题已经存在多年，但是到目前已经发布的所有稳定版本中都普遍存在，一直没有太大改善。虽然官方也在很早就承认这一问题，并且承诺尽快解决，但是至少到目前为止我们还没有看到哪一个版本较好的解决了这一问题。
银行存钱例子。
表级锁、行级锁。
SELECT * FROM information_schema.INNODB_TRX\G
mysqlslap是mysql自带的一个性能测试工具。它可以模拟各种并发，以及使用哪种sql，生成多少数据，运行多久，产生报告。
常用的选项
|
1
2
3
4
5
6
7
8
9
10
11
|
--concurrency 并发数量,多个可以用逗号隔开
--engines 要测试的引擎，可以有多个，用分隔符隔开，如--engines=myisam,innodb
--auto-generate-sql 用系统自己生成的SQL脚本来测试
--auto-generate-sql-load-type 要测试的是读还是写还是两者混合的（read,write,update,mixed）
--number-of-queries 总共要运行多少次查询。每个客户运行的查询数量可以用查询总数/并发数来计算
--debug-info 额外输出CPU以及内存的相关信息
--number-int-cols 创建测试表的int型字段数量
--number-char-cols 创建测试表的chat型字段数量
--create-schema 测试的database
--query 自己的SQL 脚本执行测试
--only-print 如果只想打印看看SQL语句是什么，可以用这个选项
|
下面是使用的例子
|
1
2
3
4
5
6
7
8
|
100并发，运行1000次，写操作和读操作都有，自动生成sql，int类型字段2个，char类型10个，
mysqlslap -h127.0.0.1 -uroot -p123456 --concurrency=100 --auto-generate-sql --auto-generate-sql-load-type=mixed --engine=innodb --auto-generate-sql-add-autoincrement --number-int-cols=2 --number-char-cols=10 --number-of-queries=10
100并发，运行5000次，besttest这个数据库上执行sql
mysqlslap -h127.0.0.1 -uroot -p123456 --concurrency=100 --query=‘select * from stu;‘ -create-schema=besttest --engine=innodb --number-of-queries=5000 --debug-info
100并发，运行5000次，besttest这个数据库上执行指定的sql文件
mysqlslap -h127.0.0.1 -uroot -p123456 --concurrency=100 --query=/tmp/besttest.sql -create-schema=besttest --engine=innodb --number-of-queries=5000--debug-info
|
标签：配置 ref 日志 uri The 开发 系统配置 就是 read
原文地址：https://www.cnblogs.com/linwenbin/p/11263319.html
