优化sql一般步骤

已于 2022-08-08 15:36:42 修改
阅读量337 收藏 1
点赞数
分类专栏： Java随笔 文章标签： 数据库 sql mysql
于 2022-08-08 15:32:38 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_50379749/article/details/126228528
版权

优化sql一般步骤

文章目录


sql提供：http://downloads.mysql.com/docs/sakila-db.zip

原文：《深入浅出MySQL++数据库开发、优化与管理维护》

压缩文件中3个文件：sakila.schema.sql是表结构创建，sakila-data是表数据，sakila.mwb是数据模型

1.通过shou status 命令了解各种sql执行频率
SHOW SESSION STATUS

或者

SHOW GLOBAL STATUS

session级: 当前连接的统计结果

global级: 自数据库上次启动至今的统计结果

两个级别可以省略不写，默认是session级

执行以下命令，like ‘Com_%’ 表示匹配Com_xxx的属性，因为这里面通常有我们关心的参数

SHOW STATUS LIKE 'Com_%'

得到结果：

+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Com_admin_commands          | 0     |
| Com_assign_to_keycache      | 0     |
| Com_alter_db                | 0     |
| Com_alter_db_upgrade        | 0     |
| Com_alter_event             | 0     |
| Com_alter_function          | 0     |
| Com_alter_instance          | 0     |
| Com_alter_procedure         | 0     |
| Com_alter_server            | 0     |
| Com_alter_table             | 0     |
| Com_alter_tablespace        | 0     |
| Com_alter_user              | 0     |
| Com_analyze                 | 0     |
| Com_begin                   | 0     |
| Com_binlog                  | 0     |
| Com_call_procedure          | 0     |
| Com_change_db               | 0     |
| Com_change_master           | 0     |
| Com_change_repl_filter      | 0     |
| Com_check                   | 0     |
| Com_checksum                | 0     |
| Com_commit                  | 0     |
| Com_create_db               | 0     |
| Com_create_event            | 0     |
| Com_create_function         | 0     |
| Com_create_index            | 0     |
| Com_create_procedure        | 0     |
| Com_create_server           | 0     |
| Com_create_table            | 0     |
| Com_create_trigger          | 0     |
| Com_create_udf              | 0     |
| Com_create_user             | 0     |
| Com_create_view             | 0     |
| Com_dealloc_sql             | 0     |
| Com_delete                  | 0     |
| Com_delete_multi            | 0     |
| Com_do                      | 0     |
| Com_drop_db                 | 0     |
| Com_drop_event              | 0     |
| Com_drop_function           | 0     |
| Com_drop_index              | 0     |
| Com_drop_procedure          | 0     |
| Com_drop_server             | 0     |
| Com_drop_table              | 0     |
| Com_drop_trigger            | 0     |
| Com_drop_user               | 0     |
| Com_drop_view               | 0     |
| Com_empty_query             | 0     |
| Com_execute_sql             | 0     |
| Com_explain_other           | 0     |
| Com_flush                   | 0     |
| Com_get_diagnostics         | 0     |
| Com_grant                   | 0     |
| Com_ha_close                | 0     |
| Com_ha_open                 | 0     |
| Com_ha_read                 | 0     |
| Com_help                    | 0     |
| Com_insert                  | 0     |
| Com_insert_select           | 0     |
| Com_install_plugin          | 0     |
| Com_kill                    | 0     |
| Com_load                    | 0     |
| Com_lock_tables             | 0     |
| Com_optimize                | 0     |
| Com_preload_keys            | 0     |
| Com_prepare_sql             | 0     |
| Com_purge                   | 0     |
| Com_purge_before_date       | 0     |
| Com_release_savepoint       | 0     |
| Com_rename_table            | 0     |
| Com_rename_user             | 0     |
| Com_repair                  | 0     |
| Com_replace                 | 0     |
| Com_replace_select          | 0     |
| Com_reset                   | 0     |
| Com_resignal                | 0     |
| Com_revoke                  | 0     |
| Com_revoke_all              | 0     |
| Com_rollback                | 0     |
| Com_rollback_to_savepoint   | 0     |
| Com_savepoint               | 0     |
| Com_select                  | 1     |
| Com_set_option              | 0     |
| Com_signal                  | 0     |
| Com_show_binlog_events      | 0     |
| Com_show_binlogs            | 0     |
| Com_show_charsets           | 0     |
| Com_show_collations         | 0     |
| Com_show_create_db          | 0     |
| Com_show_create_event       | 0     |
| Com_show_create_func        | 0     |
| Com_show_create_proc        | 0     |
| Com_show_create_table       | 0     |
| Com_show_create_trigger     | 0     |
| Com_show_databases          | 0     |
| Com_show_engine_logs        | 0     |
| Com_show_engine_mutex       | 0     |
| Com_show_engine_status      | 0     |
| Com_show_events             | 0     |
| Com_show_errors             | 0     |
| Com_show_fields             | 0     |
| Com_show_function_code      | 0     |
| Com_show_function_status    | 0     |
| Com_show_grants             | 0     |
| Com_show_keys               | 0     |
| Com_show_master_status      | 0     |
| Com_show_open_tables        | 0     |
| Com_show_plugins            | 0     |
| Com_show_privileges         | 0     |
| Com_show_procedure_code     | 0     |
| Com_show_procedure_status   | 0     |
| Com_show_processlist        | 0     |
| Com_show_profile            | 0     |
| Com_show_profiles           | 0     |
| Com_show_relaylog_events    | 0     |
| Com_show_slave_hosts        | 0     |
| Com_show_slave_status       | 0     |
| Com_show_status             | 1     |
| Com_show_storage_engines    | 0     |
| Com_show_table_status       | 0     |
| Com_show_tables             | 0     |
| Com_show_triggers           | 0     |
| Com_show_variables          | 0     |
| Com_show_warnings           | 0     |
| Com_show_create_user        | 0     |
| Com_shutdown                | 0     |
| Com_slave_start             | 0     |
| Com_slave_stop              | 0     |
| Com_group_replication_start | 0     |
| Com_group_replication_stop  | 0     |
| Com_stmt_execute            | 0     |
| Com_stmt_close              | 0     |
| Com_stmt_fetch              | 0     |
| Com_stmt_prepare            | 0     |
| Com_stmt_reset              | 0     |
| Com_stmt_send_long_data     | 0     |
| Com_truncate                | 0     |
| Com_uninstall_plugin        | 0     |
| Com_unlock_tables           | 0     |
| Com_update                  | 0     |
| Com_update_multi            | 0     |
| Com_xa_commit               | 0     |
| Com_xa_end                  | 0     |
| Com_xa_prepare              | 0     |
| Com_xa_recover              | 0     |
| Com_xa_rollback             | 0     |
| Com_xa_start                | 0     |
| Com_stmt_reprepare          | 0     |
| Compression                 | OFF   |
+-----------------------------+-------+

可以看到这些类型语句的执行数量，通常关心以下参数:

  • Com_select:执行SELECT操作次数，一次查询只累加1。

  • Com_insert: 执行INSERT操作次数，对于批量插入是的INSERTCA操作，只累计一次。

  • Com_update: 执行UPDATE操作的次数。

  • Com_ delete:执行DELETE操作的次数。

    上面这些参数对于所有存储引擎的表操作都会进行累计。下面这几个参数只是针对InnoDB存储引擎的，累加的算法也略有不同。

  • Innodb_ rows_read: SELECT 查询返回的行数。

  • Innodb_ rows_inserted: 执行INSERT操作插入的行数。

  • Innodb_ rows_ updated: 执行UPDATE操作更新的行数。

  • Innodb_ rows_ deleted: 执行DELETE操作删除的行数。

通过以上几个参数,可以很容易地了解当前数据库的应用是以插入更新为主还是以查询操作为主，以及各种类型的SQL大致的执行比例是多少。对于更新操作的计数，是对执行次数的计数，不论提交还是回滚都会进行累加。

对于事务型的应用，通过Com commit 和Com rollback 可以了解事务提交和回滚的情况，对于回滚操作非常频繁的数据库，可能意味着应用编写存在问题。

此外，以下几个参数便于用户了解数据库的基本情况。

  • Connections:试图连接MySQL服务器的次数。
  • Uptime:服务器工作时间。
  • Slow_ queries: 慢查询的次数。
2.定位执行效率较低的语句

通过慢查询日志定位那些执行效率较低的SQL语句,用–log-slow-queries[= file_ name]选项启动时, mysqld写一个包含所有执行时间超过long query time 秒的SQL语句的日志文件。

慢查询日志在查询结束以后才记录，所以在应用反映执行效率出现问题的时候查询慢查询日志并不能定位问题，可以使用show processlist命令查看当前MySQL在进行的线程，包括线程的状态、是否锁表等，可以实时地查看SQL的执行情况，同时对一些锁表操作进行优化。

3.通过EXPLAIN分析低效sql的执行计划

对每个列简单的进行一下说明

  • select_ type:表示SELECT的类型，常见的取值有SIMPLE (简单表，即不使用表连接或者子查询)、PRIMARY (主查询，即外层的查询)、UNION ( UNION中的第二个或者后面的查询语句)、SUBQUERY (子查询中的第一个SELECT)等。
  • table:输出结果集的表。
  • type:表示MySQL在表中找到所需行的方式，或者叫访问类型，常见类型如图18-1
    所示。
    请添加图片描述

从左至右，性能最差到最好。

  1. type=ALL，全表扫描，Mysql遍历全表来找到匹配的行。

  2. type=index, 索引全扫描，Mysql遍历整个索引来查询匹配的行。

  3. type=range,索引范围扫描，常见于<、<=、>、>=、between等操作符。

  4. type=ref,使用非唯一索引扫描或唯一索引的前缀扫描，返回匹配某个单独值的记录行，例如：
    请添加图片描述
    索引idx_ fk_ customer id是非唯一索引, 查询条件为等值查询条件customer id=35,所以扫描索引的类型为ref。ref还经常出现在join 操作中

  5. type=eq__ref, 类似ref,区别就在使用的索引是唯一索引，对于每个索引键值，表中只有一条记录匹配;简单来说,就是多表连接中使用primarykey或者uniqueindex作为关联条件。

  6. type-const/system,单表中最多有一个匹配行，查询起来非常迅速，所以这个匹配行中的其他列的值可以被优化器在当前查询中当作常量来处理，例如，根据主键primary key 或者唯一索引unique index进行的查询。

  7. type=NULL，MySQL不用访问表或者索引，直接就能够得到结果。

类型type还有其他值,如ref_ or_ null( 与ref类似，区别在于条件中包含对NULL的查询)index_ merge (索引合并优化) unique_subquery ( in的后面是一个查询主键字段的子查询)、index_ subquery (与unique_ subquery 类似，区别在于in的后面是查询非唯一索引字段的子查询)等。

  • possible_ keys: 表示查询时可能使用的索引。
  • key: 表示实际使用的索引。
  • key_ len:使用到索引字段的长度。
  • rows:扫描行的数量。
  • Extra:执行情况的说明和描述，包含不适合在其他列中显示但是对执行计划非常重要的额外信息。

MySQL 4.1开始引入了explain extended命令，通过explain extended加上show warnings,我们能够看到在SQL真正被执行之前优化器做了哪些SQL改写:

explain EXTENDED SELECT sum(amount) FROM customer a, payment b WHERE 1=1 AND a.customer_id = b.customer_id AND email = 'JAVE.BENNETT@sakilacustomer.org'\G

注意：如果使用软件链接的Mysql,不用加\G,不然可能会报错

mysql> explain EXTENDED SELECT sum(amount) FROM customer a, payment b WHERE 1=1 AND a.customer_id = b.customer_id AND email = 'JAVE.BENNETT@sakilacustomer.org'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: a
   partitions: NULL
         type: ALL
possible_keys: PRIMARY
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 599
     filtered: 10.00
        Extra: Using where
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: b
   partitions: NULL
         type: ref
possible_keys: idx_fk_customer_id
          key: idx_fk_customer_id
      key_len: 2
          ref: sakila.a.customer_id
         rows: 26
     filtered: 100.00
        Extra: NULL
2 rows in set, 2 warnings (0.00 sec)

mysql> show warnings\G
*************************** 1. row ***************************
  Level: Warning
   Code: 1681
Message: 'EXTENDED' is deprecated and will be removed in a future release.
*************************** 2. row ***************************
  Level: Note
   Code: 1003
Message: /* select#1 */ select sum(`sakila`.`b`.`amount`) AS `sum(amount)` from `sakila`.`customer` `a` join `sakila`.`payment` `b` where ((`sakila`.`b`.`customer_id` = `sakila`.`a`.`customer_id`) and (`sakila`.`a`.`email` = 'JAVE.BENNETT@sakilacustomer.org'))
2 rows in set (0.00 sec)

explain extended输出结果中多了filtered 字段,同时从wamning的message字段能够看到优化器自动去除了1=1 恒成立的条件,也就是说优化器在改写SQL时会自动去掉恒成立的条件。在遇到复杂的SQL时，我们可以利用explain extended的结果来迅速地获取一个更清晰易读的SQL。

MySQL 5.1开始支持分区功能，同时explain 命令也增加了对分区的支持。可以通过explainpartitions命令查看SQL所访问的分区。例如，创建-一个 Hash分区的customer part 表，根据分区键查询的时候，能够看到explain partitions 的输出结果中有-列partitions,其中显示了SQL所需要访问的分区名字p2:

请添加图片描述

请添加图片描述

有的时候，仅仅通过explain分析执行计划并不能很快地定位SQL的问题，这个时候我们还可以选择profile联合分析。

4.通过 show profile 分析SQL

MySQL从5.0.37版本开始增加了对show profiles 和show profile 语句的支持。通过have_ profiling 参数，能够看到当前MySQL是否支持profile:

select @@have_profiling;

mysql> select @@have_profiling;
+------------------+
| @@have_profiling |
+------------------+
| YES              |
+------------------+
1 row in set, 1 warning (0.00 sec)

默认profiling是关闭的，可以通过set语句在Session级别开profiling:

 select @@profiling;

mysql> select @@profiling;
+-------------+
| @@profiling |
+-------------+
|           0 |
+-------------+
1 row in set, 1 warning (0.00 sec)

通过profile,我们能够更清楚地了解SQL执行的过程。例如，我们知道MyISAM表有表元数据的缓存(例如行数，即COUNT()值),那么对一个MyISAM表的COUNT()是不需要
消耗太多资源的，而对于InnoDB 来说，就没有这种元数据缓存，COUNT(*)执行得较慢。

show profile能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。而MySQL5.6则通过trace文件进一步向我们展示 了优化器是如何选择执行计划的。

5.通过trace分析优化器如何选择执行计划

MySQL 5.6提供了对SQL的跟踪trace,通过trace文件能够进一步了解为什么优化器选择A执行计划而不选择B执行计划，帮助我们更好地理解优化器的行为。

使用方式:首先打开trace,设置格式为JSON,设置trace最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整显示。

请添加图片描述

接下来执行想做trace的SQL语句，例如想了解租赁表rental 中库存编号inventory_ id为4466的电影拷贝在出租日期rental_date 为2005-05-25 4:00:00~ 5:00:00之间出租的记录:

请添加图片描述

最后，检查INFORMATION_SCHEMA.OPTIMIZER_TRACE就可以知道MySQL是如何执行SQL的:

SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE\G

请添加图片描述

最后会输出一个跟踪文件

6.确定问题并采取相应的优化措施

经过以上步骤,基本就可以确认问题出现的原因。此时用户可以根据情况采取相应的措施,进行优化以提高执行的效率。

例如在第3小节的例子中，已经可以确认是对客户表customer的全表扫描导致效率的不理想，那么对客户表customer的email字段创建索引，具体如下：

create index idx_email on customer(email)

创建索引后，再看一下这条语句的执行计划，具体如下：

mysql> create index idx_email on customer(email);
Query OK, 0 rows affected (0.04 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> explain EXTENDED SELECT sum(amount) FROM customer a, payment b WHERE 1=1 AND a.customer_id = b.customer_id AND email = 'JAVE.BENNETT@sakilacustomer.org'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: a
   partitions: NULL
         type: ref
possible_keys: PRIMARY,idx_email
          key: idx_email
      key_len: 203
          ref: const
         rows: 1
     filtered: 100.00
        Extra: Using index
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: b
   partitions: NULL
         type: ref
possible_keys: idx_fk_customer_id
          key: idx_fk_customer_id
      key_len: 2
          ref: sakila.a.customer_id
         rows: 26
     filtered: 100.00
        Extra: NULL
2 rows in set, 2 warnings (0.00 sec)

可以发现，建立索引后对客户表customer需要扫描的行数明显减少（rows变成了1）,可见索引的使用可以大大提高数据库的访问速度，尤其在表很庞大的时候这种优势更为明显。

迟日暖风
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
SQL优化三步曲
10-29 203
有一天开发同学反馈线上业务库中有一条SQL执行很满，每次几乎要跑1分钟才结束，希望我们帮忙优化一下，具体SQL如下： SQL优化第一步 - 查看执行计划 对于一个SQL的优化，我们的第一步也是最重要的一步就是查看SQL执行计划，SQL执行计划一方面告诉我们SQL具体的处理行为，另外一方面也可以体现每个执行步骤下大致的资源消耗点。所以我们拿到问题SQL以及对应数据库环境后，登录该环境只读实例进行SQL分析测试。 从以上的SQL执行计划我们可以获取到哪些有效信息呢？ SQL先对t表扫描查询生产派生表，br
如何优化SQL？
彳亍
10-29 2318
通常，网站的性能瓶颈在数据库查询，如果你希望你的网站在一定阶段之内保持稳定，优化你的SQL和数据库是非常必要的优化环节。优化数据库是一个很大的话题，这里只是摘要一些比较关键的优化参考建议，并且需要具体分析项目的情况才能给出最合理的优化建议，所以具体的优化建议你应该咨询你公司的架构师或者DBA。1. 选择合适的存储引擎以 MySQL 为例，常用的有两个存储引擎 MyISAM 和 InnoDB，它们各有
如何进行SQL优化
最新发布
weixin_41422086的博客
07-25 801
在应用的的开发过程中，由于初期数据量小，开发人员写 SQL 语句时更重视功能上的实现，但是当应用系统正式上线后，随着生产数据量的急剧增长，很多 SQL 语句开始逐渐显露出性能问题，对生产的影响也越来越大，此时这些有问题的 SQL 语句就成为整个系统性能的瓶颈，因此我们必须要对它们进行优化。因为InnoDB类型的表是按照主键的顺序保存的，所以将导入的数据按照主键的顺序排列，可以有效的提高导入数据的效率。通过分析每个阶段的时间和资源消耗，可以找到查询中的性能瓶颈，并采取相应的措施来提高查询性能。
MySQL-SQL优化
m0_50180963的博客
02-06 1248
前言 在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个系统性能的瓶颈。 SQL优化一般步骤 1、通过慢查日志等定位那些执行效率较低的SQL语句 2、explain 分析SQL的执行计划 需要重点关注type、rows、filtered、extra。 type由上至下，效率越来越高 ALL 全表扫描 index 索引全扫描 range 索引范围扫描，常用语&lt.
Mysql Explain结果字段含义分析
weixin_30552635的博客
09-29 262
mysql 执行计划分析 sql如何使用索引 联接查询的执行顺序 查询扫描的数据行数 ID列 id列中的数据为一组数字，表示执行select语句顺序 id值相同时，执行顺序由上至下 id值越大优先级越高，越先被执行 SELECT_TYPE列 SIMPLE: 不包含子查询或是union操作的查询 primary :查询中如果包含任何子查询，那么最外层的查询则被标记为 primary SUB...
MySQL高级之SQL调优
Be_insighted的博客
10-23 721
如何优化SQL呢？ SQL优化的一般步骤是什么，怎么看执行计划（explain），如何理解其中各个字段的含义？ 慢查询日志，EXPLAIN 分析查询，profiling分析以及show命令查询系统状态及系统变量 如何能够使用组合索引的SQL？ 慢SQL，如何优化，从哪些方面入手？ 最左前缀原则是什么？ 影响mysql的性能因素 业务需求对MySQL的影响(合适合度) 存储定位对MySQL的影响 系统各种配置及规则数据 活跃用户的基本信息数据 活跃用户的个性化定制信息...
sql语句优化的一般步骤详解
09-09
网上关于SQL优化的教程很多，但是比较杂乱，近日有空整理了一下，写出来跟大家分享，下面这篇文章主要给大家分享介绍了关于sql语句优化的一般步骤，需要的朋友可以参考借鉴，下面随着小编来一起学习学习吧。
Oracle SQL tuning 数据库优化步骤分享(图文教程)
09-10
SQL Turning 是Quest公司出品的Quest Central软件中的一个工具。Quest Central是一款集成化、图形化、跨平台的数据库管理解决方案，可以同时管理 Oracle、DB2 和 SQL server 数据库
SQLServer 优化SQL语句 in 和not in的替代方案
09-11
在SQL Server中，优化SQL语句是提升数据库性能的关键环节。在处理大量数据时，尤其需要注意避免使用效率较低的操作符，如`IN`和`NOT IN`。这些操作符虽然在编写时提供了简洁和易读性，但在执行效率上往往不如其他...
SQL server安装步骤
05-30
以下是SQL Server的详细安装步骤： 1. **下载安装包**：首先，你需要访问SQL Server的官方网站，如链接，下载适合你操作系统的SQL Server版本。 2. **运行安装程序**：下载完成后，找到安装程序，右键以管理员权限...
优化SQl语句的十个重要步骤：
03-24
优化SQl语句的十个重要步骤：优化SQl语句的十个重要步骤：
Mysql sql优化步骤
xznetwork
01-05 750
1.查看当前sql执行频率 show status like 'Com_______'; 查看全局sql执行频率 show global status like 'Com_______'; 针对InnoDB引擎查询sql执行效率 show global status like 'Innodb_row_%'; 2.定位低效率的sql语句 （1）.慢查询日志 （2）.查看实时sql执行情况 show processlist; 3....
MYSQL --SQL优化流程
寻找兮悲、
03-31 1087
常去想想以前的东西，怀旧不是用感伤的，是温故知新，加油！！！一、分析一个SQL：1.先看表结构，美化一下，一个好看的结构会让人心旷神怡2.对复杂的SQL进行分析 （1）尽量将复杂的SQL拆成几个简单的查询 （2）尽量使用表连接，减少使用过 in/not in （3）尽量减少子查询的使用或者将其合并出来 （4）尽量将 in/ not in /exists/not ex
sql优化的几种方法
Spring为核心
04-26 941
我们要做到不但会写SQL,还要做到写出性能优良的SQL,以下为笔者学习、摘录、并汇总部分资料与大家分享！  （1）      选择最有效率的表名顺序(只在基于规则的优化器中有效)：  ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基
6. 优化SQL步骤&explain执行计划
weixin_40408979的博客
07-29 206
优化SQL步骤一、优化SQL步骤1.1 查看SQL执行频率1.2 定位低效率执行SQL1.3 explain分析执行计划1.3.1环境准备1.3.2 explain之id1.3.3 explain之select_type1.3.4 explain之table1.3.5 explain之type1.3.6 explain之key1.3.7 explain之rows1.3.8 explain之extra1.4 show profile分析SQL1.5 trace分析优化器执行计划 一、优化SQL步骤 1.1 查看
[Oracle] Sql优化系列--如何看懂执行计划
Alf的专栏
01-13 821
如何看懂ORACLE执行计划 一、什么是执行计划 An explain plan is a representation of the access path that is taken when a query is executed within Oracle. 二、如何访问数据 At the physical level Oracle reads blocks of data.
执行计划中各个字段的含义描述及获取方法
u012436346的专栏
04-05 4674
本篇文章主要介绍了"执行计划中各个字段的含义描述及获取方法"，主要涉及到执行计划中各个字段的含义描述及获取方法方面的内容，对于执行计划中各个字段的含义描述及获取方法感兴趣的同学可以参考一下。 一、概述 当一条SQL执行很慢时，我们需要分析SQL的执行计划来判断问题的所在。得到一条sql的执行计划有如下三种方法： 1）set autot trace（设置autotrace）   
SQL Server执行计划的理解
ajwqb06628的专栏
06-28 378
SQL Server执行计划的理解 　　要理解执行计划，怎么也得先理解，那各种各样的名词吧。鉴于自己还不是很了解。本文打算作为只写懂的，不懂的懂了才写。 　　在开头要先说明，第一次看执行计划要注意，SQL Server的执行计划是从右向左看的。 　　名词解析： ...
sql优化的理解
Qizhan_feng的博客
05-10 805
@TOC sql优化 从网上的答案提出疑问到做出假设 不管假设有没有完全，能让我理解并记住就可以了。每个人的记忆宫殿不一样。 网上查到的优化方法 1.把返回的时候把*号改成对应字段，联表查询的时候字段应该添加前缀减少判断，不要写没必要返回的字段。 2.添加索引，通过索引作为查询条件，同事注意不要以任何形式改变索引字段，改变后就不再是索引，比如函数计算等。 3.杜绝不必要的联表查询。 4.避免语句中...
oracle 慢sql优化相关步骤
02-27
优化Oracle慢SQL通常需要以下步骤： 1. 确认慢SQL：首先需要确认哪些SQL查询是慢的，可以通过Oracle提供的性能分析工具如AWR报告、SQL Trace和10046 Trace等来确认。 2. 确认执行计划：确认慢SQL的执行计划，可以使用Oracle提供的工具如SQL Developer、SQL*Plus等来查看执行计划。 3. 查找性能瓶颈：通过执行计划来查找性能瓶颈，如高CPU使用率、高I/O等待时间、锁等待等。 4. 优化SQL语句：根据性能瓶颈对SQL语句进行优化，如添加索引、优化查询条件、减少子查询等。 5. 重新测试：对优化后的SQL语句进行测试，确保性能得到改善。 6. 监控性能：持续监控数据库性能，确保优化效果持续稳定。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值