• 1. MySQL使用规范及技巧
  • 2. 大纲1. MySQL体系架构 2. MyISAM、Innodb引擎介绍 3. 表结构设计原则 4. 索引设计原则 5. 性能分析工具 6. SQL语句优化Page:2
  • 3. 7. 海量数据的写入优化 8. 查看状态及启动故障排除 9. 备份与恢复 10.查询日志 11.压力测试Page:3
  • 4. 1.1 MySQL体系架构Page:4
  • 5. 1.2 Query执行流程Page:5
  • 6. 1.2 Query执行流程Page:6
  • 7. 1.3 细化:数据处理方式 获取数据时,首先在内存中查找数据;如果不存在,将得到一个系统调用错误,触发数据抽取动作。 抽取动作:首先判断是否有适当的索引可以调用, a)如果有:先通过B+tree查询到键值所在页面(索引页),然后将该页面加载到内存中,然后通过二叉树再次查找所需的行寻址地址,根据寻址地址扫描磁盘返回行数据。 b)没有相应的索引:扫描磁盘返回行数据。 抽取动作结束后,一方面返回给内存做缓存,一方面将数据通过连程线程返回给客户端Page:7
  • 8. 1.4 总结Page:8通过第一章的学习,得出如下结论: a)mysqld有connection pool的,会缓存设定大小的连接线程,不要太过担心频繁的连接造成的系统消耗 b) mysqld有Cache & Buffer 具有读写缓存,可以缓解读写压力。 c) mysqld具有解析、优化功能,但不可过度的依赖;sql复杂程度会影响mysqld的解析与优化,因此优秀的SQL语法与表结构是必需的。 d)合适的索引的会极大的提升性能(查询速度、CPU、IO)
  • 9. 2.1 MyISAM、Innodb引擎介绍Page:9A)MyISAM表特性: MyISAM是个堆表,数据按先后顺序依次写入(理论上速度快、表级锁对高并发海量数据写入性能造成的影响大),因此数据是无序存放的; MyISAM索引是有序的它指向.myd 文件中具体行(保存磁盘数据的寻址地址)
  • 10. 2.1 MyISAM、Innodb引擎介绍Page:10B)Innodb表特性: Innodb是栈表,对于不在一个页上的数据更新,原则上不会影响其他页的写入(支持并发写),数据采用二叉树结构存放。 索引与表数据全在单独的表空间中(.ibd),非聚集索引数据的更新由主键关联插入。
  • 11. 2.1 MyISAM、Innodb引擎介绍Page:11A) MyISAM占用存储空间的特性: MyIsam:索引与数据文件分开存放,由frm/myi/myd等文件组成。myisam容易形成碎片,特别是有varchar 字段时大批量的修改删除操作。空间浪费比较严重,所以适当时候要修复表,但要尽可能的避免修复表;修复有风险,使用请谨慎。 附: 修复原理:其实就是校对索引文件,然后再校对数据文件;将索引与数据进行对比;如果数据文件有多余的数据,那说明索引损坏,就需要在索引树中新增键值,修复索引。如果是索引中有数据,数据文件没数据,就是数据丢失很严重,就修复数据,重新排序数据,可能引起数据丢失 危害:锁表、非常消耗CPU和IO
  • 12. 2.1 MyISAM、Innodb引擎介绍Page:12B) Innodb占用存储空间的特性:
  • 13. 2.1 MyISAM、Innodb引擎介绍Page:13A)MyISAM锁机制: MyISAM: 只支持表级锁,最小粒度为表,兼容性如下: 用户在操作MyISAM 表时,select,update,delete,insert 语句都会给表自动加相应的锁。
  • 14. 2.1 MyISAM、Innodb引擎介绍Page:14B)Innodb锁机制: Innodb: 支持行级锁,最小粒度为Row,兼容性如下:
  • 15. 2.1 MyISAM、Innodb引擎介绍Page:151.查看当前会话隔离级别:select @@tx_isolation; 2.查看系统当前隔离级别:select @@global.tx_isolation; 3.设置当前会话隔离级别:set session transaction isolation level repeatable read; 4.设置系统当前隔离级别:set global transaction isolation level repeatable read; 5.命令行,开始事务时: set autocommit=off 或者 start transaction
  • 16. 3.1 表结构设计原则Page:16更小的字段类型和更小的字符数通常对请求的处理更快;因为他们占用更少的CPU缓存、更少的磁盘空间、更少的磁盘IO、更少的带宽、更少的内存(MySQL通常会根据列类型分配固定大小的内存块来保存值,不合理会严重影响排序和基于内存的临时表) 选择合适的数据类型,如果能够定长尽量定长;遵守越小越好、越简单越好的设计思路 Bit>tinyint(1/127)>smallint(2/255)>int(4/21亿)>bigint(8/千亿以上) float(4)>double(8)>decimal(m,n) year>date>time>timestamp>datetime Enum()>char(m)/varchar(m)>blob、text 数字分为整数和小数,使用unsigned可以提供一倍的数据空间。
  • 17. 3.1 表结构设计原则Page:17int(1)和int(20)保存的值是一样的,它不会限制范围,只是规定了mysql的交互工具显示的字符个数 为保证查询性能,最好每个表都建立有:auto_increment字段 text和blob类型用于存储大数据,mysql将该类型当成有实体的对象来处理,存储引擎会单独保存他们; mysql不能对该类型进行完全索引,但可以通过部分前缀索引。在使用order by操作时,也不会使用该类型索引 尽可能避免使用长字符串做标识符,因为占用了很多空间而且速度通常比数字慢,性能会指数级的放大。
  • 18. 3.1 表结构设计原则当所有数据集都很热的时候,不合理的字符串(char/varchar)类型会使特定的数据缓存到内存没有意义,而且还可能造成结果集不能完全装载进内存,这将导致大量的缓存刷写工作,严重降低缓存命中率 为了避免联表查询,有时候可以适当的数据冗余,比如:邮箱、姓名这些不容易更改的数据 最好给每个字段都设定 default 值 除非真的需要保存NULL,否则将字段设置为NOT NULL。在填充数据时,尽可能用空字符串或0来代替 Page:18
  • 19. 4.1.1 索引设计原则--索引原理Page:19
  • 20. 4.1.1 索引设计原则--索引原理Page:20
  • 21. 4.1.2 索引对查询效率的影响Page:21过度索引是如何影响数据库的性能的呢? 1。 在执行sql之前,数据库会根据metadata信息决定该使用哪个索引,如果索引过多会影响这一步骤的效率。 2。 由于每次数据更新和插入都要更新索引,因此会影响相关操作的效率测试环境: create PROCEDURE insert_data_for_test_index_performance () begin DECLARE total int default 100000; DECLARE i int default 0; truncate table test_index_performance; while(i < total) do insert into test_index_performance values (i, ’a',’a',’a',’a',’a',’a',’a',’a',’a',’a'); set i=i+1; end while ; end $$ delimiter ; call insert_data_for_test_index_performance();drop table if EXISTS test_index_performance; CREATE TABLE test_index_performance ( id int primary key , col1 varchar(10), col2 varchar(10), col3 varchar(10), col4 varchar(10), col5 varchar(10), col6 varchar(10), col7 varchar(10), col8 varchar(10), col9 varchar(10), col10 varchar(10) )engine=innodb;
  • 22. 4.1.2 索引对查询效率的影响Page:22
  • 23. 4.1.3 索引设计原则Page:23设计原则 1. 搜索的索引列,不一定是所要选择的列。换句话说,最适合索引的列是出现在WHERE 子句中的列,或连接子句中指定的列,而不是出现在SELECT 关键字后的选择列表中的列。 2. 使用惟一度高作索引。考虑某列中值的分布,对于惟一值的列,索引的效果最好,而具有多个重复值的列,其索引效果最差。例如,存放年龄的列具有不同值,很容易区分各行。而用来记录性别的列,只含有“ M”和“F”,则对此列进行索引没有多大用处(不管搜索哪个值,都会得出大约一半的行) 3. 使用短索引(最左前缀)。如果对串列进行索引,应该指定一个前缀长度。例如,如果有一个CHAR(200) 列,如果在前10 个或20 个字符内,多数值是惟一的,那么就不要对整个列进行索引。对前10 个或20 个字符进行索引能够节省大量索引空间,也可能会使查询更快。 4. 较小的索引涉及的磁盘I/O 较少,较短的值比较起来更快。更重要的是,对于较短的键值,索引高速缓存中的块能容纳更多的键值。
  • 24. 4.1.3 索引设计原则5. 不要过度索引。不要以为索引“越多越好”,什么东西都用索引是错的。每个额外的索引都要占用额外的磁盘空间,并降低写操作的性能。在修改表的内容时,索引必须进行更新,有时可能需要重构,因此,索引越多,所花的时间越长。如果有一个索引很少利用或从不使用,那么会不必要地减缓表的修改速度。此外,MySQL 在生成一个执行计划时,要考虑各个索引,这也要费时间。创建多余的索引给查询优化带来了更多的工作。索引太多,也可能会使MySQL 选择不到所要使用的最好索引。只保持所需的索引有利于查询优化。如果想给已索引的表增加索引,应该考虑所要增加的索引是否是现有多列索引的最左索引。如果是,则就不要费力去增加这个索引了,因为已经有了。 6. 考虑在列上进行的比较类型。索引可用于“ <”、“ < = ”、“ = ”、“ > =”、“ >”和BETWEEN 运算。在模式具有一个直接量前缀时,索引也用于LIKE 运算。如果只将某个列用于其他类型的运算时(如FROM_UNIXTIME (time )>?),对其进行索引没有价值。 Page:24
  • 25. 5.1 性能分析工具--explainPage:25执行计划包含的信息id:如果相同,可以认为是一组,从上往下顺序执行;在所有组中,id值越大,优先级越高,越先执行
  • 26. 5.1 性能分析工具--explainPage:26type:表示MySQL在表中找到所需行的方式,又称“访问类型”,常见类型如下:由左至右,由最差到最好ALL:Full Table Scan, MySQL将遍历全表以找到匹配的行 index:Full Index Scan,index与ALL区别为index类型只遍历索引树 range:索引范围扫描,对索引的扫描开始于某一点,返回匹配值域的行,常见于between、<、>等的查询 ref:非唯一性索引扫描,返回匹配某个单独值的所有行。常见于使用非唯一索引即唯一索引的非唯一前缀进行的查找 eq_ref:唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配。常见于主键或唯一索引扫描
  • 27. 5.1 性能分析工具--explainPage:27const、system:当MySQL对查询某部分进行优化,并转换为一个常量时,使用这些类型访问。如将主键置于where列表中,MySQL就能将该查询转换为一个常量 NULL:MySQL在优化过程中分解语句,执行时甚至不用访问表或索引 rows:表示MySQL根据表统计信息及索引选用情况,估算的找到所需的记录所需要读取的行数
  • 28. 5.1 性能分析工具--explainExtra:  该列包含MySQL解决查询的详细信息。 using filesort   正在使用文件排序 using index 只使用索引树中的信息而不需要进一步搜索读取实际的行来检索表中的信息 using temporary为了解决查询,MySQL需要创建一个临时表来容纳结果Page:28
  • 29. 5.2 性能分析工具--profilesPage:29开启:set session profiling=1; 使用方法: show profiles; show profile for query 2; show profile block io,cpu for query 2; show profile cpu,block io,memory,swaps for query 2; 关闭:set profiling=1; 只对当前session有效;退出、关闭session后,profiles失效。
  • 30. 6.1 SQL语句优化Page:30like 的优化: where username like '%abc%' 如果能确定username就是abc开头的,那么在使用like时请用 where username like 'abc%' 去掉了第一个百分号,这样可能会用到索引;如果是第一种写法,不可能用到索引。 in/not in 的优化 SELECT userid,termname FROM sys_user_info WHERE userid NOT in (SELECT userid FROM sys_user) 用下面join代替 SELECT a.userid,a.termname FROM sys_user_info a LEFT JOIN sys_user b ON a.userid =b.userid WHERE b.userid IS NULL 连接(JOIN).. 之所以更有效率一些,是因为 MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。
  • 31. 6.1 SQL语句优化Page:31join: left join、right join、inner join、cross join的区别 A left join B 的连接的记录数与A表的记录数同 A right join B 的连接的记录数与B表的记录数同 故:A left join B 等价 B right join A inner join:内连接 select * from a,b where a.id=b.id 这个语法是内连接的另外一种写法,其执行结果与inner join 一样 cross join:生成两张表的笛卡尔集
  • 32. 6.1 SQL语句优化Page:32小数据集驱动大数据集 Join 算法(Nested Loop Join), 实际上就是通过驱动表的结果集作为循环基础数据,然后一条一条的通过该结果集中的数据作为过滤条件到下一个表中查询数据,然后合并结果。如果还有第三个参与Join,则再通过前两个表的Join 结果集作为循环基础数据,再一次通过循环查询条件到第三个表中查询数据,如此往复。 where条件:仅仅使用最有效的过滤条件(能定位ID=1 就不用其他条件了)
  • 33. 6.1 SQL语句优化Page:33不在索引列做运算或者使用函数 SELECT orderid,productid,order_created FROM Orders WHERE TO_DAYS(CURRENT_DATE()) – TO_DAYS(order_created) <= 7; 在索引字段(order_created) 字段上使用了函数操作,我们修改为下面的模式 SELECT orderid,productid,order_created FROM Orders WHERE order_created >= CURRENT_DATE() - INTERVAL 7 DAY; 我们改写了语句,可以走索引了,但是where 条件中current_date()仍然是个不确定的值,结果集无法从query cache 中重用。再改写下: SELECT orderid,productid,order_created FROM Orders WHERE order_created >= '2012-09-19' - INTERVAL 7 DAY; 我们用具体的值代替了current_date()使得这个sql语句的所有部分变成了确认的值,结果集可以cache到qery cache 中被重用 只取所需的列,杜绝select *
  • 34. 6.1 SQL语句优化Page:34or 的优化 SELECT userid,username FROM sys_user WHERE userid ='dgr2840000005@xf' or userid='dgr2840000006@xf') 用下面join代替 SELECT userid,username FROM sys_user WHERE userid ='dgr2840000005@xf' union all SELECT userid,username FROM sys_user WHERE userid ='dgr2840000005@xf‘ 查询尽可能使用limit减少返回的行数,减少数据传输时间和带宽浪费。
  • 35. 6.1 SQL语句优化Page:35字符类型与值类型务必保持一致 示例:`remark` varchar(50) not null comment'备注、默认空' mysql>select id,remark from test1 where id=1 and remark=100; 1 row in set(0.14sec) mysql>select id,remark from test1 where id=1 and remark='100'; 1 row in set(0.05sec) ORDER BY 的实现与优化 在MySQL 中,ORDER BY 的实现有如下两种类型: 一种是通过有序索引而直接取得有序的数据,这样不用进行任何排序操作即可得到满足客户端要求的有序数据返回给客户端; 另外一种则需要通过MySQL 的排序算法将存储引擎中返回的数据进行排序然后再将排序后的数据返回给客户端。 优化综合考虑:是否需要排序,排序尽可能用到索引列
  • 36. 6.1 SQL语句优化Page:36千万不要 ORDER BY RAND(),这样用会使用索引无意义 SELECT userid,username FROM sys_user order by rand() limit 1; 改成这样会更好: 1.select count(*) from sys_user; 2.定义变量$rand=rand(1,总数) 3.select userid,username from sys_user limit $rand,1; 在Join表的时候使用相当类型的列(int对int),并将其索引 确认两个表中Join的字段是被建过索引的。这样,MySQL内部会启动为你优化Join的SQL语句的机制。而且,这些被用来Join的字段,应该是相同的类型的。例如:如果你要把 DECIMAL 字段和一个 INT 字段Join在一起,MySQL就无法使用它们的索引。对于那些STRING类型,还需要有相同的字符集才行。
  • 37. 7.1 插入语句优化--测试Page:37
  • 38. 7.2 插入语句优化Page:38分析:一次性插入几万数据导致程序缓慢、服务器无响应 1)insert into tables(...)values(...),(...),(...).....等上万数据 2)for(i=1;i<=100000;i++) do   insert into tables(...) values (...); done; 为什么慢
  • 39. 7.2 插入语句优化Page:39 索引越多数据容量越大、所用时间越长(也证明了索引越多对写入的影响),大量写操作表一定要规划好索引。 MyISAM表是表级锁,命令发送给数据库后,此表马上获得写锁;写锁优化级最高,此时其他用户只要涉及到到此表的任何操作(select、DML等)都将处于等待状态,但不会造成死锁。一般程序无响应都表现为:web服务的超时,造成用户无响应,但数据还是会保存进库。 如果此表并发读很高,有其他用户也在进行读操作,此时就会让插入时间倍数级增加,因为用户获得读锁后其他用户不允许写。 以上两写法对磁盘的I/O: 第一种远小于第二种,因此第一种更快。因为第一个一次IO,由于VALUES里的值很多,可以先把这些值insert buffer里面,合并之后一次可以写16K,一个页(N行的数据);但第2个每次只能写100字节,写16000次才写满一个页。(这里没做测试,估计刷到磁盘是按页16K不按块4K的大小写入)
  • 40. 7.2 插入语句优化Page:40怎样做 中和第一第二的写法(对于10万行数据一次写入): ALTER TABLE tbl_name DISABLE KEYS Insert into tbl_name(...)values(...),(...)... 此处1000行; ALTER TABLE tbl_name ENABLE KEYS 或:Insert delayed into tbl_name(...)values(...),(...)... 此处1000行; 上面先禁用索引---->插入数据---->重新创建索引。这将在写入磁盘前在内存中创建索引树,并且它更快,因为避免了大量磁盘搜索。结果索引树也被完美地平衡。 delayed: 当一个客户端使用INSERT DELAYED时,会立刻从服务器处得到一个确定,其实数据都被放在内存的队列中,并没有真正写入磁盘。并且行被排入队列,当表没有被其它线程使用时,此行被插入磁盘。使用INSERT DELAYED的另一个重要的好处是,来自许多客户端的插入被集中在一起,并被编写入一个块。这比执行许多独立的插入要快很多。Delayed 的含义是让insert 语句马上执行,其实数据都被放在内存的队列中,并没有真正写入磁盘; delayed:(需考虑业务需要)这样做的目的:为了解决在并行过程中的堵塞问题,允许其它的线程访问表,这也会获得好的性能,解决其他功能出现无响应。
  • 41. 7.2 插入语句优化Page:41海量更新时用 ALTER TABLE table_name DELAY_KEY_WRITE= 1; update ; ALTER TABLE table_name DELAY_KEY_WRITE=0; DELAY_KEY_WRITE 是指在表关闭之前,将对表的update 操作指跟新数据到磁盘,而不更新索引到磁盘,把对索引的更改记录在内存。这样MyISAM 表可以使索引更新更快。在关闭表的时候一起更新索引到磁盘。
  • 42. 8.1 查看状态Page:42查看各线程状态信息:show processlist; 关注sending data、lock table 查看数据库运行状态信息: 查看总连接数: show status like 'Connections%'; 服务器启动后已经同时使用的连接的最大数量: show status like 'Max_used_connections%'; 当前打开的表的数量: show status like 'Open_tables%'; 不能立即获得的表的锁的次数: show status like 'Table_locks_waited%'; 查询缓存被访问的次数 show status like '%Qcache_hits%';
  • 43. 8.2 启动故障排除Page:43数据库连不上,查看二个状态: telnet IP 3306; service mysql status; 或 ps -ef |grep mysql; 学会查看错误日志文件,一般情况下错误日志以计算机名命名,后缀名为.err的文件;可以使用cat localhostname.err查看 数据库能启动,但某些表无法打开,提示表不存在: 通常情况是由于权限不足引起,使用命令:chown -R mysql.mysql data/ 授予该数据库文件mysql权限即可
  • 44. 9.1 备份与恢复Page:44基于文件的备份(基于myisam引擎): 直接copy数据库文件的备份,通过这种备份时,应通过以下手法实现,避免数据的丢失: service mysql stop; tar zcvf data.tar.gz data; service mysql start; Innodb 基于文件备份:xtrabackup(大库不锁表) 基于mysqldump的备份: 1.数据库全备份(包含表结构,表数据,存储过程,自定义函数,视图等)mysqldump -uroot -pRoOt --opt --triggers -e -C -R avmcdb > ./avmcdbbak.sql 2.只对数据进行备份(导出格式全为数据,无表结构),但更改了表结构:mysqldump -uroot -pRoOt --opt --skip-triggers --skip-create-option --extended-insert=false -C -F -t -B data > ./baktest/bak.sql
  • 45. 9.1 备份与恢复Page:45mysqldump参数说明: -A:所有数据库、-B:指定的某一个数据库 -t:只导出数据,而不添加 CREATE TABLE 语句 -d:不导出任何数据,只导出数据库表结构。 -c: 导出的数据采用包含字段名的完整INSERT 方式,也就是把所有的值都写在一行。这么做能提高插入效率,但是可能会受到max_allowed_packet 参数的影响而导致插入失败。 -R: 导出存储过程以及自定义函数。 --triggers: 导出触发器 基于mysqldump的还原: mysqldump -uroot -pRoOt data< ./data.sql
  • 46. 10.1 查询日志Page:46二进制日志 也就是我们常说的binlog,MySQL 会将所有修改数据库数据的query 以二进制形式记录到日志文件中。当然,日志中并不仅限于query 语句这么简单,还包括每一条query 所执行的时间,所消耗的资源,以及相关的事务信息慢查询日志。 可通过“--log-bin[=file_name]”参数的显式指定才能开启,如果未指定file_name,则会在数据目录下记录为mysql-bin.******(*代表0~9 之间的某一个数字,来表示该日志的序号) 将二进制日志导出到文本: mysqlbinlog mysqlbin-log.000001 > /baktest/binlogexport.sql 根据日志点恢复: mysqlbinlog --start-position=4 --stop-position=106 mysqlbin-log.000001 | mysql -uroot -p 根据日期恢复: mysqlbinlog --start-datetime="2012-10-14 12:00:00" --stop-datetim="2012-10-15 12:00:00" /diskb/bin-logs/xxx_db-bin.000001 | mysql -u root
  • 47. 10.1 查询日志Page:47慢查询日志 慢查询日志中记录的是执行时间较长的query,慢查询日志采用的是简单的文本格式,可以通过各种文本编辑器查看其中的内容,记录了语句执行的时刻,执行所消耗的时间,执行用户,连接主机等相关信息。MySQL 还提供了专门用来分析满查询日志的工具程序mysqlslowdump,用来帮助数据库管理人员解决可能存在的性能问题。 访问次数最多的20个sql语句: mysqldumpslow -s c -t 20 host-slow.log 返回记录数最多的20个sql: mysqldumpslow -s r -t 20 host-slow.log 打开与关闭:set global slow_query_log=on/false; 查看慢查询日志信息:show variables like 'slow_query%';
  • 48. 10.1 查询日志Page:48通用查询日志 查询日志记录MySQL 中所有的query,体积比较大,开启后对性能也有较大的影响,所以请大家慎用该功能。一般只用于跟踪某些特殊的sql 性能问题才会短暂打开该功能 使用方法通慢查询日志一样。 查询:show variables like 'general_log%'; 打开/关闭:set global slow_query_log=on/false; 错误日志 错误日志记录了MyQL Server 运行过程中所有较为严重的警告和错误信息,以及MySQLServer 每次启动和关闭的详细信息。 以.err结尾,可通过cat、vi工具查看。
  • 49. 11. 压力测试Page:49mysqlslap mysqlslap是一个mysql官方提供的压力测试工具,通过模拟多个并发客户端访问mysql来执行测试。通过mysqlslap --help可以获得可用的选项。 参数介绍: --help:查看使用帮助 --concurrency代表并发数量,concurrency=10,50,100, 并发连接线程数分别是10、50、100个并发。 --iterations代表要运行这些测试多少次。 --auto-generate-sql 代表用系统自己生成的SQL脚本来测试。 --number-of-queries 代表总共要运行多少次查询。 --query 使用自定义脚本执行测试,例如可以调用自定义的一个存储过程或者sql语句来执行测试。 --create-schema 测试的schema,MySQL中schema也就是database --debug-info 代表要额外输出CPU以及内存的相关信息。
  • 50. 11. 压力测试Page:50其他参数配置 mysql> set global max_connections=1024; Query OK, 0 rows affected (0.00 sec) mysql> show VARIABLES like 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 1024 | +-----------------+-------+ 1 row in set (0.00 sec) 由于每个连接需要使用10M(stack size默认为10240)的内存,这样并发300个进程时,就消耗了10M X 300 = 3000M 内存,超过系统可用内存会导致报错。 解决办法: ulimit -s 512 通过修改”stack size“为512KB,这样并发300个进程就相当于系统默认的150个进程的内存使用量。
  • 51. 11. 压力测试使用实例: 使用自动生成的脚本测试,指定数据库和sql语句: mysqlslap --concurrency=50 --iterations=20 --create-schema='test' --query='select * from test;' --number-of-queries=200 --debug-info -uavmc -pAvMc -h192.168.5.218 Benchmark Average number of seconds to run all queries: 0.897 seconds Minimum number of seconds to run all queries: 0.081 seconds Maximum number of seconds to run all queries: 1.239 seconds Number of clients running queries: 50 Average number of queries per client: 4 说明:50个并发客户端,平均每个客户端4个查询,20次查询中最少的时间是0.081秒、 最多1.239秒、平均0.897秒。 Page:51
  • 52. 结束Page:52