精华内容
下载资源
问答
  • 文章目录一、数据库调优的目标二、确定调优目标的方式1. 用户的反馈2. 日志分析3. 服务器资源使用资源4. 数据库内部状况监控三、数据库的调优维度1. 选择合适的DBMS2. 优化表设计3. 优化逻辑查询4. 优化物理查询5. ...

    一、数据库调优的目标

    简单来说,数据库调优的目的就是要让数据库运行得更快,也就是说响应的时间更快,吞吐量更大
    不过随着用户量的不断增加,以及应用程序复杂度的提升,我们很难用“更快”去定义数据库调优的目标,因为用户在不同时间段访问服务器遇到的瓶颈不同,比如双十一促销的时候会带来大规模的并发访问;还有用户在进行不同业务操作的时候,数据库的事务处理和 SQL 查询都会有所不同。因此我们还需要更加精细的定位,去确定调优的目标。

    二、确定调优目标的方式

    1. 用户的反馈

    用户是我们的服务对象,因此他们的反馈是最直接的。虽然他们不会直接提出技术建议,但是有些问题往往是用户第一时间发现的。我们要重视用户的反馈,找到和数据相关的问题。

    2. 日志分析

    --可以通过查看数据库日志和操作系统日志等方式找出异常情况,通过它们来定位遇到的问题。
    
    --1.查询系统使用的是哪一组日志文件:
    select * from v$log;
    --2.查询正在使用的组所对应的日志文件:
    select * from v$logfile;
    --3.强制日志切换:
    alter system switch logfile;
    --4.查询历史日志:
    select * from v$log_history;
    --5.查询日志的归档模式:
    select dbid,name,created,log_mode from v$database;
    --6.查询归档日志的信息:
    select recid,stamp,thread#,sequence#,name from v$archived_log;
    --7.增加与删除日志文件组
    alter database add logfile group 1 ('/home1/oracle/oradata/ora8i/log1a.log'),'/home2/oracle/oradata/ora8i/log1b.log') size 100M;
    alter database drop logfile group 1;
    --8.增加与删除日志成员
    alter database add logfile member '/home1/oracle/oradata/ora8i/log1a.log' to group 1,'/home1/oracle/oradata/ora8i/log2a.log' to group 2;
    alter database drop logfile member '/home1/oracle/oradata/ora8i/log1a.log' ;
    --9.日志文件移动
    alter database rename file '/home1/oracle/oradata/ora8i/log1a.log' to '/home2/oracle/oradata/ora8i/log1a.log';
    ----执行该命令之前必须保证该日志文件物理上已经移动到新目录
    --10.清除日志文件
    alter database clear logfile '/home1/oracle/oradata/ora8i/log1a.log';
    

    3. 服务器资源使用资源

    通过监控服务器的 CPU、内存、I/O 等使用情况,可以实时了解服务器的性能使用,与历史情况进行对比。

    4. 数据库内部状况监控

    --在数据库的监控中,活动会话(Active Session)监控是一个重要的指标。通过它,你可以清楚地了解数据库当前是否处于非常繁忙的状态,是否存在 SQL 堆积等。除了活动会话监控以外,我们也可以对事务、锁等待等进行监控,这些都可以帮助我们对数据库的运行状态有更全面的认识。
    
    -- 查看所有job
    select from dba_jobs;
    -- 查看正在运行的job
    select from dba_jobs_running;
    select job,log_user,priv_user,schema_user,BROKEN from dba_jobs where job=545;
    -- 查看数据库建立的回话情况
    select sid,serial#,username,program,machine,status
    from v$session;
    -- 查看对应sid的sql_id
    select * from v$session where sid=2272 or sid=327;
    -- 知道sql_id后查看sql语句
    select SQL_TEXT from v$sql where sql_id='3f18ygbqg41mw';
    -- 给MESPRD赋权
    grant execute on DBMS_WORKLOAD_REPOSITORY to MESPRD;
    kill会话
    alter system kill session 'sid,serial#';
    alter system kill session '327,8133';
    -- 查看进程的spid
    select spid, program from v$process
    where program!= 'PSEUDO'
    and addr not in (select paddr from v$session)
    and addr not in (select paddr from v$bgprocess)
    and addr not in (select paddr from v$shared_server);
    !ps -ef|grep spid|grep -v grep;
    -- 查看进程的spid
    SELECT s.username,s.status,
    x.ADDR,x.KSLLAPSC,x.KSLLAPSN,x.KSLLASPO,x.KSLLID1R,x.KSLLRTYP,
    decode(bitand (x.ksuprflg,2),0,null,1)
    FROM x$ksupr x,v$session s
    WHERE s.paddr(+)=x.addr
    and bitand(ksspaflg,1)!=0;
    

    三、数据库的调优维度

    我们需要调优的对象是整个数据库管理系统,它不仅包括 SQL 查询,还包括数据库的部署配置、架构等。从这个角度来说,我们思考的维度就不仅仅局限在 SQL 优化上了。

    1. 选择合适的DBMS

    在 RDBMS 中,常用的有 Oracle,SQL Server 和 MySQL 等。如果对事务性处理以及安全性要求高的话,可以选择商业的数据库产品。这些数据库在事务处理和查询性能上都比较强,比如采用 SQL Server,那么单表存储上亿条数据是没有问题的。如果数据表设计得好,即使不采用分库分表的方式,查询效率也不差。
    NoSQL 阵营包括键值型数据库、文档型数据库、搜索引擎、列式存储和图形数据库。这些数据库的优缺点和使用场景各有不同,比如列式存储数据库可以大幅度降低系统的 I/O,适合于分布式文件系统和 OLAP,但如果数据需要频繁地增删改,那么列式存储就不太适用了。

    2. 优化表设计

    选择了 DBMS 之后,我们就需要进行表设计了。RDBMS 中,每个对象都可以定义为一张表,表与表之间的关系代表了对象之间的关系。如果用的是 MySQL,我们还可以根据不同表的使用需求,选择不同的存储引擎。除此以外,还有一些优化的原则可以参考:

    1. 表结构要尽量遵循第三范式的原则。这样可以让数据结构更加清晰规范,减少冗余字段,同时也减少了在更新,插入和删除数据时等异常情况的发生。
    2. 如果分析查询应用比较多,尤其是需要进行多表联查的时候,可以采用反范式进行优化。反范式采用空间换时间的方式,通过增加冗余字段提高查询的效率。
    3. 表字段的数据类型选择,关系到了查询效率的高低以及存储空间的大小。一般来说,如果字段可以采用数值类型就不要采用字符类型;字符长度要尽可能设计得短一些。针对字符类型来说,当确定字符长度固定时,就可以采用CHAR 类型;当长度不固定时,通常采用 VARCHAR 类型。
    4. 数据表的结构设计很基础,也很关键。好的表结构可以在业务发展和用户量增加的情况下依然发挥作用,不好的表结构设计会让数据表变得非常臃肿,查询效率也会降低。

    3. 优化逻辑查询

    SQL 查询优化,可以分为逻辑查询优化和物理查询优化。逻辑查询优化就是通过改变 SQL 语句的内容让 SQL 执行效率更高效,采用的方式是对 SQL 语句进行等价变换,对查询进行重写。
    SQL 的查询重写包括了子查询优化、等价谓词重写、视图重写、条件简化、连接消除和嵌套连接消除等。

    比如EXISTS 子查询和 IN 子查询的时候,会根据小表驱动大表的原则选择适合的子查询。在 WHERE 子句中会尽量避免对字段进行函数运算,它们会让字段的索引失效。
    我举一个例子,假设我想对emp进行检索,查询评论内容开头为 abc 的内容都有哪些,如果在 WHERE 子句中使用了函数,语句就会写成下面这样:
    SELECT字段FROM 表名WHERE SUBSTRING(a, 1,3)=‘abc’
    我们可以采用查询重写的方式进行等价替换:
    SELECT 字段FROM 表名 WHERE 字段LIKE 'abc%'你会发现在数据量大的情况下,第二条 SQL 语句的查询效率要比前面的高很多,执行时间为前者的 1/10。

    4. 优化物理查询

    物理查询优化是将逻辑查询的内容变成可以被执行的物理操作符,从而为后续执行器的执行提供准备。它的核心是高效地建立索引,并通过这些索引来做各种优化。但你要知道索引不是万能的,我们需要根据实际情况来创建索引。那么都有哪些情况需要考虑呢?

    1. 如果数据重复度高,就不需要创建索引。通常在重复度超过 10% 的情况下,可以不创建这个字段的索引。比如性别这个字段(取值为男和女)。
    2. 要注意索引列的位置对索引使用的影响。比如我们在 WHERE 子句中对索引字段进行了表达式的计算,会造成这个字段的索引失效。
    3. 要注意联合索引对索引使用的影响。我们在创建联合索引的时候会对多个字段创建索引,这时索引的顺序就很重要了。比如我们对字段 x, y, z 创建了索引,那么顺序是 (x,y,z) 还是 (z,y,x),在执行的时候就会存在差别。
    4. 要注意多个索引对索引使用的影响。索引不是越多越好,因为每个索引都需要存储空间,索引多也就意味着需要更多的存储空间。此外,过多的索引也会导致优化器在进行评估的时候增加了筛选出索引的计算时间,影响评估的效率。

    5. 使用 Redis 或 Memcached

    作为缓存除了可以对 SQL 本身进行优化以外,我们还可以请外援提升查询的效率。因为数据都是存放到数据库中,我们需要从数据库层中取出数据放到内存中进行业务逻辑的操作,当用户量增大的时候,如果频繁地进行数据查询,会消耗数据库的很多资源。如果我们将常用的数据直接放到内存中,就会大幅提升查询的效率。
    键值存储数据库可以帮我们解决这个问题。常用的键值存储数据库有 Redis 和 Memcached,它们都可以将数据存放到内存中。从可靠性来说,Redis 支持持久化,可以让我们的数据保存在硬盘上,不过这样一来性能消耗也会比较大。而 Memcached 仅仅是内存存储,不支持持久化。从支持的数据类型来说,Redis 比 Memcached 要多,它不仅支持 key-value 类型的数据,还支持 List,Set,Hash 等数据结构。
    当我们有持久化需求或者是更高级的数据处理需求的时候,就可以使用 Redis。如果是简单的 key-value 存储,则可以使用 Memcached。通常我们对于查询响应要求高的场景(响应时间短,吞吐量大),可以考虑内存数据库,毕竟术业有专攻。传统的 RDBMS 都是将数据存储在硬盘上,而内存数据库则存放在内存中,查询起来要快得多。不过使用不同的工具,也增加了开发人员的使用成本。

    6. 库级优化

    库级优化是站在数据库的维度上进行的优化策略,比如控制一个库中的数据表数量。另外我们可以采用主从架构优化我们的读写策略。如果读和写的业务量都很大,并且它们都在同一个数据库服务器中进行操作,那么数据库的性能就会出现瓶颈,这时为了提升系统的性能,优化用户体验,我们可以采用读写分离的方式降低主数据库的负载,比如用主数据库(master)完成写操作,用从数据库(slave)完成读操作。除此以外,我们还可以对数据库分库分表。当数据量级达到亿级以上时,有时候我们需要把一个数据库切成多份,放到不同的数据库服务器上,减少对单一数据库服务器的访问压力。如果你使用的是 MySQL,就可以使用 MySQL 自带的分区表功能,当然你也可以考虑自己做垂直切分和水平切分。什么情况下做垂直切分,什么情况下做水平切分呢?如果数据库中的数据表过多,可以采用垂直分库的方式,将关联的数据表部署在一个数据库上。如果数据表中的列过多,可以采用垂直分表的方式,将数据表分拆成多张,把经常一起使用的列放到同一张表里。如果数据表中的数据达到了亿级以上,可以考虑水平切分,将大的数据表分拆成不同的子表,每张表保持相同的表结构。比如你可以按照年份来划分,把不同年份的数据放到不同的数据表中。2017 年、2018 年和 2019 年的数据就可以分别放到三张数据表中。采用垂直分表的形式,就是将一张数据表分拆成多张表,采用水平拆分的方式,就是将单张数据量大的表按照某个属性维度分成不同的小表。但需要注意的是,分拆在提升数据库性能的同时,也会增加维护和使用成本。

    四、SQL语句优化

    1. SELECT子句中避免使用 " * ":
    ORACLE在解析的过程中, 会将"*" 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间。
    
    1. sql语句用大写的:
    因为oracle总是先解析sql语句,把小写的字母转换成大写的再执行。
    
    1. WHERE子句中的连接顺序:
    ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。
    
    1. 尽量多使用COMMIT:
    只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求也会因为COMMIT所释放的资源而减少:
    COMMIT所释放的资源:
    	a. 回滚段上用于恢复数据的信息.
    	b. 被程序语句获得的锁
    	c. redo log buffer 中的空间
    
    1. 用TRUNCATE替代DELETE:
    当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存放可以被恢复的信息. 
    如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用TRUNCATE, 回滚段不再存放任何可被恢复的信息.
    当命令运行后,数据不能被恢复.因此很少的资源被调用,执行时间也会很短. ( TRUNCATE只在删除全表适用,TRUNCATE是DDL不是DML)
    1. 用EXISTS替代IN、用NOT EXISTS替代NOT IN:
    在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行联接.
    在这种情况下, 使用EXISTS(NOT EXISTS)通常将提高查询的效率. 在子查询中,NOT IN子句将执行一个内部的排序和合并. 
    无论在哪种情况下,NOT IN都是最低效的 (因为它对子查询中的表执行了一个全表遍历). 为了避免使用NOT IN ,我们可以把它改写成外连接(Outer Joins)NOT EXISTS.
    
    --例子:
    ---(高效) 
    SELECT * FROM EMP (基础表) WHERE EMPNO > 0 AND EXISTS ( SELECT ‘X ' FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = ‘MELB' )
    ---(低效) 
    SELECT * FROM EMP (基础表) WHERE EMPNO > 0 AND DEPTNO IN ( SELECT DEPTNO FROM DEPT WHERE
    
    1. 用EXISTS替换DISTINCT:
    当提交一个包含一对多表信息(比如部门表和雇员表)的查询时,避免在SELECT子句中使用DISTINCT. 一般可以考虑用EXIST替换, EXISTS 使查询更为迅速,因为RDBMS核心模块将在子查询的条件一旦满足后,立刻返回结果. 
    例子:
    (低效): 
    SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E 
    WHERE D.DEPT_NO = E.DEPT_NO
    (高效): 
    SELECT DEPT_NO,DEPT_NAME FROM DEPT D WHERE EXISTS ( SELECT ‘X' 
    FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO);
    
    1. 避免在索引列使用not,is null ,is not null ,以及使用计算。

    2. 用>= 替代>

    3. 用UNION替换OR (适用于索引列)

    通常情况下,UNION替换WHERE子句中的OR将会起到较好的效果. 对索引列使用OR将造成全表扫描. 注意, 以上规则只针对多个索引列有效. 如果有column没有被索引, 查询效率可能会因为你没有选择OR而降低. 在下面的例子中, LOC_ID 和REGION上都建有索引.
    
    高效: 
    SELECT LOC_ID , LOC_DESC , REGION 
    FROM LOCATION 
    WHERE LOC_ID = 10 
    UNION 
    SELECT LOC_ID , LOC_DESC , REGION 
    FROM LOCATION 
    WHERE REGION = “MELBOURNE”
    低效: 
    SELECT LOC_ID , LOC_DESC , REGION 
    FROM LOCATION 
    WHERE LOC_ID = 10 OR REGION = “MELBOURNE”
    如果你坚持要用OR, 那就需要返回记录最少的索引列写在最前面.
    
    1. 用 in 替换 or 。
    2. 总是使用索引的第一个列:
    如果索引是建立在多个列上, 只有在它的第一个列(leading column)where子句引用时,优化器才会选择使用该索引.
    这也是一条简单而重要的规则,当仅引用索引的第二个列时,优化器使用了全表扫描而忽略了索引。
    
    1. 避免改变索引列的类型.:
    当比较不同数据类型的数据时, ORACLE自动对列进行简单的类型转换.
    假设 EMPNO是一个数值类型的索引列.
    
    SELECTFROM EMP WHERE EMPNO =123'
    实际上,经过ORACLE类型转换, 语句转化为:
    
    SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(‘123')
    幸运的是,类型转换没有发生在索引列上,索引的用途没有被改变.
    现在,假设EMP_TYPE是一个字符类型的索引列.
    SELECTFROM EMP WHERE EMP_TYPE = 123
    这个语句被ORACLE转换为:
    
    SELECTFROM EMP WHERETO_NUMBER(EMP_TYPE)=123
    因为内部发生的类型转换, 这个索引将不会被用到! 为了避免ORACLE对你的SQL进行隐式的类型转换, 最好把类型转换用显式表现出来. 注意当字符和数值比较时, ORACLE会优先转换数值类型到字符类型
    
    展开全文
  • 数据库调优

    2021-06-18 20:58:16
    数据库调优的目标 一般lai'sh数据库调优的目的就是要让数据库运行得更快,也就是说响应的时间更快,吞吐量更大。不过随着用户量的不断增加,以及应用程序复杂度的提升,我们很难用“更快”去定义数据库调优的目标,...

    数据库调优的目标

    一般来说,数据库调优的目的就是要让数据库运行得更快,响应的时间更快,吞吐量更大。但是随着用户量的不断增加,以及应用程序复杂度的提升,数据库调优有了不同的目标,因为用户在不同时间段访问服务器遇到的瓶颈不同,比如双十一促销的时候会带来大规模的并发访问;还有用户在进行不同业务操作的时候,数据库的事务处理和 SQL 查询都会有所不同。因此我们还需要更加精细的定位,去确定调优的目标。

    1. 通过用户的反馈去确定调优的目标:用户是服务对象,因此他们的反馈是最直接的。

    2. 通过日志分析:我们可以通过查看数据库日志和操作系统日志等方式找出异常情况,通过它们来定位遇到的问题。

    3.通过服务器资源使用监控:通过监控服务器的 CPU、内存、I/O 等使用情况,可以实时了解服务器的性能使用,与历史情况进行对比。

    4. 数据库内部状况监控:在数据库的监控中,活动会话监控是一个重要的指标。通过它,你可以清楚地了解数据库当前是否处于非常繁忙的状态,是否存在 SQL 堆积等。

    数据调优的维度:

    1. 选择适合的 DBMS

    不同的DBMS有不同的特点,DBMS 的选择关系到了后面的整个设计过程,所以第一步就是要选择适合的 DBMS。

    2. 优化表设计

    ①表结构要尽量遵循第三范式的原则。这样可以让数据结构更加清晰规范,减少冗余字段,同时也减少了在更新,插入和删除数据时等异常情况的发生。

    ②如果分析查询应用比较多,尤其是需要进行多表联查的时候,可以采用反范式进行优化。反范式采用空间换时间的方式,通过增加冗余字段提高查询的效率。

    ③表字段的数据类型选择,关系到了查询效率的高低以及存储空间的大小。一般来说,如果字段可以采用数值类型就不要采用字符类型;字符长度要尽可能设计得短一些。

    3. 优化逻辑查询

    SQL 查询优化,可以分为逻辑查询优化和物理查询优化。逻辑查询优化就是通过改变 SQL 语句的内容让 SQL 执行效率更高效,采用的方式是对 SQL 语句进行等价变换,对查询进行重写。

    SQL 的查询重写包括了子查询优化、等价谓词重写、视图重写、条件简化、连接消除和嵌套连接消除等。

    EXISTS 子查询和 IN 子查询的时候,会根据小表驱动大表的原则选择适合的子查询。

    在 WHERE 子句中会尽量避免对字段进行函数运算,它们会让字段的索引失效。

    eg:

    SELECT ... FROM ... WHERE SUBSTRING(comment_text,1.3) = 'abc'

    改写为

    SELECT ... FROM ... WHERE comment_text  LIKE 'abc%'

    4. 优化物理查询

    物理查询优化是在确定了逻辑查询优化之后,采用物理优化技术(比如索引等),通过计算代价模型对各种可能的访问路径进行估算,从而找到执行方式中代价最小的作为执行计划。这个部分的核心是高效地建立索引,并通过这些索引来做各种优化。

    索引创建需要注意的情况:

    1. 如果数据重复度高,就不需要创建索引。通常在重复度超过 10% 的情况下,可以不创建这个字段的索引。比如性别这个字段(取值为男和女)。

    2. 要注意索引列的位置对索引使用的影响。比如我们在 WHERE 子句中对索引字段进行了表达式的计算,会造成这个字段的索引失效。

    3. 要注意联合索引对索引使用的影响。我们在创建联合索引的时候会对多个字段创建索引,这时索引的顺序就很重要了。比如我们对字段 x, y, z 创建了索引,那么顺序是 (x,y,z) 还是 (z,y,x),在执行的时候就会存在差别。

    4. 要注意多个索引对索引使用的影响。索引不是越多越好,因为每个索引都需要存储空间,索引多也就意味着需要更多的存储空间。此外,过多的索引也会导致优化器在进行评估的时候增加了筛选出索引的计算时间,影响评估的效率。

    5. 在物理查询优化阶段会根据数据表的索引情况和数据情况确定访问路径,这就决定了执行 SQL 时所需要消耗的资源,并决定这些查询所采用的路径:

    ① 单表查询:对于单表扫描来说,我们可以全表扫描所有的数据,也可以局部扫描。

    ②两张表的连接:常用的连接方式包括了嵌套循环连接、HASH 连接和合并连接。

    ③多张表的连接:多张数据表进行连接的时候,顺序很重要,因为不同的连接路径查询的效率不同,搜索空间也会不同。巨大的搜索空间会占用很多的资源,因此我们需要通过调整连接顺序,将搜索空间调整在一个可接收的范围内。

    5. 使用 Redis 或 Memcached 作为缓存

    因为数据都是存放到数据库中,我们需要从数据库层中取出数据放到内存中进行业务逻辑的操作,当用户量增大的时候,如果频繁地进行数据查询,会消耗数据库的很多资源。如果我们将常用的数据直接放到内存中,就会大幅提升查询的效率。

    键值存储数据库Redis 和 Memcached,它们都可以将数据存放到内存中。

    两者相比Redis 支持持久化,可以让我们的数据保存在硬盘上,不过这样一来性能消耗也会比较大。而 Memcached 仅仅是内存存储,不支持持久化。并且Redis支持的数据类型比 Memcached 要多。

    6. 库级优化

    库级优化是站在数据库的维度上进行的优化策略,比如控制一个库中的数据表数量。或是采用主从架构来优化读写策略。

    如果读和写的业务量都很大,并且它们都在同一个数据库服务器中进行操作,那么数据库的性能就会出现瓶颈,这时为了提升系统的性能,优化用户体验,我们可以采用读写分离的方式降低主数据库的负载,比如用主数据库(master)完成写操作,用从数据库(slave)完成读操作。

    分库:

    我们还可以对数据库分库分表。当数据量级达到亿级以上时,有时候我们需要把一个数据库切成多份,放到不同的数据库服务器上,减少对单一数据库服务器的访问压力。

    垂直切分和水平切分:

    垂直分库是指按照业务将表进行分类,分布到不同的数据库上面,每个库可以放在不同的服务器上,它的核心理念是专库专用。

    垂直分表:将一个表按照字段分成多表,每个表存储其中一部分字段。

    水平分库是把同一个表的数据按一定规则拆到不同的数据库中,每个库可以放在不同的服务器上。

    水平分表是在同一个数据库内,把同一个表的数据按一定规则拆到多个表中。

    采用垂直分表的形式,就是将一张数据表分拆成多张表,采用水平拆分的方式,就是将单张数据量大的表按照某个属性维度分成不同的小表。分拆在提升数据库性能的同时,也会增加维护和使用成本。

    如果数据库中的数据表过多,可以采用垂直分库的方式,将关联的数据表部署在一个数据库上。如果数据表中的列过多,可以采用垂直分表的方式,将数据表分拆成多张,把经常一起使用的列放到同一张表里。

    如果数据表中的数据达到了亿级以上,可以考虑水平分表将大的数据表分拆成不同的子表,每张表保持相同的表结构。比如你可以按照年份来划分,把不同年份的数据放到不同的数据表中。2017 年、2018 年和 2019 年的数据就可以分别放到三张数据表中。

    展开全文
  • 数据库调优-3

    2021-01-06 10:32:04
    面试官一问到数据库调优的,除了加索引大家还知道别的么? 或者索引相关的点你全部都知道么?聚簇索引,非聚簇索引,普通索引,唯一索引,change buffer,表锁、行锁、间隙锁以及行锁,还有索引为啥会选择错误?...

    面试官一问到数据库调优的,除了加索引大家还知道别的么?

    或者索引相关的点你全部都知道么?聚簇索引,非聚簇索引,普通索引,唯一索引,change buffer,表锁、行锁、间隙锁以及行锁,还有索引为啥会选择错误?这些大家知道嘛?

    排除缓存干扰

    因为在mysql8.0之前我们的数据库是存在缓存这样的情况,因为存在缓存,大多时候sql怎么执行都是很快的,当然第一次其实不快,只是没有注意到。以至于上线后因为缓存经常失效,导致rt(response time)时高时低

    后面发现是缓存的问题,我们在执行sql的时候,记得加上sql_no_cache去执行sql,这样跑出来的时间就是真实的查询时间了。

    为什么缓存会失效,而且经常失效?

    如果我们当前的MySQL版本支持缓存而且我们又开启了缓存,那每次请求的查询语句和结果都会以key-value的形式缓存在内存中的。在数据库基础知识的结构图中,一个请求会先去看缓存是否存在,不存在才会走解析器。

    缓存失效比较频繁的原因就是,只要我们一对表进行更新,那这个表所有的缓存都会被清空,其实我们很少存在不更新的表,特别是我之前的电商场景,可能静态表可以用到缓存,但是我们都走大数据离线分析,缓存也就没用了。

    大家如果是8.0以上的版本就不用担心这个问题,如果是8.0之下的版本,记得排除缓存的干扰。

    Explain

    explain有哪些字段,分别有什么含义?

    这里不具体讨论每个字段,怕大家忘记我贴一遍图大家自己回忆一下。

    那我再问大家一下,你们认为统计这个统计的行数就是完全对的么?索引一定会走到最优索引么?

    当然我都这么问了,你们肯定也知道结果了,行数只是一个接近的数字,不是完全正确的,索引也不一定就是走最优的,是可能走错的。

    我的总行数大概有10W行,但是我去用explain去分析sql的时候,就会发现只得到了9.4W,为啥行数只是个近似值呢?

    看过基础章节的小伙伴都知道,MySQL中数据的单位都是页,MySQL又采用了采样统计的方法,采样统计的时候,InnoDB默认会选择N个数据页,统计这些页面上的不同值,得到一个平均值,然后乘以这个索引的页面数,就得到了这个索引的基数。

    我们数据是一直在变的,所以索引的统计信息也是会变的,会根据一个阈值,重新做统计。

    如果是上面的统计信息错了,那简单,我们用analyze table tablename就可以重新统计索引信息了,所以在实践中,如果你发现explain的结果预计的rows跟实际情况下差距比较大,可以采用这个方法来处理。

    至于MySQL索引可能走错也很好理解,如果走A索引要扫描100行,B所有只要20行,但是他可能选择走A索引,你可能会想MySQL是不是有病啊,其实不是的。

    一般走错都是因为优化器在选择的时候发现,走A索引没有额外的代价,比如走B索引并不能直接拿到我们的值,还需要回到主键索引才可以拿到数据,多了一次回表的过程,这个也是被优化器考虑进去的。

    他发现走A索引不需要回表,没有额外的开销,所以他选错了。

    有个方法是force index强制走正确的索引,或者优化sql,最后实在不行,可以新建索引,或者删除掉错误的索引

    覆盖索引

    上面提到了,可能需要回表这样的操作,那怎么做才能不回表呢?在自己的索引上就查到自己想要的数据,不用去主键索引查询了

    由于覆盖索引可以减少树的搜索次数,显著提升查询性能,所以使用覆盖索引是一个常用的性能优化手段。

    联合索引

    以商品表举例,我们需要根据他的名称,去查他的库存,假设这是一个很高频的查询请求,你会怎么建立索引呢?

    大家可以思考上面的回表的消耗对SQL进行优化。

    是的建立一个,名称和库存的联合索引,这样名称查出来就可以看到库存了,不需要查出id之后去回表再查询库存了,联合索引在我们开发过程中也是常见的,但是并不是可以一直建立的,大家要思考索引占据的空间。

    最左匹配原则

    大家在写sql的时候,最好能利用到现有的SQL最大化利用,像上面的场景,如果利用一个模糊查询 itemname like ’敖丙%‘,这样还是能利用到这个索引的,而且如果有这样的联合索引,大家也没必要去新建一个商品名称单独的索引了。

    很多时候我们索引可能没建对,那你调整一下顺序,可能就可以优化到整个SQL了。

    索引下推

    你已经知道了前缀索引规则,那我就说一个官方帮我们优化的东西,索引下推。

    select * from itemcenter where name like '敖%' and size=22 and age = 20;

    所以这个语句在搜索索引树的时候,只能用 “敖”,找到第一个满足条件的记录ID1,当然,这还不错,总比全表扫描要好。

    然后呢?

    当然是判断其他条件是否满足,比如size。

    在MySQL 5.6之前,只能从ID1开始一个个回表,到主键索引上找出数据行,再对比字段值。

    而MySQL 5.6 引入的索引下推优化(index condition pushdown), 可以在索引遍历过程中,对索引中包含的字段先做判断,直接过滤掉不满足条件的记录,减少回表次数。

    唯一索引,普通索引的选择

    核心是回答到change buffer。

    当需要更新一个数据页时,如果数据页在内存中就直接更新,如果不在,在不影响数据一致性的前提下,InnoDB会将这些更新操作缓存在change buffer中,这样就不需要从磁盘中读入这个数据页了。

    在下次查询需要访问这个数据页的时候,将数据页读入内存,然后执行change buffer中与这个页有关的操作,通过这种方式就能保证这个数据逻辑的正确性。

    需要说明的是,虽然名字叫做change buffer,实际上它是可以持久化的数据。也就是说,change buffer在内存中有拷贝,也会被写入磁盘上。

    将change buffer中的操作应用到原始数据页,得到最新结果的过程称为merge。

    除了访问这个数据页会触发merge外,系统有后台线程会定期merge。在数据库正常关闭的过程中,也会执行merge操作。

     显然,如果能够将更新操作先记录在change buffer,减少读磁盘,语句的执行速度会得到明显的提升。而且,数据读入内存是需要占用buffer pool的,所以这种方式还能够避免占用内存,提高内存利用率

    什么条件下可以使用change buffer呢?

    对于唯一索引来说,所有的更新操作都要先判断这个操作是否违反唯一性约束。

    要判断表中是否存在这个数据,而这必须要将数据页读入内存才能判断,如果都已经读入到内存了,那直接更新内存会更快,就没必要使用change buffer了。

    因此,唯一索引的更新就不能使用change buffer,实际上也只有普通索引可以使用。

    change buffer用的是buffer pool里的内存,因此不能无限增大,change buffer的大小,可以通过参数innodb_change_buffer_max_size来动态设置,这个参数设置为50的时候,表示change buffer的大小最多只能占用buffer pool的50%

    将数据从磁盘读入内存涉及随机IO的访问,是数据库里面成本最高的操作之一,change buffer因为减少了随机磁盘访问,所以对更新性能的提升是会很明显的。

    change buffer的使用场景

    因为merge的时候是真正进行数据更新的时刻,而change buffer的主要目的就是将记录的变更动作缓存下来,所以在一个数据页做merge之前,change buffer记录的变更越多(也就是这个页面上要更新的次数越多),收益就越大。

    因此,对于写多读少的业务来说,页面在写完以后马上被访问到的概率比较小,此时change buffer的使用效果最好,这种业务模型常见的就是账单类、日志类的系统。

    反过来,假设一个业务的更新模式是写入之后马上会做查询,那么即使满足了条件,将更新先记录在change buffer,但之后由于马上要访问这个数据页,会立即触发merge过程。这样随机访问IO的次数不会减少,反而增加了change buffer的维护代价,所以,对于这种业务模式来说,change buffer反而起到了副作用。

    前缀索引

    我们存在邮箱作为用户名的情况,每个人的邮箱都是不一样的,那我们是不是可以在邮箱上建立索引,但是邮箱那么长,我们怎么去建立索引呢?

    mysql是支持前缀索引的,也就是说,你可以定义字符串的一部分作为索引。默认的,如果你创建索引的语句不指定前缀长度,那么索引就会包含整个字符串。

    我们是否可以建立一个区分度很高的前缀索引,达到优化和节约空间的目的呢?

    使用前缀索引,定义好长度,就可以做到既节省空间,又不用额外增加太多的查询成本。

    上线说过覆盖索引了,覆盖索引是不需要回表的,但是前缀索引,即使你的联合索引已经包含了相关信息,他还是会回表的,因为他不确定你到底是不是一个完整的信息,就算你是一个完整的邮箱去查询,他还是不知道你是否是完整的,所以他需要回表去判断一下。

    很长的字段,想做索引我们怎么去优化他呢?

    因为存在一个磁盘占用的问题,索引选取的越长,占用的磁盘空间就越大,相同的数据页能放下的索引值就越少,搜索的效率也会越低。

    可以使用hash,

    把字段hash为另外一个字段存起来,每次校验hash就好了,hash的索引也不大。

    我们都知道只要区分度过高,都可以,那我们可以采用倒序,或者删减字符串这样的情况去建立我们自己的区分度,不过大家需要注意的是,调用函数也是一次开销哟,这点当时没注意。

    就比如本来是 www.aobing@qq.com 其实前面的www.基本上是没任何区分度的,所有人的邮箱都是这么开头的,你一搜一大堆出来,放在索引还浪费内存,你可以substring()函数截取掉前面的,然后建立索引。

    我们所有人的身份证都是区域开头的,同区域的人很多,那怎么做良好的区分呢?REVERSE()函数翻转一下,区分度可能就高了。

    这些操作都用到了函数,我就说一下函数的坑。

    条件字段函数操作

    日常开发过程中,大家经常对很多字段进行函数操作,如果对日期字段操作,浮点字符操作等等,大家需要注意的是,如果对字段做了函数计算,就用不上索引了,这是MySQL的规定。

    对索引字段做函数操作,可能会破坏索引值的有序性,因此优化器就决定放弃走树搜索功能。

    需要注意的是,优化器并不是要放弃使用这个索引。

    这个时候大家可以用一些取巧的方法,比如 select * from tradelog where id + 1 = 10000 就走不上索引,select * from tradelog where id = 9999 就可以。

    隐式类型转换

    select * from t where id = 1

    如果id是字符类型的,1是数字类型的,你用explain会发现走了全表扫描,根本用不上索引,为啥呢?

    因为MySQL底层会对你的比较进行转换,相当于加了 CAST( id AS signed int) 这样的一个函数,上面说过函数会导致走不上索引。

    隐式字符编码转换

    还是一样的问题,如果两个表的字符集不一样,一个是utf8mb4,一个是utf8,因为utf8mb4是utf8的超集,所以一旦两个字符比较,就会转换为utf8mb4再比较。

    转换的过程相当于加了CONVERT(id USING utf8mb4)函数,那又回到上面的问题了,用到函数就用不上索引了。

    flush

    redo log大家都知道,也就是我们对数据库操作的日志,他是在内存中的,每次操作一旦写了redo log就会立马返回结果,但是这个redo log总会找个时间去更新到磁盘,这个操作就是flush。

    在更新之前,当内存数据页跟磁盘数据页内容不一致的时候,我们称这个内存页为“脏页”。

    内存数据写入到磁盘后,内存和磁盘上的数据页的内容就一致了,称为“干净页“。

    那什么时候会flush呢?

    1. InnoDB的redo log写满了,这时候系统会停止所有更新操作,把checkpoint往前推进,redo log留出空间可以继续写。

    2. 系统内存不足,当需要新的内存页,而内存不够用的时候,就要淘汰一些数据页,空出内存给别的数据页使用。如果淘汰的是“脏页”,就要先将脏页写到磁盘。

    3. MySQL认为系统“空闲”的时候,只要有机会就刷一点“脏页”。

    4. MySQL正常关闭,这时候,MySQL会把内存的脏页都flush到磁盘上,这样下次MySQL启动的时候,就可以直接从磁盘上读数据,启动速度会很快。

    那我们怎么做才能把握flush的时机呢?

    Innodb刷脏页控制策略,我们每个电脑主机的io能力是不一样的,你要正确地告诉InnoDB所在主机的IO能力,这样InnoDB才能知道需要全力刷脏页的时候,可以刷多快。

    这就要用到innodb_io_capacity这个参数了,它会告诉InnoDB你的磁盘能力,这个值建议设置成磁盘的IOPS,磁盘的IOPS可以通过fio这个工具来测试。

    正确地设置innodb_io_capacity参数,可以有效的解决这个问题。

    这中间有个有意思的点,刷脏页的时候,旁边如果也是脏页,会一起刷掉的,并且如果周围还有脏页,这个连带责任制会一直蔓延,这种情况其实在机械硬盘时代比较好,一次IO就解决了所有问题,

    但是现在都是固态硬盘了,innodb_flush_neighbors=0这个参数可以不产生连带制,在MySQL 8.0中,innodb_flush_neighbors参数的默认值已经是0了

    总结:

    下一章,我们说下MVCC和事务隔离级别

    展开全文
  • MySQL 数据库调优

    2021-05-07 10:40:01
    数据库的查询速度进行优化; 一些SQL的编写注意事项; 查询出sql的执行计划,并以此进行专门优化的步骤详解

    数据库查询语句调优录

    SQL调优的三个方向:

    • 数据库对象的设计
    • 常规查询语句的编写注意事项
    • 根据SQL的执行计划进行定向优化

    1. 数据库对象优化

    数据库对象的设计优劣直接决定了SQL语句执行性能的上限,如果设计不当会导致很多的性能问题.
    

    1.1 字段类型的优化

    • 字段类型尽量短
    • 字段类型尽量高效: 整型>浮点型>字符串
    • 字段类型的长度需要设计冗余,避免后期因业务变更导致需要更改数据库结构

    1.2 表的拆分

    影响表的查询效率的一个比较大的因素是数据量.
    为了避免因数据量的增多而导致SQL语句执行缓慢,在表的设计初期会考虑表的拆分操作.一般表的拆分分为两种:

    • 水平表拆分:分区-RANGE,LIST,HASH,KEY等.
    • 垂直表拆分:根据业务逻辑将一张表中常用列和非常用列拆分出来,使得单条数据行变小,提高查询效率,但查询所有数据需要JOIN操作(使用join会使查询效率变低).

    1.3 反范式操作

    数据库表的范式设计能使得表之间的结构清晰,表之间的关系复杂,表之间的JOIN操作频繁,而JOIN操作属于性能较低的操作,会影响查询性能.因此对于一些JOIN查询较多的业务场景,需要根据实际情况采用反范式的方式来对数据库进行设计.

    • 增加冗余列:在多个表中具有相同的列;
    • 增加派生列:增加的列来自其他表数据或有其他表的数据计算生成,避免使用集函数;
    • 重新生表: 用户经常那个需要查看多个表的JOIN结果,把这些表重新组成一个表;
    • 分割表:表的拆分操作;

    1.4 中间表设计

    针对某些特定数据量比较大的表,用户需要先筛选然后做分析时,中间表的设计会使得查询效率变高.

    • 中间表需要和源表结构完全相同.
    • 一般先将需要统计的表数据转移到中间表上,然后再中间表上做统计
    • 中间表的设计有如下优点:
      • 与源表’隔离’,在中间表上做统计操作不会对源表产生影响
      • 中间表可以灵活添加索引或新增临时的新字段从而提高查询效率和辅助统计查询.

    1.5 索引设计

    索引建立和使用规则

    • 索引字段尽量小;
    • 最左前匹配原则;
    • =和in可以乱序;
    • 尽量选择区分度高的列作为索引列
    • 索引列不能参与计算,保持列’干净’
    • 尽量地扩展索引,不要新建索引

    2 常见的SQL语句调优

    • 当使用INSERT插入多行记录时,使用INSERT INTO table_name VALUES () , (),…();
    • SELECT语句尽量不要使用*
    • 尽量少使用GROUP BY,一般建议通过关联查询和DISTINCT代替
      • GROUP BY非要用的话,在分组字段上添加索引
    • 查询一条记录时,使用 LIMIT 1.
    • 灵活的使用EXISTS和IN,NOT EXISTS和NOT IN:
      • EXISTS和IN:有两个待查询的表,当两表数据量差别不大时,使用起来差别不大;若两个表一大一小,则子查询大表时,推荐使用EXISTS;子查询小表时,推荐使用IN,例:
        • A表>B表: select * from A where id in (select id from B);
        • A表<B表: select * from A where exists ( select 1 from B where B.id=A.id);
      • NOT EXISTS和NOT IN: 用NOT EXISTS总是比NOT IN效率高
    • 多用函数,根据业务需求搭配合适的函数,减少数据再转换
    • 大量数据插入时,先删除索引及约束并关闭自动提交,等数据插入完成后,再重新创建索引和约束
    • 适当添加索引
    • 不提倡使用JOIN,但若不得不用时,需要注意使用JOIN时要以小表去驱动大表.例:小表 left join 大表

    3. 根据EXPLAIN的SQL执行计划进行SQL调优

    3.1 调优步骤

    1. 查看type类型为All的计划(即进行全表扫描的SQL).优化查询逻辑

    2. 查看extra为Using where的计划,进行索引向的优化.

    3. 对于创建了索引但未生效的计划,可以使用Hint语法强制使用索引(需要适配使用索引的原则)
      SELECT 某字段 FROM 某表 FORCE INDEX(索引名) WHERE …

    4. 虽然不提倡使用JOIN,但若不得不用时,需要注意使用JOIN时要以小表去驱动大表.
      小表 left join 大表; 大表 right join 小表; 小表 straight_join 大表(功能同join类似,但能让左边的表来驱动右边的表);

    3.2 关于explain

    在这里插入图片描述

    • id:SQL执行的顺序的标识,Id越大优先级越高,相同Id则从上到下执行
    • select_type:
      • SIMPALE:简单select,不适用union或子查询等
      • PRIMARY: 子查询中最外层查询,查询中若包含子查询,最外层的select被标记为primary.
      • UNION: union中的第二个或后面的select语句.
      • DEPENDENT UNION: union中的第二个或后面的select语句.
      • UNION RESULT: UNION的结果.
      • SUBQUERY: 子查询中的第一个select,结果不依赖于外部查询.
      • DEPENDENT SUBQUERY: 子查询中的第一个select,依赖于外部查询.
      • DERIVED: 派生表的select, FROM子句的子查询
      • UNCACHEABLE SUBQUERY: 一个子查询的结果不能被缓存,必须重新评估外链接的第一行
    • table: 访问的数据库中表的名称,有时不是真实的表的名字,可能是简称
    • type: 对表的访问方式,表示在表中找到所需行的方式,又称’访问类型’.从上到下,性能越来越好
      • ALL:Full Table Scan, MySQL将遍历全表以找到匹配的行.
      • index: Full Index Scan,index与ALL区别为index类型只遍历索引树.
      • range:只检索给定范围的行,使用一个索引来选择行.
      • Index_range:表示使用了索引合并的优化方法.
      • Ref_or_null: 类似ref,可以搜索值为NULL的行.
      • Ref: 表示上述表的连接匹配条件,即哪些列或常量被用于查找索引列上的值.
      • eq_ref: 类似ref,区别就在使用的索引是唯一索引,对于每个索引键值,表中只有一条记录匹配,简单来说,就是多表连接中使用primary key或者 unique key作为关联条件.
      • const、system: 当MySQL对查询某部分进行优化,并转换为一个常量时,使用这些类型访问。如将主键置于where列表中,MySQL就能将该查询转换为一个常量,system是const类型的特例,当查询的表只有一行的情况下,使用system.
      • NULL: MySQL在优化过程中分解语句,执行时甚至不用访问表或索引,例如从一个索引列里选取最小值可以通过单独索引查找完成.
    • possible_keys:指出MySQL能使用哪个索引在表中找到记录,查询涉及到的字段上若存在索引,则该索引将被列出,但不一定被查询使用.
    • key: 显示MySQL实际决定使用的键(索引) .如果没有选择索引,键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引,在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX.
    • key_len: 表示索引中使用的字节数,可通过该列计算查询中使用的索引的长度(key_len显示的值为索引字段的最大可能长度,并非实际使用长度,即key_len是根据表定义计算而得,不是通过表内检索出的)不损失精确性的情况下,长度越短越好.
    • Ref 表示上述表的连接匹配条件,即哪些列或常量被用于查找索引列上的值.
    • Rows 表示MySQL根据表统计信息及索引选用情况,估算的找到所需的记录所需要读取的行数.
    • Extra :解决查询的详细信息,如果出现下面的Using temporary和Using filesort说明查询效率低
      • Using where:列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的,这发生在对表的全部的请求列都是同一个索引的部分的时候,表示mysql服务器将在存储引擎检索行后再进行过滤.
      • Using temporary:表示MySQL需要使用临时表来存储结果集,常见于排序和分组查询.
      • Using filesort:MySQL中无法利用索引完成的排序操作称为“文件排序”.
      • Using join buffer:改值强调了在获取连接条件时没有使用索引,并且需要连接缓冲区来存储中间结果.如果出现了这个值,那应该注意,根据查询的具体情况可能需要添加索引来改进能.
      • Impossible where:这个值强调了where语句会导致没有符合条件的行.
      • Select tables optimized away:这个值意味着仅通过使用索引,优化器可能仅从聚合函数结果中返回一行
      • No table used: Query语句中使用from dual 或不含任何from子句.

    EXPLAIN总结

    - EXPLAIN无法获取触发器,存储过程以及用户自定义函数对查询的影响
    - EXPLAIN不考虑Cache
    - EXPLAIN无法显示数据库在执行查询时做的优化工作
    - EXPALIN产生的统计信息是估算的,并非精确
    - EXPALIN一般针对SELECT语句,其他操作要重写为select后查看执行计划
    
    展开全文
  • Java性能调优常用方法

    2021-04-13 00:55:49
    Java应用的性能优化也是一个老生常谈的话题,但是只要我们深入的了解性能调优方法,走遍天下都不怕!根据我的个人经验,将Java性能优化分为4个层级:应用层、数据库层、框架层、JVM 层。通过介绍Java性能诊断工具和...
  • DM8达梦数据库SQL调优

    2021-10-18 23:55:08
    执行计划常用操作符解读 NEST 收集结果集,用于结果集收集的操作符,一般是查询计划的顶层节点。 PRJT 投影,用于选择表达式项的计算;广泛用于查询,排序,函数索引创建等。 SLCT 选择,用于查询条件的过滤。 ...
  • 数据库调优1.1.修改数据库参数以sys用户登录,运行如下的命令:alter system set optimizer_index_cost_adj=10 scope=spfilealter system set optimizer_dynamic_sampling=5 scope=spfileoptimizer_index_cost_adj...
  • 数据库调优分层思想

    2021-01-28 03:22:39
    数据库调优分层思想1.调优策略1)*号的处理(只提取必要字段,减少流量)最好是用,有用的字段,减少流量。表结构会改变,增加或者减少某列,如果*号全部查询出来 会造成代码逻辑错误。2)大SQL(拆分,逐步缩小结果集)大...
  • mysql数据库调优基本上是面试必问的,不过平时工作中用的还是有点偏少,容易忘记,还是记录一下,时常可以看看,今天时间不充足了,暂且写一点,然后在不断补充 1.慢查询优化
  • 很多的时侯,做oracle dba的我们,当应用管理员向我们通告现在应用很慢、数据库很慢的时侯,我们到数据库时做几个示例的select也发现同样的问题时,有些时侯我们会无从下手,因为我们认为数据库的各种命种率都是满足...
  • 文章目录前言数据库调优的目标用户的反馈日志分析服务器资源使用监控数据库内部状况监控对数据库调优的维度第一步,选择适合的 DBMS第二步,优化表设计第三步,优化逻辑查询第四步,优化物理查询 前言 关于数据库...
  • 1、硬件层相关优化修改服务器BIOS设置选择Performance Per Watt Optimized(DAPC)模式,发挥CPU最大性能。Memory Frequency(内存频率)选择Maximum Performance(最佳性能)内存设置菜单中,启用Node Interleaving,避免...
  • MySQL数据库的性能监控 查看MySQL的连接数 连接数指的是用户已经创建多少个连接 运行线程数详情 MySQL中执行SHOW PROCESSLIST命令输出数据库中运行着的线程数个数的详情 SHOW PROCESSLIST 查询结果 SHOW ...
  • 做业务,要懂基本的SQL语句;...数据库调优与最佳实践; 面试考察点及加分项。 知识点汇总 打开百度APP看高清图片 一、数据库的不同类型 1 1.常用的关系型数据库 Oracle:功能强大,主要缺点就是贵
  • spark调优常见手段,在生产中常常会遇到各种各样的问题,有事前原因,有事中原因,也有不规范原因,spark调优总结下来可以从下面几个点来调优。 1. 分配更多的资源 分配更多的资源: 它是性能优化调优的王道,就是...
  • 主要描述了数据库连接池参数配置的准则,针对常用数据库连接池(c3p0,dbcp,druid)给出推荐的配置考虑因素1:当前连接DB的规模 2:并发情况 3:执行db的响应时间配置考虑1:初始化连接:可考虑设置为3个连接 。...
  • 二、MySQL调优之事务:高并发场景下的数据库事务调优 常用数据库引擎为InnoDB和MyISAM,MyISAM不支持事务处理,所以Mysql事务基于InnoDB引擎。 数据库事务具有以下四个基本属性:原子性(Atomicity)、一致性...
  • mysql作为一款大众免费开源的关系型数据库软件,受到很多“穷屌丝”企业的热烈欢迎,看一下目前最新数据库排行,Mysql排在第二位,仅此于oracle,看来被甲骨文收购后,市场地位上升了很多。 Jul 2021 Jun ...
  • 你如何理解Spring Boot 中的Starters Springboot常用的star ter有哪些 Spr ingBoot实现热部署有哪几种方式 如何理解Spring Boot配置加载顺序 Spring Boot的核心配置文件有哪几个?它们的区别是什么? 如何集成Spring ...
  • 互联网时代,一个简单的系统就囊括了应用程序、数据库、容器、操作系统、网络等技术,线上一旦出现性能问题,就可能要你协调多方面组件去进行优化,这就是技术广度;而很多性能问题呢,又隐藏得很深,可能...
  • 性能与压力测试

    2021-02-01 22:32:08
    服务器内存) 静态资源 5、 JVM 分析&调优 1、几个常用工具 2、命令示例 3、调优项 1、性能压测-优化-nginx动静分离 在这里插入图片描述 1)上传静态资源到nginx服务器 在/mydata/nginx/html/路径下创建static/...
  • JVM优化原理深度分析及JVM调优实战
  • sql调优常用命令

    2021-01-28 13:35:33
    常用sql调优常用命令 -- 数据库中各种sql的执行频率 show STATUS like '%innodb_rows%'; -- 执行计划 EXPLAIN SELECT * from `user`; -- 分析sql(剖析) show profile; -- 慢查询时间配置 show variables like ...
  • 数据库优化方法总结

    2021-03-27 15:56:45
    子查询笛卡尔积过高,数据量较大的场合,对数据库性能消耗过大,可能使数据库卡死崩溃 3.使用联合 使用联合(UNION)来代替手动创建的临时表 4.事物 当需要执行多条sql来满足一个需求时,事物可以很好的保持数据
  • mysql数据库优化

    2021-02-02 11:03:20
    1.数据库自身的优化a. 如何选择mysql的存储引擎:innodb:事务要求高,保存的数据都是重要数据,如订单表,账号表.;myisam:事务要求不高,查询和添加为主的,如bbs中的发帖表,回复表,但是不支持外键(一定要定时...
  • 一、调优思路 1.数据库设计与规划–以后再修该很麻烦,估计数据量,使用什么存储引擎 2.数据的应用–怎样取数据,sql语句的优化 3.mysql服务优化–内存的使用,磁盘的使用 4.操作系统的优化–内核 5.升级硬件设备 6...
  • 宝塔面板优化之Mysql数据库性能调优

    千次阅读 2021-01-19 04:32:03
    通常,我们会使用redis、memcached等缓存软件来缓存内容,这确实是最优的解决方案之一,但这需要网站程序的支持,然而多数常用网站程序并不支持或者不能完美支持这些缓存软件,今天我们就来谈谈如何通过MySQL自身的...
  • MySQL常用的SQL调优手段或工具有哪些在一个2c4g的服务器上如何用python操作8GB的超大文件MySQL反应慢的排查思路一、MySQL binlog_format=mixed,可行吗,为什么不可行,因为会导致主从数据不一致Mixe...
  • 一、问题分析考官主要是对数据库优化方面的考核,一般数据库优化分为性能和应用方面的,如你了解sql优化吗;百万数据怎么优化等二、核心答案讲解1、根据服务层面、配置mysql性能优化参数;2、从系统层面增强mysql的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 46,270
精华内容 18,508
关键字:

数据库调优常用方法