优化、分析Mysql表读写、索引等操作的sql语句效率优化问题

为什么要优化:

随着实际项目的启动,数据库经过一段时间的运行,最初的数据库设置,会与实际数据库运行性能会有一些差异,这时我们 就需要做一个优化调整。

数据库优化这个课题较大,可分为四大类:

》主机性能
》内存使用性能
》网络传输性能
》SQL语句执行性能【软件工程师】
下面列出一些数据库SQL优化方案:

(01)选择最有效率的表名顺序(笔试常考)

数据库的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表放在最后,如果有3个以上的表连接查询,那就需要选择那个被其他表所引用的表放在最后。

例如:查询员工的编号,姓名,工资,工资等级,部门名

select emp.empno,emp.ename,emp.sal,salgrade.grade,dept.dname
from salgrade,dept,emp
where (emp.deptno = dept.deptno) and (emp.sal between salgrade.losal and salgrade.hisal)

1)如果三个表是完全无关系的话,将记录和列名最少的表,写在最后,然后依次类推
2)如果三个表是有关系的话,将引用最多的表,放在最后,然后依次类推

(02)WHERE子句中的连接顺序(笔试常考)

数据库采用自右而左的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之左,那些可以过滤掉最大数量记录的条件必须写在WHERE子句的之右。

例如:查询员工的编号,姓名,工资,部门名

select emp.empno,emp.ename,emp.sal,dept.dname
from emp,dept
where (emp.deptno = dept.deptno) and (emp.sal > 1500)

(03)SELECT子句中避免使用*号

数据库在解析的过程中,会将*依次转换成所有的列名,这个工作是通过查询数据字典完成的,这意味着将耗费更多的时间

select empno,ename from emp;
(04)用TRUNCATE替代DELETE

(05)尽量多使用COMMIT

因为COMMIT会释放回滚点

(06)用WHERE子句替换HAVING子句

WHERE先执行,HAVING后执行

(07)多使用内部函数提高SQL效率

(08)使用表的别名

salgrade s

(09)使用列的别名

ename e

总之,数据库优化不是一天的课题,你得在长期工作实践中,进行反复测试与总结,希望学员们日后好好领会

今天我们分享一些 分析mysql表读写、索引等等操作的sql语句。

闲话不多说,直接上代码:

反映表的读写压力

SELECT file_name AS file,
count_read,
sum_number_of_bytes_read AS total_read,
count_write,
sum_number_of_bytes_write AS total_written,
(sum_number_of_bytes_read + sum_number_of_bytes_write) AS total
FROM performance_schema.file_summary_by_instance
ORDER BY sum_number_of_bytes_read+ sum_number_of_bytes_write DESC;

反映文件的延迟

SELECT (file_name) AS file,
count_star AS total,
CONCAT(ROUND(sum_timer_wait / 3600000000000000, 2), ‘h‘) AS total_latency,
count_read,
CONCAT(ROUND(sum_timer_read / 1000000000000, 2), ‘s‘) AS read_latency,
count_write,
CONCAT(ROUND(sum_timer_write / 3600000000000000, 2), ‘h‘)AS write_latency
FROM performance_schema.file_summary_by_instance
ORDER BY sum_timer_wait DESC;

table 的读写延迟

SELECT object_schema AS table_schema,
object_name AS table_name,
count_star AS total,
CONCAT(ROUND(sum_timer_wait / 3600000000000000, 2), ‘h‘) as total_latency,
CONCAT(ROUND((sum_timer_wait / count_star) / 1000000, 2), ‘us‘) AS avg_latency,
CONCAT(ROUND(max_timer_wait / 1000000000, 2), ‘ms‘) AS max_latency
FROM performance_schema.objects_summary_global_by_type
ORDER BY sum_timer_wait DESC;

查看表操作频度

SELECT object_schema AS table_schema,
object_name AS table_name,
count_star AS rows_io_total,
count_read AS rows_read,
count_write AS rows_write,
count_fetch AS rows_fetchs,
count_insert AS rows_inserts,
count_update AS rows_updates,
count_delete AS rows_deletes,
CONCAT(ROUND(sum_timer_fetch / 3600000000000000, 2), ‘h‘) AS fetch_latency,
CONCAT(ROUND(sum_timer_insert / 3600000000000000, 2), ‘h‘) AS insert_latency,
CONCAT(ROUND(sum_timer_update / 3600000000000000, 2), ‘h‘) AS update_latency,
CONCAT(ROUND(sum_timer_delete / 3600000000000000, 2), ‘h‘) AS delete_latency
FROM performance_schema.table_io_waits_summary_by_table
ORDER BY sum_timer_wait DESC ;

索引状况

SELECT OBJECT_SCHEMA AS table_schema,
OBJECT_NAME AS table_name,
INDEX_NAME as index_name,
COUNT_FETCH AS rows_fetched,
CONCAT(ROUND(SUM_TIMER_FETCH / 3600000000000000, 2), ‘h‘) AS select_latency,
COUNT_INSERT AS rows_inserted,
CONCAT(ROUND(SUM_TIMER_INSERT / 3600000000000000, 2), ‘h‘) AS insert_latency,
COUNT_UPDATE AS rows_updated,
CONCAT(ROUND(SUM_TIMER_UPDATE / 3600000000000000, 2), ‘h‘) AS update_latency,
COUNT_DELETE AS rows_deleted,
CONCAT(ROUND(SUM_TIMER_DELETE / 3600000000000000, 2), ‘h‘)AS delete_latency
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NOT NULL
ORDER BY sum_timer_wait DESC;

全表扫描情况

SELECT object_schema,
object_name,
count_read AS rows_full_scanned
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NULL
AND count_read > 0
ORDER BY count_read DESC;
没有使用的index

SELECT object_schema,
object_name,
index_name
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NOT NULL
AND count_star = 0
AND object_schema not in (‘mysql‘,‘v_monitor‘)
AND index_name <> ‘PRIMARY‘
ORDER BY object_schema, object_name;

糟糕的sql问题摘要

SELECT (DIGEST_TEXT) AS query,
SCHEMA_NAME AS db,
IF(SUM_NO_GOOD_INDEX_USED > 0 OR SUM_NO_INDEX_USED > 0, ‘*‘, ‘‘) AS full_scan,
COUNT_STAR AS exec_count,
SUM_ERRORS AS err_count,
SUM_WARNINGS AS warn_count,
(SUM_TIMER_WAIT) AS total_latency,
(MAX_TIMER_WAIT) AS max_latency,
(AVG_TIMER_WAIT) AS avg_latency,
(SUM_LOCK_TIME) AS lock_latency,
format(SUM_ROWS_SENT,0) AS rows_sent,
ROUND(IFNULL(SUM_ROWS_SENT / NULLIF(COUNT_STAR, 0), 0)) AS rows_sent_avg,
SUM_ROWS_EXAMINED AS rows_examined,
ROUND(IFNULL(SUM_ROWS_EXAMINED / NULLIF(COUNT_STAR, 0), 0)) AS rows_examined_avg,
SUM_CREATED_TMP_TABLES AS tmp_tables,
SUM_CREATED_TMP_DISK_TABLES AS tmp_disk_tables,
SUM_SORT_ROWS AS rows_sorted,
SUM_SORT_MERGE_PASSES AS sort_merge_passes,
DIGEST AS digest,
FIRST_SEEN AS first_seen,
LAST_SEEN as last_seen
FROM performance_schema.events_statements_summary_by_digest d
where d
ORDER BY SUM_TIMER_WAIT DESC
limit 20;

掌握这些sql,你能轻松知道你的库那些表存在问题,然后考虑怎么去优化。

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对脚本之家的支持。如果你想了解更多相关内容请查看下面相关链接

原文地址:https://www.cnblogs.com/hnsongbiao/p/11070014.html

时间: 2024-10-07 04:52:39

优化、分析Mysql表读写、索引等操作的sql语句效率优化问题的相关文章

Mysql表读写、索引等操作的sql语句效率优化问题

上次我们说到mysql的一些sql查询方面的优化,包括查看explain执行计划,分析索引等等.今天我们分享一些 分析mysql表读写.索引等等操作的sql语句. 闲话不多说,直接上代码: 反映表的读写压力 SELECT file_name AS file, count_read, sum_number_of_bytes_read AS total_read, count_write, sum_number_of_bytes_write AS total_written, (sum_number

SQL语句效率优化--持续更新

1 delete与in搭配使用,效率特别低,如下可解决该问题,not in同理 /*正常写法*/ DELETE from activity where id in ( SELECT id from activity_data); /*优化后写法*/ DELETE from activity where id in (select * from (SELECT id from activity_data) t); 原文地址:https://www.cnblogs.com/cdut-yy/p/120

MySql数据库3【优化2】sql语句的优化

1.SELECT语句优化 1).利用LIMIT 1取得唯一行[控制结果集的行数] 有时,当你要查询一张表是,你知道自己只需要看一行.你可能会去的一条十分独特的记录,或者只是刚好检查了任何存在的记录数,他们都满足了你的WHERE子句.在这种情况下,增加一个LIMIT 1会令你的查询更加有效.这样数据库引擎发现只有1后将停止扫描,而不是去扫描整个表或索引. 2).不要使用BY RAND()命令 这是一个令很多新手程序员会掉进去的陷阱.你可能不知不觉中制造了一个可怕的平静.这个陷阱在你是用BY RAN

SQL语句的优化

一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一.系统优化中一个很重要的方面就是SQL语句的优化.对于海量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就可,而是要写出高质量的SQL语句,提高系统的可用性. 在多数情况下,Oracle使用索

谈谈SQL 语句的优化技术

在SQL server 的性能优化过程中,TSQL的语句优化是很重要的一环.当您使用各种手段找出系统最需要优化的语句后,应该如何对该语句进行优化呢?下面列出一些TSQL 语句优化的常见技巧. 1.     语句的执行计划分析 首先要对该语句的执行计划(execution plan)进行分析,找出语句运行慢的原因.比如说, <>在检查执行计划是否包含table scan /index scan等昂贵的操作? <>对table, worktable是否进行了大量的逻辑读? <&g

SQL语句性能优化--LECCO SQL Expert

SQL语句的优化是将性能低下的SQL语句转换成目的相同的性能优异的SQL语句. 人工智能自动SQL优化就是使用人工智能技术,自动对SQL语句进行重写,从而找到性能最好的等效SQL语句. 数据库性能的优化   一个数据库系统的生命周期可以分成:设计.开发和成品三个阶段.在设计阶段进行数据库性能优化的成本最低,收益最大.在成品阶段进行数据库性能优化的成本最高,收益最小. 数据库的优化通常可以通过对网络.硬件.操作系统.数据库参数和应用程序的优化来进行.最常见的优化手段就是对硬件的升级.根据统计,对网

关于sql语句的优化

最近在做mysql的数据库优化以及对sql语句优化的指导,写了一点文档,这个大家共勉一下! 数据库参数进行优化所获得的性能提升全部加起来只占数据库应用系统性能提升的40%左右,其余60%的系统性能提升全部来自对应用程序的优化.许多优化专家甚至认为对应用程序的优化可以得到80%的系统性能提升.因此可以肯定,通过优化应用程序来对数据库系统进行优化能获得更大的收益. 通常可分为两个方面: SQL语句的优化和数据库性能调优.应用程序对数据库的操作最终要表现为SQL语句对数据库的操作.而数据库性能调优是结

Oracle数据库的sql语句性能优化

在应用系统开发初期,由于开发数据库数据比较少,对于查询sql语句,复杂试图的编写等体会不出sql语句各种写法的性能优劣,但是如果将应用系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要问题之一.系统优化中一个很重要的方面就是sql语句的优化.对于海量数据,劣质sql语句和优质sql语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就行,而是要写出高质量的sql语句,提高系统的可用性. Oracle的sql调优第一个复杂的主题,甚至需要长

SQL语句常见优化十大案例

1.慢SQL消耗了70%~90%的数据库CPU资源: 2.SQL语句独立于程序设计逻辑,相对于对程序源代码的优化,对SQL语句的优化在时间成本和风险上的代价都很低:3.SQL语句可以有不同的写法: 下面是我总结的一些SQL常见的优化方法,每个案例都简单易懂,在开发过程中可以作为参考: 1.不使用子查询例:SELECT * FROM t1 WHERE id (SELECT id FROM t2 WHERE name='hechunyang');子查询在MySQL5.5版本里,内部执行计划器是这样执