-
如何通过慢查日志发现有问题的SQL？ 1.查询次数多且每次查询占用时间长的SQL 通常为pt-query-digest分析的前几个查询 2.IO大的SQL，数据库的主要瓶颈就在于IO 注意pt-query-digest分析中的Rows examine项。扫描行数多，占用io大 3.未命中索引的SQL 注意pt-query-digest分析中Rows examine（扫描行数）和Rows send（发送行数）的对比 如果这个比值比较大，说明索引命中率不高查看全部
-
part3查看全部
-
part2查看全部
-
part1查看全部
-
第三部分是具体执行的SQL语句相关的统计信息（Query 1）查看全部
-
第二部分是关于表和语句的统计 显示出来那些表调用次数最多，响应时间最长、以及相关的是什么操作查看全部
-
-limit 设置显示多少条分析结果（百分比）<br> pt-query-digest /opt/slow.log<br> 分析结果分为3部分，第一部分是头部，<br> Overall：慢查询日志中包含了多少sql（9.10k个），不同的查询共有多少（1.17k）个，<br> Time range：慢查询日志中包含sql的时间范围<br> 还有执行时间、锁定时间、总共发送的行数、总共扫描的行数、查询的大小 这里扫描的范围（2.38M）远远大于我们需要的行数（31.63k），也说明了索引的设置并不是很合理查看全部
-
使用 -t参数设置显示多少条（TopN） mysqldumpslow -t 3 /opt/slow.log 截图是输出结果。查看全部
-
如何发现有问题的SQL？ show variables like 'slow_query_log' 展现慢查询数据日志 set global slow_query_log_file = 'd:/mysql/sql_log/mysql-slow.log/'设置慢查询日志存放的位置 set global log_queries_not_using_indexes = on; 将没有索引的查询展现出来 set global long_query_time = 1;将查询语句在一秒以上的查询展现在日志中 show variables like '%log'; set global log_queries_not_using_indexes = on; 将没有索引的查询展现出来;记录未使用索引的查询。 show variables like 'slow%' ke可以看到慢查询日志是否开启以及慢查询日志的位置。 1,查看是否开启了慢查询日志：show variables like 'slow_query_log'; 2,查看所有日志状态： show variables like '%log', 若log_queries_not_using_indexes 为OFF，则设置未使用索引的查询：set global log_queries_not_using_indexes=on 3,查看慢查询状态：show variables like 'show%' 4,开启慢查询日志：set global slow_query_log=on查看全部
-
慢查日志格式： (1)执行时间 (2)用户主机信息 (3)执行信息(如：执行时间、锁定时间、发送行数、扫描行数) (4)执行时间 (5)执行内容 如下： # Time: 150419 15:21:31 # User@Host: root[root] @ localhost [127.0.0.1] Id: 45 # Query_time: 0.001000 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0 SET timestamp=1429428091; SET PROFILING=1;查看全部
-
数据库优化： 1、SQL及索引优化 结构良好的SQL（选择最优的SQL）、 有效索引（索引越多不但会造成写操作的效率下降、而且也会造成读操作效率下降） 2、数据库表结构（满足范式、考虑到查询语句的写法） （根据数据库设计范式，设计出简洁明了的表结构、减少数据的冗余； a、在设计表结构时候要想到怎么样对这个表数据进行查询 b、怎么样设计表结构才是有益于SQL写法的 SQL及索引的优化也是日常工作中所涉及到的最多的一种优化方式 3、系统配置 大多数情况下我们的mysql都是跑在linux上的，系统本身也是会有些限制： a、tcp/ip连接数的限制 b、打开文件数限制（重点） mysql都是基于文件的，每查询一个表时，需要打开一些文件， 一旦打开的文件数超过上限，文件就会无法打开、就会平分IO操作 c、安全性限制 4、 硬件优化 内存：越大越好、mysql查询修改都是load在内存中进行的。 CPU：并不是越多，性能提升就越好的、mysql会对cpu核数进行限制、甚至有些查询只会用到单核 硬盘：会影响IO，可以考虑换用SSD，固态硬盘等等 所以这种IO设备对数据库肯定是有良好的影响的，但是这只是表面、并不能解决mysql内部锁的问题 lock锁是保证数据完整性的一种机制, 虽然IO很快并不能解决阻塞，所以说硬件优化、其实是成本最高，效果最不明显的 如果没有良好的SQL及有效的索引，数据库查询造成大量的慢查询、大量的阻塞，随之并发量就会上去、并发量一上去loading 就会高，会造成应用缓慢查看全部
-
1、数据库优化的目的 避免出现页面访问错误 · 由于数据库连接tomeout产生页面5xx错误（服务器内部错误，由web、中间件、数据库等引起） · 由于慢查询造成页面无法加载（web及数据库的慢速查询到时页面无法加载，避免慢速查询和事物阻塞） · 由于阻塞造成数据无法提交（服务器内部锁的原因，在大并发更新某一个字段时产生阻塞，轻则影响服务器性能，数据库中有锁超时，阻塞超过一定的时间，事物就会被回滚，影响到业务，及收入） 增加数据库的稳定性 • 很多数据库问题都是由于低效的查询引起的 优化用户体验 • 流畅页面的访问速度 • 良好的网站功能体验查看全部
-
数据库优化，系统级的查看全部
-
表的水平拆分查看全部
-
表的垂直拆分查看全部
举报
0/150
提交
取消