安科网

为什么需要SQL Profile

huanging

huanging

2016-11-17

关注 关注

>阅读导航

  • 为什么需要SQL Profile
  •   遇到的问题
  •   Oracle 分析背后做了什么
  •   优化器的问题
  •   什么是SQL Profile

为什么需要SQL Profile

Why oracle need SQL Profiles,how it work and what are SQL Profiles...

使用DBMS_XPLAN.DISPLAY分析SQL执行计划，通常会看到Note中有类似下面这样的提示；

Note
-----
 
   - SQL profile "SYS_SQLPROF_0158283a9b920000" used for this statement

SQL profile由人为手工创建或在Automatic SQL Tunning阶段由SQL tuning advisor创建，它看起来有如下的意思:

  1. 在优化器评估SQL时使用了额外的对象帮助完成评估；
  2. 对象改变了优化器原先的评估计划；

当看到这些信息，比较关心的是这个对象(SLQ profile)是什么?它做了什么?是否真的需要它?带着这些疑问学习和探索，最终决解了遇到的问题。

SQL> @i

USERNAME             INST_NAME            HOST_NAME                 SID   SERIAL#  VERSION    STARTED  SPID       OPID  CPID            SADDR            PADDR
-------------------- -------------------- ------------------------- ----- -------- ---------- -------- ---------- ----- --------------- ---------------- ----------------
OPS$SYWU             sydb                 sywu.com                  288   22197    11.2.0.4.0 20160421 13736      46    3392:1312       0000000071FE0DA0 0000000072149F40

 

遇到的问题

假设有这样一张类似订单的表orders；

create table orders(order_no,order_date)
as
select
    level,cast(sysdate-level/24 as date) 
from 
    dual
connect by level<=5E5;

SQL> @desc orders
           Name                            Null?    Type
           ------------------------------- -------- ----------------------------
    1      ORDER_NO                                 NUMBER
    2      ORDER_DATE                               DATE

保存订单信息，order_date上创建了索引。

create index idx_orders_dt on orders(order_date);

在交易中可能经常遇到某些原因导致交易延期的情况，为了测试这个问题，开发人员添加了未来某一天这样的日期值测试；这里用一个清晰的时间来代替未来的日期；

INSERT INTO ORDERS VALUES (-1, DATE '9999-01-01');

和正常使用的一样，该表定期收集了统计信息；

exec dbms_stats.gather_table_stats(user,'orders', cascade => true);

当系统查询当天的交易记录时发现优化器使用全表扫描，并非索引扫描；

-------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation         | Name   | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads  |
-------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |      1 |        |       |   130 (100)|          |     10 |00:00:00.23 |     329 |    323 |
|*  1 |  TABLE ACCESS FULL| ORDERS |      1 |    496K|  6302K|   130  (26)| 00:00:02 |     10 |00:00:00.23 |     329 |    323 |
-------------------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$1 / ORDERS@SEL$1

Outline Data
-------------

  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('11.2.0.4')
      DB_VERSION('11.2.0.4')
      ALL_ROWS
      OUTLINE_LEAF(@"SEL$1")
      FULL(@"SEL$1" "ORDERS"@"SEL$1")
      END_OUTLINE_DATA
  */

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("ORDER_DATE">=TRUNC(SYSDATE@!,'fmdd'))

Column Projection Information (identified by operation id):
-----------------------------------------------------------

   1 - "ORDERS"."ORDER_NO"[NUMBER,22], "ORDER_DATE"[DATE,7]

显然对于这样一张交易记录表，实际当天的记录数据只占全表数据量的4.1%左右，使用索引扫描的方式开销小于全表扫描，但优化器对范围评估错误。接着使用DBMS_SQLTUNE分析SQL；

var task_name varchar2(30)

BEGIN
    :task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
         sql_text    => 'select * from orders where order_date>=trunc(sysdate,''DD'')',
         user_name   => user,
         scope       => 'COMPREHENSIVE',
         time_limit  => 60,
         task_name   => 'orders_tuning_task');
END;
/

执行分析；

alter session set events '10046 trace name context forever,level 12';
exec DBMS_SQLTUNE.execute_tuning_task(task_name => :task_name);

分析结果；

col REPORT_TUNING format a200
select
    dbms_sqltune.report_tuning_task(:task_name) REPORT_TUNING
from
    dual;

REPORT_TUNING
----------------------------------------------------------------------------------------------------------------------
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name   : orders_tuning_task
Tuning Task Owner  : OPS$SYWU
Workload Type      : Single SQL Statement
Scope              : COMPREHENSIVE
Time Limit(seconds): 60
Completion Status  : COMPLETED
Started at         : 11/07/2016 21:43:25
Completed at       : 11/07/2016 21:43:27

-------------------------------------------------------------------------------
Schema Name: OPS$SYWU
SQL ID     : 9ybj4xdc5hsrb
SQL Text   : select * from orders where order_date>=trunc(sysdate,'DD')

-------------------------------------------------------------------------------
FINDINGS SECTION (1 finding)
-------------------------------------------------------------------------------

1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------
  A potentially better execution plan was found for this statement.

  Recommendation (estimated benefit: 98.78%)
  ------------------------------------------
  - Consider accepting the recommended SQL profile.
    execute dbms_sqltune.accept_sql_profile(task_name =>
            'orders_tuning_task', task_owner => 'OPS$SYWU', replace => TRUE);

  Validation results
  ------------------
  The SQL profile was tested by executing both its plan and the original plan
  and measuring their respective execution statistics. A plan may have been
  only partially executed if the other could be run to completion in less time.

                           Original Plan  With SQL Profile  % Improved
                           -------------  ----------------  ----------
  Completion Status:            COMPLETE          COMPLETE
  Elapsed Time (s):             .041546           .000132      99.68 %
  CPU Time (s):                 .029895             .0001      99.66 %
  User I/O Time (s):            .015204           .000032      99.78 %
  Buffer Gets:                      328                 4      98.78 %
  Physical Read Requests:            45                 0        100 %
  Physical Write Requests:            0                 0
  Physical Read Bytes:         10682368              9830       99.9 %
  Physical Write Bytes:               0                 0
  Rows Processed:                    10                10
  Fetches:                           10                10
  Executions:                         1                 1

  Notes
  -----
  1. Statistics for the original plan were averaged over 10 executions.
  2. Statistics for the SQL profile plan were averaged over 10 executions.

-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------

1- Original With Adjusted Cost
------------------------------
Plan hash value: 1275100350

----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |    18 |   234 |   130  (26)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL| ORDERS |    18 |   234 |   130  (26)| 00:00:02 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("ORDER_DATE">=TRUNC(SYSDATE@!,'fmdd'))

2- Using SQL Profile
--------------------
Plan hash value: 3364688013

---------------------------------------------------------------------------------------------
| Id  | Operation                   | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |               |    18 |   234 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ORDERS        |    18 |   234 |     3   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_ORDERS_DT |    10 |       |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ORDER_DATE">=TRUNC(SYSDATE@!,'fmdd'))

-------------------------------------------------------------------------------

oracle通过分析发现了问题，产生了新的执行计划，并对比两个执行计划，新的执行计划改善90%+的性能，并且改善性能问题只需要同意使用SQL Profile即可；然后允许数据库使用SQL Profile。

exec dbms_sqltune.ACCEPT_SQL_PROFILE(TASK_NAME=>:task_name);

再次执行SQL时，优化器使用了SQL Profile和新的执行计划。

select * from orders where order_date>=trunc(sysdate,'DD');

SQL_ID  3zcvw1pxfcypm, child number 0
-------------------------------------
select * from orders where order_date>=trunc(sysdate,'DD')

Plan hash value: 3364688013

---------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name          | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
---------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |               |      1 |        |       |     3 (100)|          |     10 |00:00:00.01 |       6 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ORDERS        |      1 |     18 |   234 |     3   (0)| 00:00:01 |     10 |00:00:00.01 |       6 |
|*  2 |   INDEX RANGE SCAN          | IDX_ORDERS_DT |      1 |     10 |       |     2   (0)| 00:00:01 |     10 |00:00:00.01 |       3 |
---------------------------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$1 / ORDERS@SEL$1
   2 - SEL$1 / ORDERS@SEL$1

Outline Data
-------------

  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('11.2.0.4')
      DB_VERSION('11.2.0.4')
      ALL_ROWS
      OUTLINE_LEAF(@"SEL$1")
      INDEX_RS_ASC(@"SEL$1" "ORDERS"@"SEL$1" ("ORDERS"."ORDER_DATE"))
      END_OUTLINE_DATA
  */

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ORDER_DATE">=TRUNC(SYSDATE@!,'fmdd'))

Column Projection Information (identified by operation id):
-----------------------------------------------------------

   1 - "ORDERS"."ORDER_NO"[NUMBER,22], "ORDER_DATE"[DATE,7]
   2 - "ORDERS".ROWID[ROWID,10], "ORDER_DATE"[DATE,7]

Note
-----
 
   - SQL profile SYS_SQLPROF_01582d15092f0001 used for this statement


SQL>  @sql 2061925043
Show SQL text, child cursors and execution stats for SQL hash value 2061925043 child OPS$SYWU@sydb_111 report

HASH_VALUE   CH#  PLAN_HASH SQL_TEXT                                                                                                       SQL_PROFILE
---------- ----- ---------- -------------------------------------------------------------------------------------------------------------- ------------------------------
2061925043     0 3364688013 select * from orders where order_date>=trunc(sysdate,'DD')                                               SYS_SQLPROF_01582d15092f0001 


  CH# PARENT_HANDLE    OBJECT_HANDLE        PARSES   H_PARSES EXECUTIONS    FETCHES ROWS_PROCESSED       LIOS       PIOS      SORTS     CPU_MS     ELA_MS USERS_EXECUTING
----- ---------------- ---------------- ---------- ---------- ---------- ---------- -------------- ---------- ---------- ---------- ---------- ---------- ---------------
    0 0000000064618858 0000000063A03108          1          3          1          2             10         16          6          0      7.999      8.621               0

 

Oracle 分析背后做了什么

很惊奇，为什么分析后优化器就能找出问题所在，此时焦点都集中在trace文件了；分析trace文件，发现如下信息；

SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring
  optimizer_features_enable(default) opt_param('parallel_execution_enabled',
  'false')  result_cache */ COUNT(C1)
FROM
 (SELECT /*+ qb_name("innerQuery") NO_INDEX_FFS( "ORDERS")  */ 1 AS C1 FROM
  "ORDERS" SAMPLE BLOCK(56.8182, 2) SEED(1)  "ORDERS") innerQuery

SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring
  optimizer_features_enable(default) opt_param('parallel_execution_enabled',
  'false')  result_cache */ COUNT(C1)
FROM
 (SELECT /*+ qb_name("innerQuery") INDEX_FFS( "ORDERS" "IDX_ORDERS_DT")  */ 1
  AS C1 FROM "ORDERS" SAMPLE BLOCK(59.5238, 2) SEED(1)  "ORDERS" WHERE (
  "ORDERS".ORDER_DATE IS NOT NULL)) innerQuery

SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring
  optimizer_features_enable(default) opt_param('parallel_execution_enabled',
  'false')  result_cache */ COUNT(C1)
FROM
 (SELECT /*+ qb_name("innerQuery") NO_INDEX_FFS( "ORDERS")  */ 1 AS C1 FROM
  "ORDERS" SAMPLE BLOCK(56.8182, 2) SEED(1)  "ORDERS" WHERE
  ("ORDERS"."ORDER_DATE">=TRUNC(SYSDATE@!,'fmdd'))) innerQuery

SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring
  optimizer_features_enable(default) opt_param('parallel_execution_enabled',
  'false')  result_cache OPT_ESTIMATE(@"innerQuery", TABLE, "ORDERS",
  SCALE_ROWS=3.545138895e-05) */ C1, C2, C3
FROM
 (SELECT /*+ qb_name("innerQuery") INDEX( "ORDERS" "IDX_ORDERS_DT")  */
  COUNT(*) AS C1, 4294967295 AS C2, COUNT(*) AS C3  FROM "ORDERS" "ORDERS"
  WHERE ("ORDERS"."ORDER_DATE">=TRUNC(SYSDATE@!,'fmdd'))) innerQuery

/* SQL Analyze(156,0) */ select * from orders where order_date>=trunc(sysdate,'DD')

从trace文件分析得出，oracle做了如下的操作:

  1. 动态采样分析全表数据(无索引)；
  2. 动态采样分析表中非空数据(无索引)；
  3. 用全表扫描的方式动态采样分析相关的数据；
  4. 用索引扫描的方式动态采样分析相关的数据；
  5. 对比旧的和新的执行计划；

Oracle对比旧的和新的执行计划后，将消耗小的执行计划信息保存到SQL profile中。

 

优化器的问题

通常优化器相信:

  1. 数据值分布均匀(比如假设：表列数据中，数值2比数值5一样使用频繁)；
  2. 数据行分布均匀(比如假设：没有物理cluster或者数据排序)；
  3. 对于范围数据是连续的，没有漏缺。

优化器信任收集的统计信息，这些信息包括表行记录数,distinct value,max/min value,直方图信息；换一种通俗的说法，统计信息捕获了表整体形状数据，但有些低级别的信息丢失了。这种分析对于大多数数据来说往往工作得很好，但实际情况中，不可避免的有违反规则的例外，比如对于一张大表，98%的数据可能以随机的方式分配在整个段中(segment)，剩余的2%的数据可能只集中在几个数据块中；不幸的是收集统计信息时没有记录这些细节；这就引发一个问题，已经有的统计信息不能完全有效的帮助优化器生成正确的执行计划，所以到了这里问题转变为什么可以弥补或纠正这些信息，让优化器面对这种特定的SQL时可以评估正确，生成好的执行计划。

 

什么是SQL Profile

通过上面的实验大体将SQL Profile定义为：

  1. 为特定SQL创建和保存执行计划信息；
  2. 使用实际运行时的数据来帮助优化器为特定的SQL评估和生成更好的执行计划；

首先通过dbms_sqltune.create_tunning_task创建任务告诉数据库存在问题的可以改善的SQL，这个操作在11G或以后的版本中可以通过Automatic SQL Tuning在对"most active" SQL 分析时创建；然后运行dbms_sqltune.execute_tuning_task评估，这个过程包括三个主要步骤:

  1. 动态采样分析表数据，获取到真实的实数信息(最重要的比如，Cardinality)
  2. 提供这些真实的实数信息给优化器，让优化器重新评估；
  3. 如果优化器评估出新的执行计划，重复多次运行旧的执行计划和新的执行计划，最后对比性能；

如果优化器试运行得出的结果为:

  1. 优化器评估后产生了新的执行计划；
  2. 新的执行计划比旧的执行计划性能消耗更小，大幅提升性能；

则表明优化器证明旧的评估对于特定的SQL是错误的，一些低级的数据被分析出，进一步，oracle会将这些信息保存供以后使用。但是如何保存这些信息呢?不可能通过定期性的更新统计信息，因为统计信息不包括这些信息。所以，数据库使用一个独立的对象(SQL Profile)保存SQL和这些(cardinality)信息。oracle 以opt_estimate hints的格式保存cardinality信息；
/+ opt_estimate(table, orders, scale_rows=10) */
或者
/+ opt_estimate(index_scan, orders, IDX_ORDERS_DT, scale_rows=0.001) */
所以如果使用了SQL Profile，评估时默认的cardinality将乘以这些数字，优化器会更真实的查看到表中的数据信息，然后做出评估。

sql优化

huanging

huanging

0 关注 0 粉丝 0 动态

关注 关注

相关推荐

MySQL数据类型优化原则

MySQL支持的数据类型很多，选择正确的数据类型对于高性能至关重要。下面几个简单的原则都有助于做出更好的选择。应该尽量使用可以正确储存数据的最小数据类型。如果无法确定哪个数据类型时最好的，就选择你认为不会超过范围的最小类型。比如用MySQ内建的类型而不是使

ribavnu 2020-11-16

MySQL中使用binlog时格式该如何选择

每一条会修改数据的sql都会记录到master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。另外就是,由于mysql现在发展比较快，很多的新功能加入，使mysql的复制遇到了不小的挑战,自然

要啥自行车一把梭 2020-11-12

详解 MySQL中count函数的正确使用方法

当搞清楚count函数的运行原理后，相信上面几个问题的答案就会了然于胸。为了解决上述的问题，我创建了一张 user 表，它有两个字段：主键id和name，后者可以为null，建表语句如下。`id` int NOT NULL AUTO_INCREMENT C

vitasfly 2020-11-12

sql优化实战 把full join改为left join +union all(从5分钟降为10秒)

今天收到一个需求，要改写一个报表的逻辑，当改完之后，再次运行，发现运行超时。因为特殊原因，无法访问客户的服务器，没办法查看sql的执行计划、没办法知道表中的索引情况，所以，尝试从语句的改写上来优化。但是考虑到第2段代码中并没有prod_id这个字段，所以这

ILVNMM 2020-09-19

SQL Server 开窗函数 Over()代替游标的使用详解

今天在优化工作中遇到的sql慢的问题，发现以前用了挺多游标来处理数据，这样就导致在数据量多的情况下，需要一行一行去遍历从而计算需要的数据，这样处理的结果就是数据慢，容易卡死。第一行表示标题；第二行表示客户，是一行空行；第三行是期初余额，只显示期末余额的数据

zycchun 2020-10-16

Mysql临时表及分区表区别详解

内存表，指的是使用Memory引擎的表，建表语法是create table …这种 表的数据都保存在内存，系统重启的时候会被清空，但是表结构还在。除这两个特性看 上去比较“奇怪”外，从其他的特征上看，它就是一个正常的表。如果是使用InnoDB引擎或者MyI

康慧欣 2020-09-10

导致MySQL索引失效的一些常见写法总结

最近一直忙着处理原来老项目遗留的一些SQL优化问题，由于当初表的设计以及字段设计的问题，随着业务的增长，出现了大量的慢SQL，导致MySQL的CPU资源飙升，基于此，给大家简单分享下这些比较使用的易于学习和使用的经验。这次的话简单说下如何防止你的索引失效。

liuweiq 2020-09-09

MySQL索引的各种类型

索引是数据库存储引擎用于快速查找到指定数据的一种数据结构。可以用新华字典做类比：如果新华字典中对每个字的详细解释是数据库中表的记录，那么按部首或拼音等排序的目录就是索引，使用它可以让我们快速查找的某一个字详细解释的位置。在MySQL中，存储引擎也是用了类似

silencehgt 2020-09-07

MySQL 数据库如何解决高并发问题

我们都知道初创公司一开始都是以单体应用为首要架构，一般都是单体单库的形式。但是版本以及版本的迭代，数据库需要承受更多的高并发已经成了 架构设计 需要考虑的点。高并发的情况下，可以将多个请求的查询合在一次进行，以减少对数据库的访问速度。我们都知道，只要数据库

sunnyxuebuhui 2020-09-07

MySQL 千万级数据量如何快速分页

后端开发中为了防止一次性加载太多数据导致内存、磁盘IO都开销过大，经常需要分页展示，这个时候就需要用到MySQL的LIMIT关键字。但你以为LIMIT分页就万事大吉了么，Too young,too simple啊，LIMIT在数据量大的时候极可能造成的一个

西瓜皮儿的皮儿 2020-09-07

分区表场景下的 SQL 优化

有个表做了分区，每天一个分区。该表上有个查询，经常只查询表中某一天数据，但每次都几乎要扫描整个分区的所有数据，有什么办法进行优化吗？有一个大表，每天产生的数据量约100万，所以就采用表分区方案，每天一个分区。`tst` timestamp NOT NULL

李轮清 2020-09-15

mysql性能分析篇

数据库查询快慢是影响项目性能的一大因素， 对于数据库， 我们除了要优化SQL， 更重要的是得先找到需要优化的SQL， MYSQL数据库又一个慢查询日志功能， 用来记录查询时间超过某个设定值的SQL语句， 这将极大程序帮助我们快速定位到问题， 以便对症下药。

lifeison 2020-08-18

不得不会的mysql架构， 让你更懂她！

Connection Pool**: 连接池a. 管理缓冲用户连接，线程处理等需要缓存的需求。c. 而连接线程的主要工作就是负责 MySQL Server 与客户端的通信，接受客户端的命令请求，传递 Server 端的结果信息等。包括线程的创建，线程的 c

cyhgogogo 2020-08-18

MySQL优化SQL语句的技巧

在面对不够优化、或者性能极差的SQL语句时，我们通常的想法是将重构这个SQL语句，让其查询的结果集和原来保持一样，并且希望SQL性能得以提升。而在重构SQL时，一般都有一定方法技巧可供参考，本文将介绍如何通过这些技巧方法来重构SQL。有时候对于一个复杂SQ

minerk 2020-08-15

MySQL如何优化查询速度

前面章节我们介绍了如何选择优化的数据类型、如何高效的使用索引，这些对于高性能的MySQL来说是必不可少的。但这些还完全不够，还需要合理的设计查询。如果查询写的很糟糕，即使表结构再合理、索引再合适，也是无法实现高性能的。谈到MySQL性能优化，查询优化作为优

webliyang 2020-08-15

MySQL数据库查询性能优化策略

Explain 用来分析 SELECT 查询语句，开发人员可以通过分析 Explain 结果来优化查询语句。MySQL可以为多个字段创建索引,一个索引可以包括16个字段,只有查询条件中使用这些字段中的第一个字段时,索引才会被使用.子查询虽然可以使查询语句更

houdaxiami 2020-08-15

关于mysql自增id，你需要知道的

本篇文章将以问答的形式讲述关于自增id的一切。这就要求同一个叶子节点内的各条数据记录按主键顺序存放，因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子，则开辟一个新的页（节点）。自增id是增长的 不一定连续。

抱抱熊 2020-08-15

详解MySQL分区表

分区是一种表的设计模式，通俗地讲表分区是将一大表，根据条件分割成若干个小表。但是对于应用程序来讲，分区的表和没有分区的表是一样的。换句话来讲，分区对于应用是透明的，只是数据库对于数据的重新整理。本篇文章给大家带来的内容是关于MySQL中分区表的介绍及使用场

caodayong 2020-08-15

Centos7 安装 Mysql8教程

首先，您需要在MySQL提供的系统中启用MySQL yum存储库。根据您的操作系统版本执行以下命令之一，这里我们选择CentOS 7 / RHEL 7的源。因此，首先禁用mysql repo文件中的所有存储库。安装MySQL 8.0后，将为MySQL根用户

徐悦TechBlog 2020-08-15

Mysql中Sleep进程连接数过多问题解决

连接数查看进入MySQL命令行，输入“show processlist;”命令后，Command列出现一大堆Sleep睡眠状态的连接进程。超过配置的最大连接数，新的客户端连接将无法连接，mysql将无法提供服务，Web系统无法访问、崩塌。造成连接数过多原因

hevenue 2020-07-30
huanging

huanging

W3CSchool教程
HTML 教程
CSS 教程
Bootstrap 教程
Javascript 教程
jQuery 教程
后端教程
C 教程
Java 教程
PHP 教程
Python 教程
Go 教程
移动开发
Android 教程
Swift 教程
Kotlin 教程
jQuery Mobile 教程
ionic 教程
关于我们
新闻动态
联系方式
招聘英才
安科实验室
帮助与反馈

安科网(Ancii)，中国第一极客网

Copyright © 2013 - 2019 Ancii.com

京ICP备18063983号 京公网安备11010802014868号