1, 查看MySQL服务器配置信息 1. mysql> show variables; 2, 查看MySQL服务器运行的各种状态值 1. mysql> show global status; 3, 慢查询 1. mysql> show variables like ‘%slow%’; 2. +——————+——-+ 3. | Variable_name | Value | 4. +——————+——-+ 5. | log_slow_queries | OFF | 6. | slow_launch_time | 2 | 7. +——————+——-+ 8. mysql> show global status like ‘%slow%’; 9. +———————+——-+ 10. | Variable_name | Value | 11. +———————+——-+ 12. | Slow_launch_threads | 0 | 13. | Slow_queries | 279 | 多少条慢查询 14. +———————+——-+ slow_launch_time与long_query_time没有关系,slow_launch_time它是创建线程的一个阀值! 慢查询设置 MySQL在linux系统中的配置文件一般是是my.cnf找到[mysqld]下面加上 long_query_time=1 (超过1秒就记录) 4, 连接数 1. mysql> show variables like ‘max_connections’; 2. +—————–+——-+ 3. | Variable_name | Value | 4. +—————–+——-+ 5. | max_connections | 500 | 6. +—————–+——-+ 7. 8. mysql> show global status like ‘max_used_connections’; 9. +———————-+——-+ 10. | Variable_name | Value | 11. +———————-+——-+ 12. | Max_used_connections | 498 | 13. +———————-+——-+ 设置的最大连接数是500,而响应的连接数是498 max_used_connections / max_connections * 100% = 99.6% (理想值 ≈ 85%) 5, key_buffer_size key_buffer_size是对MyISAM表性能影响最大的一个参数, 不过数据库中多为Innodb 1. mysql> show variables like ‘key_buffer_size’; 2. +—————–+———-+ 3. | Variable_name | Value | 4. +—————–+———-+ 5. | key_buffer_size | 67108864 | 6. +—————–+———-+ 7. 8. mysql> show global status like ‘key_read%’; 9. +——————-+———-+ 10. | Variable_name | Value | 11. +——————-+———-+ 12. | Key_read_requests | 25629497 | 13. | Key_reads | 66071 | 14. +——————-+———-+ 一共有25629497个索引读取请求,有66071个请求在内存中没有找到直接从硬盘读取索引,计算索引未命中缓存的概率: key_cache_miss_rate = Key_reads / Key_read_requests * 100% =0.27% 需要适当加大key_buffer_size 1. mysql> show global status like ‘key_blocks_u%’; 2. +——————-+——-+ 3. | Variable_name | Value | 4. +——————-+——-+ 5. | Key_blocks_unused | 10285 | 6. | Key_blocks_used | 47705 | 7. +——————-+——-+ Key_blocks_unused表示未使用的缓存簇(blocks)数,Key_blocks_used表示曾经用到的最大的blocks数 Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 18% (理想值 ≈ 80%) 6,临时表 1. mysql> show global status like ‘created_tmp%’; 2. +————————-+———+ 3. | Variable_name | Value | 4. +————————-+———+ 5. | Created_tmp_disk_tables | 4184337 | 6. | Created_tmp_files | 4124 | 7. | Created_tmp_tables | 4215028 | 8. +————————-+———+ 每次创建临时表,Created_tmp_tables增加,如果是在磁盘上创建临时表,Created_tmp_disk_tables也增加,Created_tmp_files表示 MySQL服务创建的临时文件文件数: Created_tmp_disk_tables / Created_tmp_tables * 100% = 99% (理想值<= 25%) 1. mysql> show variables where Variable_name in (‘tmp_table_size‘, ‘max_heap_table_size‘); 2. +———————+———–+ 3. | Variable_name | Value | 4. +———————+———–+ 5. | max_heap_table_size | 134217728 | 计算内存中最大行数的值 6. | tmp_table_size | 134217728 | 内部内存临时表的最大值 7. +———————+———–+ 主要查看Created_tmp_disk_tables这个值在高峰时每秒速率值,如果盲目的增加tmp_table_size值的话,那么多条执行语句并发,就会导致内存堵塞! 7,open table 的情况 1. mysql> show global status like ‘open%tables%’; 2. +—————+——-+ 3. | Variable_name | Value | 4. +—————+——-+ 5. | Open_tables | 1024 | 6. | Opened_tables | 1465 | 7. +—————+——-+ Open_tables 表示打开表的数量, Opened_tables表示打开过的表数量,如果Opened_tables数量过大,说明配置中 table_cache(5.1.3 之后这个值叫做table_open_cache)值可能太小,我们查询一下服务器table_cache值 1. mysql> show variables like ‘table_cache’; 2. +—————+——-+ 3. | Variable_name | Value | 4. +—————+——-+ 5. | table_cache | 1024 | 6. +—————+——-+ Open_tables / Opened_tables * 100% =69% 理想值 (>= 85%) Open_tables / table_cache * 100% = 100% 理想值 (<= 95%) 8, 进程使用情况 1. mysql> show global status like ‘Thread%’; 2. +——————-+——-+ 3. | Variable_name | Value | 4. +——————-+——-+ 5. | Threads_cached | 31 | 代表当前此时此刻线程缓存中有多少空闲线程。 6. | Threads_connected | 239 |代表当前已建立连接的数量,因为一个连接就需要一个线程,所以也可以看成当前被使用的线程数。 7. | Threads_created | 2914 |代表从最近一次服务启动,已创建线程的数量。 8. | Threads_running | 4 |代表当前激活的(非睡眠状态)线程数。并不是代表正在使用的线程数,有时候连接已建立,但是连接处于sleep状态,这里相对应的线程也是sleep状态。 9. +——————-+——-+ 如果我们在MySQL服务器配置文件中设置了thread_cache_size,当客户端断开之后,服务器处理此客户的线程将会缓存起来以响应 下一个客户而不是销毁(前提是缓存数未达上限)。Threads_created表示创建过的线程数,如果发现Threads_created值过大的话, 表明 MySQL服务器一直在创建线程,这也是比较耗资源,可以适当增加配置文件中thread_cache_size值,查询服务器 thread_cache_size配置: 1. mysql> show variables like ‘thread_cache_size’; 2. +——————-+——-+ 3. | Variable_name | Value | 4. +——————-+——-+ 5. | thread_cache_size | 32 | 6. +——————-+——-+ 9, 查询缓存(query cache) 1. mysql> show global status like ‘qcache%’; 2. +————————-+———-+ 3. | Variable_name | Value | 4. +————————-+———-+ 5. | Qcache_free_blocks | 2226 | 6. | Qcache_free_memory | 10794944 | 7. | Qcache_hits | 5385458 | 8. | Qcache_inserts | 1806301 | 9. | Qcache_lowmem_prunes | 433101 | 10. | Qcache_not_cached | 4429464 | 11. | Qcache_queries_in_cache | 7168 | 12. | Qcache_total_blocks | 16820 | 13. +————————-+———-+ Qcache_free_blocks:缓存中相邻内存块的个数。数目大说明可能有碎片。 Mysql>FLUSH QUERY CACHE会对缓存中的碎片进行整理,从 而得到一个空闲块。 Qcache_free_memory:缓存中的空闲内存。 Qcache_hits:每次查询在缓存中命中时就增大 Qcache_inserts:每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。 Qcache_lowmem_prunes:缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个数字在不断增长,就表示可能碎片非常严重,或者内存很少。(上面的 free_blocks和free_memory可以告诉您属于哪种情况) Qcache_not_cached:不适合进行缓存的查询的数量,通常是由于这些查询不是 SELECT 语句或者用了now()之类的函数。 Qcache_queries_in_cache:当前缓存的查询(和响应)的数量。 Qcache_total_blocks:缓存中块的数量。 我们再查询一下服务器关于query_cache的配置: 1. mysql> show variables like ‘query_cache%’; 2. +——————————+———-+ 3. | Variable_name | Value | 4. +——————————+———-+ 5. | query_cache_limit | 33554432 | 6. | query_cache_min_res_unit | 4096 | 7. | query_cache_size | 33554432 | 8. | query_cache_type | ON | 9. | query_cache_wlock_invalidate | OFF | 10. +——————————+———-+ 各字段的解释: query_cache_limit:超过此大小的查询将不缓存 query_cache_min_res_unit:缓存块的最小大小 query_cache_size:查询缓存大小 query_cache_type:缓存类型,决定缓存什么样的查询,示例中表示不缓存 select sql_no_cache 查询 query_cache_wlock_invalidate:当有其他客户端正在对MyISAM表进行写操作时,如果查询在query cache中,是否返回cache结 果还是等写操作完成再读表获取结果。 query_cache_min_res_unit的配置是一柄”双刃剑”,默认是4KB,设置值大对大数据查询有好处,但如果你的查询都是小数据查询, 就容易造成内存碎片和浪费。 查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100% 如果查询缓存碎片率超过20%,可以用FLUSH QUERY CACHE整理缓存碎片,或者试试减小query_cache_min_res_unit,如果你 的查询都是小数据量的话。 查询缓存利用率 = (query_cache_size – Qcache_free_memory) / query_cache_size * 100% 查询缓存利用率在25%以下的话说明query_cache_size设置的过大,可适当减小;查询缓存利用率在80%以上而且 Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小,要不就是碎片太多。 查询缓存命中率 = (Qcache_hits – Qcache_inserts) / Qcache_hits * 100% 示例服务器 查询缓存碎片率 = 20.46%,查询缓存利用率 = 62.26%,查询缓存命中率 = 1.94%,命中率很差,可能写操作比较 频繁吧,而且可能有些碎片。 10,排序使用情况 1. mysql> show global status like ‘sort%’; 2. +——————-+———-+ 3. | Variable_name | Value | 4. +——————-+———-+ 5. | Sort_merge_passes | 2136 | 6. | Sort_range | 81888 | 7. | Sort_rows | 35918141 | 8. | Sort_scan | 55269 | 9. +——————-+———-+ Sort_merge_passes 包括两步。MySQL 首先会尝试在内存中做排序,使用的内存大小由系统变量 Sort_buffer_size 决定,如果它的 大小不够把所有的记录都读到内存中,MySQL 就会把每次在内存中排序的结果存到临时文件中,等 MySQL 找到所有记录之后,再 把临时文件中的记录做一次排序。这再次排序就会增加 Sort_merge_passes。实际上,MySQL 会用另一个临时文件来存再次排序的 结果,所以通常会看到 Sort_merge_passes 增加的数值是建临时文件数的两倍。因为用到了临时文件,所以速度可能会比较慢,增 加 Sort_buffer_size 会减少 Sort_merge_passes 和 创建临时文件的次数。但盲目的增加 Sort_buffer_size 并不一定能提高速度, 见 How fast can you sort data with MySQL?(引自http://qroom.blogspot.com/2007/09/mysql-select-sort.html) 另外,增加read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值对排序的操作也有一点的好处,参见: http://www.mysqlperformanceblog.com/2007/07/24/what-exactly-is- read_rnd_buffer_size/ 11.文件打开数(open_files) 1. mysql> show global status like ‘open_files’; 2. +—————+——-+ 3. | Variable_name | Value | 4. +—————+——-+ 5. | Open_files | 821 | 6. +—————+——-+ 7. 8. mysql> show variables like ‘open_files_limit’; 9. +——————+——-+ 10. | Variable_name | Value | 11. +——————+——-+ 12. | open_files_limit | 65535 | 13. +——————+——-+ 比较合适的设置:Open_files / open_files_limit * 100% <= 75% 正常 12, 表锁情况 1. mysql> show global status like ‘table_locks%’; 2. +———————–+———+ 3. | Variable_name | Value | 4. +———————–+———+ 5. | Table_locks_immediate | 4257944 | 6. | Table_locks_waited | 25182 | 7. +———————–+———+ Table_locks_immediate 表示立即释放表锁数,Table_locks_waited表示需要等待的表锁数,如果 Table_locks_immediate / Table_locks_waited > 5000,最好采用InnoDB引擎,因为InnoDB是行锁而MyISAM是表锁,对于高并发写入的应用InnoDB效果 会好些. 13. 表扫描情况 1. mysql> show global status like ‘handler_read%’; 2. +———————–+———–+ 3. | Variable_name | Value | 4. +———————–+———–+ 5. | Handler_read_first | 108763 | 6. | Handler_read_key | 92813521 | 7. | Handler_read_next | 486650793 | 8. | Handler_read_prev | 688726 | 9. | Handler_read_rnd | 9321362 | 10. | Handler_read_rnd_next | 153086384 | 11. +———————–+———–+ 各字段解释参见http://hi.baidu.com/thinkinginlamp/blog/item/31690cd7c4bc5cdaa144df9c.html,调出服务器完成的查询请求次数: 1. mysql> show global status like ‘com_select’; 2. +—————+———+ 3. | Variable_name | Value | 4. +—————+———+ 5. | Com_select | 2693147 | 6. +—————+———+ 计算表扫描率: 表扫描率 = Handler_read_rnd_next / Com_select 如果表扫描率超过4000,说明进行了太多表扫描,很有可能索引没有建好,增加read_buffer_size值会有一些好处,但最好不要超过 8MB。 |
通过mysql show语句来优化mysql
时间: 2024-10-07 18:57:33
通过mysql show语句来优化mysql的相关文章
Mysql insert语句的优化
1) 如果你同时从同一客户插入很多行,使用多个值表的INSERT语句.这比使用分开INSERT语句快(在一些情况中几倍). Insert into test values(1,2),(1,3),(1,4)- 2) 如果你从不同客户插入很多行,能通过使用INSERT DELAYED语句得到更高的速度.Delayed的含义是让insert 语句马上执行,其实数据都被放在内存的队列中,并没有真正写入磁盘:这比每条语句分别插入要快的多:LOW_PRIORITY刚好相反,在所有其他用户对表的读写完后
MySQL循环语句实例教程 mysql while循环测试
在mysql数据库中操作同样有循环语句操作,标准的循环方式: while 循环 . loop 循环和repeat循环.还有一种非标准的循环: goto. 鉴于goto 语句的跳跃性会造成使用的的思维混乱,所以不建议使用. 这几个循环语句的格式如下:WHILE……DO……END WHILEREPEAT……UNTIL END REPEATLOOP……END LOOPGOTO.目前我只测试了 while 循环:delimiter $$ // 定义结束符为 $$ drop procedure if ex
MySQL 百万级分页优化(Mysql千万级快速分页)
以下分享一点我的经验 一般刚开始学SQL的时候,会这样写 : SELECT * FROM table ORDER BY id LIMIT 1000, 10; 但在数据达到百万级的时候,这样写会慢死 : SELECT * FROM table ORDER BY id LIMIT 1000000, 10; 也许耗费几十秒 网上很多优化的方法是这样的: SELECT * FROM table WHERE id >= (SELECT id FROM table LIMIT 1000000, 1) LIM
(转)MySQL慢查询分析优化 + MySQL调优
1.long_query_time的默认值为10,意思是运行10S以上的语句. 2.临时设置开启慢查询日志 mysql> show variables like '%slow_query_log%'; +---------------------+------------------------------------------+ | Variable_name | Value | +---------------------+---------------------------------
第04章 mysql SQL语句
2015-10-24 目录 参考资料 [1] 唐汉明.深入浅出MySQL 数据库开发.优化与管理维护(第2版)[M].北京:人民邮电出版社,2014 [2] Schwartz.高性能MySQL(第3版)[M].北京:电子工业出版社,2013 [3] 范德兰斯.MySQL开发者SQL权威指南 [M].北京:机械工业出版社,2008 [4] Forta.MySQL必知必会 [M].北京:人民邮电出版社,2009 [5] mysql sql语句大全 [6] MySQL 最基本的SQL语法/语句 [7]
千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记
千万级记录的Discuz论坛导致MySQL CPU 100%的优化笔记 2007年3月,我写过一篇文章<解决一个 MySQL 服务器进程 CPU 占用 100%的技术笔记>( http://www.xiaohui.com/weekly/20070307.htm ),谈到自己在解决一个拥有 60 万条记录的 MySQL 数据库访问时,导致 MySQL CPU 占用 100% 的经过.在解决问题完成优化(optimize)之后,我发现 Discuz 论坛也存在这个问题,当时稍微提了一下: 发现此主
MySQL 查询语句优化思路
query 语句的优化思路和原则主要提现在以下几个方面:1. 优化更需要优化的Query:2. 定位优化对象的性能瓶颈:3. 明确的优化目标:4. 从 Explain 入手:5. 多使用profile6. 永远用小结果集驱动大的结果集:7. 尽可能在索引中完成排序:8. 只取出自己需要的Columns:9. 仅仅使用最有效的过滤条件:10. 尽可能避免复杂的Join和子查询 关于explain 用法:explain select * from tables1 where 1 ... 先看一下在
【夯实Mysql基础】记一次mysql语句的优化过程!
1. [事件起因] 今天在做项目的时候,发现提供给客户端的接口时间很慢,达到了2秒多,我第一时间,抓了接口,看了运行的sql,发现就是 2个sql慢,分别占了1秒多. 一个sql是 链接了5个表同时使用了 2个 order by和 1个limit的分页 sql. 一个sql是上一个sql的count(*),即链接了5个表,当然没有limit了(取总数). 2. [着手优化] 1)[优化思路] 第一条是 做client调用 service层的数据缓存 第二条就是 优化sql本身. 这里着重讲一下
MySql数据库3【优化2】sql语句的优化
1.SELECT语句优化 1).利用LIMIT 1取得唯一行[控制结果集的行数] 有时,当你要查询一张表是,你知道自己只需要看一行.你可能会去的一条十分独特的记录,或者只是刚好检查了任何存在的记录数,他们都满足了你的WHERE子句.在这种情况下,增加一个LIMIT 1会令你的查询更加有效.这样数据库引擎发现只有1后将停止扫描,而不是去扫描整个表或索引. 2).不要使用BY RAND()命令 这是一个令很多新手程序员会掉进去的陷阱.你可能不知不觉中制造了一个可怕的平静.这个陷阱在你是用BY RAN