精华内容
下载资源
问答
  • 数据库优化 - SQL优化

    万次阅读 多人点赞 2019-11-01 21:00:00
    以实际SQL入手,带你一步一步走上SQL优化之路!
    前面一篇文章从实例的角度进行数据库优化,通过配置一些参数让数据库性能达到最优。但是一些“不好”的SQL也会导致数据库查询变慢,影响业务流程。本文从SQL角度进行数据库优化,提升SQL运行效率。

    判断问题SQL

    判断SQL是否有问题时可以通过两个表象进行判断:

    • 系统级别表象
      • CPU消耗严重
      • IO等待严重
      • 页面响应时间过长
      • 应用的日志出现超时等错误

    可以使用sar命令,top命令查看当前系统状态。

    也可以通过Prometheus、Grafana等监控工具观察系统状态。(感兴趣的可以翻看我之前的文章)
    640?wx_fmt=png

    • SQL语句表象
      • 冗长
      • 执行时间过长
      • 从全表扫描获取数据
      • 执行计划中的rows、cost很大

    冗长的SQL都好理解,一段SQL太长阅读性肯定会差,而且出现问题的频率肯定会更高。更进一步判断SQL问题就得从执行计划入手,如下所示:640?wx_fmt=png

    执行计划告诉我们本次查询走了全表扫描Type=ALL,rows很大(9950400)基本可以判断这是一段"有味道"的SQL。

    获取问题SQL

    不同数据库有不同的获取方法,以下为目前主流数据库的慢查询SQL获取工具

    • MySQL

      • 慢查询日志
      • 测试工具loadrunner
      • Percona公司的ptquery等工具
    • Oracle

      • AWR报告
      • 测试工具loadrunner等
      • 相关内部视图如v$、$session_wait等
      • GRID CONTROL监控工具
    • 达梦数据库

      • AWR报告
      • 测试工具loadrunner等
      • 达梦性能监控工具(dem)
      • 相关内部视图如v$、$session_wait等

    SQL编写技巧

    SQL编写有以下几个通用的技巧:

    • 合理使用索引

    索引少了查询慢;索引多了占用空间大,执行增删改语句的时候需要动态维护索引,影响性能 选择率高(重复值少)且被where频繁引用需要建立B树索引;

    一般join列需要建立索引;复杂文档类型查询采用全文索引效率更好;索引的建立要在查询和DML性能之间取得平衡;复合索引创建时要注意基于非前导列查询的情况

    • 使用UNION ALL替代UNION

    UNION ALL的执行效率比UNION高,UNION执行时需要排重;UNION需要对数据进行排序

    • 避免select * 写法

    执行SQL时优化器需要将 * 转成具体的列;每次查询都要回表,不能走覆盖索引。

    • JOIN字段建议建立索引

    一般JOIN字段都提前加上索引

    • 避免复杂SQL语句

    提升可阅读性;避免慢查询的概率;可以转换成多个短查询,用业务端处理

    • 避免where 1=1写法

    • 避免order by rand()类似写法

    RAND()导致数据列被多次扫描

    SQL优化

    执行计划

    完成SQL优化一定要先读执行计划,执行计划会告诉你哪些地方效率低,哪里可以需要优化。我们以MYSQL为例,看看执行计划是什么。(每个数据库的执行计划都不一样,需要自行了解)explain sql640?wx_fmt=png

    字段 解释
    id 每个被独立执行的操作标识,标识对象被操作的顺序,id值越大,先被执行,如果相同,执行顺序从上到下
    select_type 查询中每个select 字句的类型
    table 被操作的对象名称,通常是表名,但有其他格式
    partitions 匹配的分区信息(对于非分区表值为NULL)
    type 连接操作的类型
    possible_keys 可能用到的索引
    key 优化器实际使用的索引(最重要的列) 从最好到最差的连接类型为consteq_regrefrangeindexALL。当出现ALL时表示当前SQL出现了“坏味道”
    key_len 被优化器选定的索引键长度,单位是字节
    ref 表示本行被操作对象的参照对象,无参照对象为NULL
    rows 查询执行所扫描的元组个数(对于innodb,此值为估计值)
    filtered 条件表上数据被过滤的元组个数百分比
    extra 执行计划的重要补充信息,当此列出现Using filesort , Using temporary 字样时就要小心了,很可能SQL语句需要优化

    接下来我们用一段实际优化案例来说明SQL优化的过程及优化技巧。

    优化案例

    • 表结构

      CREATE TABLE `a`
      (
          `id`          int(11) NOT NULLAUTO_INCREMENT,
          `seller_id`   bigint(20)                                       DEFAULT NULL,
          `seller_name` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
          `gmt_create`  varchar(30)                                      DEFAULT NULL,
          PRIMARY KEY (`id`)
      );
      CREATE TABLE `b`
      (
          `id`          int(11) NOT NULLAUTO_INCREMENT,
          `seller_name` varchar(100) DEFAULT NULL,
          `user_id`     varchar(50)  DEFAULT NULL,
          `user_name`   varchar(100) DEFAULT NULL,
          `sales`       bigint(20)   DEFAULT NULL,
          `gmt_create`  varchar(30)  DEFAULT NULL,
          PRIMARY KEY (`id`)
      );
      CREATE TABLE `c`
      (
          `id`         int(11) NOT NULLAUTO_INCREMENT,
          `user_id`    varchar(50)  DEFAULT NULL,
          `order_id`   varchar(100) DEFAULT NULL,
          `state`      bigint(20)   DEFAULT NULL,
          `gmt_create` varchar(30)  DEFAULT NULL,
          PRIMARY KEY (`id`)
      );
      
    • 三张表关联,查询当前用户在当前时间前后10个小时的订单情况,并根据订单创建时间升序排列,具体SQL如下

      select a.seller_id,
             a.seller_name,
             b.user_name,
             c.state
      from a,
           b,
           c
      where a.seller_name = b.seller_name
        and b.user_id = c.user_id
        and c.user_id = 17
        and a.gmt_create
          BETWEEN DATE_ADD(NOW(), INTERVAL – 600 MINUTE)
          AND DATE_ADD(NOW(), INTERVAL 600 MINUTE)
      order by a.gmt_create;
      
    • 查看数据量  

      640?wx_fmt=png

    • 原执行时间
      640?wx_fmt=png

    • 原执行计划
      640?wx_fmt=png

    • 初步优化思路

    1. SQL中 where条件字段类型要跟表结构一致,表中user_id 为varchar(50)类型,实际SQL用的int类型,存在隐式转换,也未添加索引。将b和c表user_id 字段改成int类型。
    2. 因存在b表和c表关联,将b和c表user_id创建索引
    3. 因存在a表和b表关联,将a和b表seller_name字段创建索引
    4. 利用复合索引消除临时表和排序

    初步优化SQL

    alter table b modify `user_id` int(10) DEFAULT NULL;
    alter table c modify `user_id` int(10) DEFAULT NULL;
    alter table c add index `idx_user_id`(`user_id`);
    alter table b add index `idx_user_id_sell_name`(`user_id`,`seller_name`);
    alter table a add index `idx_sellname_gmt_sellid`(`gmt_create`,`seller_name`,`seller_id`);
    

    查看优化后执行时间

    640?wx_fmt=png

    查看优化后执行计划
    640?wx_fmt=png

    查看warnings信息
    640?wx_fmt=png

    继续优化alter table a modify "gmt_create" datetime DEFAULT NULL;

    查看执行时间

    640?wx_fmt=png

    查看执行计划
    640?wx_fmt=png

    总结

    1. 查看执行计划 explain
    2. 如果有告警信息,查看告警信息 show warnings;
    3. 查看SQL涉及的表结构和索引信息
    4. 根据执行计划,思考可能的优化点
    5. 按照可能的优化点执行表结构变更、增加索引、SQL改写等操作
    6. 查看优化后的执行时间和执行计划
    7. 如果优化效果不明显,重复第四步操作
     

    系列文章

     
     

    温馨提示

    如果你喜欢本文,请关注我的个人公众号!或者关注我的个人博客www.javadaily.cn

    图片

     

     

    展开全文
  • 数据库优化

    千次阅读 2016-06-27 09:17:15
    数据库优化
    1、创建索引
    对于查询占主要的应用来说,索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的,或者说没有添加更为有效的索引导致。如果不加索引的话,那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描,如果一张表的数据量很大而符合条件的结果又很少,那么不加索引会引起致命的性能下降。但是也不是什么情况都非得建索引不可,比如性别可能就只有两个值,建索引不仅没什么优势,还会影响到更新速度,这被称为过度索引。
    2、复合索引
    比如有一条语句是这样的:select * from users where area='beijing' and age=22;
    如果我们是在area和age上分别创建单个索引的话,由于mysql查询每次只能使用一个索引,所以虽然这样已经相对不做索引时全表扫描提高了很多效率,但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了(area, age, salary)的复合索引,那么其实相当于创建了(area,age,salary)、(area,age)、(area)三个索引,这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边,依次递减。
    3、索引不会包含有NULL值的列
    只要列中包含有NULL值都将不会被包含在索引中,复合索引中只要有一列含有NULL值,那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。
    4、使用短索引
    对串列进行索引,如果可能应该指定一个前缀长度。例如,如果有一个CHAR(255)的 列,如果在前10 个或20 个字符内,多数值是惟一的,那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
    5、排序的索引问题
    mysql查询只使用一个索引,因此如果where子句中已经使用了索引的话,那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作;尽量不要包含多个列的排序,如果需要最好给这些列创建复合索引。
    6、like语句操作
    一般情况下不鼓励使用like操作,如果非使用不可,如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。
    7、不要在列上进行运算
    select * from users where YEAR(adddate)<2007;
    将在每个行上进行运算,这将导致索引失效而进行全表扫描,因此我们可以改成
    select * from users where adddate<‘2007-01-01';
    8、不使用NOT IN和<>操作
    NOT IN和<>操作都不会使用索引将进行全表扫描。NOT IN可以NOT EXISTS代替,id<>3则可使用id>3 or id<3来代替。
    展开全文
  • 数据库优化

    千次阅读 2019-11-03 11:48:00
    数据库优化

    数据库优化

    1. SQL查询优化

    • 避免全表扫描,应考虑在 where 及 order by 涉及的列上建立索引
    • 查询时使用select明确指明所要查询的字段,避免使用select *的操作
    • SQL语句尽量大写,如SELECT name FROM t WHERE id=1
    • 尽量避免在 where 子句中使用!=或<>操作符, MySQL只有对以下操作符才使用索引:<,<=,=,>,>=,BETWEEN,IN,以及某些时候的LIKE,如SELECT id FROM t WHERE name LIKE ‘abc%’
    • 对于模糊查询,如:SELECT id FROM t WHERE name LIKE ‘%abc%’将导致全表扫描,应避免使用,若要提高效率,可以考虑全文检索
    • 遵循最左原则,在where子句中写查询条件时把索引字段放在前面
    • 能使用关联查询解决的尽量不要使用子查询,能不使用关联查询的尽量不要使用关联查询
    • 不需要获取全表数据的时候,不要查询全表数据,使用LIMIT来限制数据

    2. 数据库优化

    对于表结构

    • 在进行表设计时,可适度增加冗余字段(反范式设计),减少JOIN操作;
    • 多字段表可以进行垂直分表优化,多数据表可以进行水平分表优化;
    • 选择恰当的数据类型,如整型的选择;

    对于SQL语句

    • 编写SQL时使用上面的方式对SQL语句进行优化;
    • 使用慢查询工具找出效率低下的SQL语句进行优化;

    对于索引

    • 对较频繁的作为查询条件的字段创建索引;唯一性太差的字段不适合单独创建索引,即使频繁作为查询条件;更新非常频繁的字段不适合创建索引;

    对于引擎

    • 对于强调快速读取的操作,可以考虑使用MyISAM数据库引擎;

    其他

    • 构建缓存,减少数据库磁盘操作;
    • 可以考虑结合使用内在型数据库,如Redis,进行混合存储
    展开全文
  • 面试不再尬聊的Mysql数据库优化方案

    万次阅读 多人点赞 2020-03-23 11:41:10
    数据库优化是一个老生常谈的问题,刚入门的小白或者工作N年的光头对这个问题应该都不陌生,你要面试一个中高级工程师那么他就想"哥俩好"一样那么粘,面试官肯定会问这个问题,这篇文章我们就和它哥俩好!而且这个...

    点赞多大胆,就有多大产!有支持才有动力!将技术分享给每一个技术使用者和爱好者!

    干货满满,摆好姿势,点赞发车!

     前言

    数据库优化是一个老生常谈的问题,刚入门的小白或者工作N年的光头对这个问题应该都不陌生,你要面试一个中高级工程师那么他就想"哥俩好"一样那么粘,面试官肯定会问这个问题,这篇文章我们就和它哥俩好!而且这个问题就是一个送分题,数据库的优化方案基本就是那些,答案也都是固定的,大家只要好好准备这个问题就不会住你,可以在面试中安排面试官,不然就被面试官安排!话不多说下边就针对数据库优化展开讲!

    相关文章

    《MySQL索引从零上手使用》

    《MySQL索引数据结构,看看什么是B+树吧》

    《基于MyCat实现MySQL读写分离》

    《基于MyCat实现MySQL数据拆分》

    面试开始

    小伙子看你简历上写了Mysql,数据库优化了解吗?

    摸摸头之后笑着说数据库优化不是很了解嘿嘿~~~,这时和蔼的面试官头上出现了一抹红!

    如果这时你正好想到了我这篇文章,那么你就会说数据库优化方面我还是很有研究的,请您听我慢慢道来......

    首先

    面试官我想解释一下为什么做数据库优化(这个你心里知道就好了,面试的时候就不要说了)

    • 系统的数据都从数据库上来,数据库的吞吐量和速度一定程度决定系统的并发和响应速度
    • 系统运行与数据量成正比,数据读处理尤其是查询自然就慢
    • Mysql数据库的数据最终在磁盘上持久化存储,读写不如Redis等这些内存数据库

    其次

    面试官大人我想说一下数据库优化一般从以下几个方面来:

    • 数据库设计:数据表设计遵循三范式,使用合适的数据类型,使用合适的存储引擎
    • 适当创建索引
    • 数据库扩展:数据库的分表分库,读写分离等
    • SQL语句优化等

    接下来我们一一说明解释

    数据库设计

    数据库设计3范式

    数据库设计范式如果要满足N范式必须要先满足N-1范式

    第一范式1NF:字段原子性

    第一范式简单的说就是表中的字段是最小不可再分的,我们下边举个例子,我们看到以下一张用户表。里边的字段是不可再分的,这样就符合第一范式的原子性,可能有些朋友会疑问,这个地址还可以分成省份、城市、区/县三个字段,是的!如果是一个电商项目它需要再分,那么就不符合第一范式,所以具体还是看项目的需求,没有固定标准,在项目需求中它的设计已不可再分那么就符合第一范式!

    第二范式2NF: 消除对主键的部分依赖

    2NF的使用是需要满足1NF为前提,在表中添加一个业务字段,而主键不用来做业务处理,比如我们的商品表有商品id,商品id为商品的主键,但是需要创建一个商品编号列来专门处理业务,因为id太敏感,我们处理业务都是用商品编号来处理,比如展示商品时展示编号等等!

    第三范式3NF:在2NF的基础上添加外键

    3NF的使用必须满足2NF,要求表中的每一列只与主键直接相关而不是间接相关,(表中的每一列只能依赖于主键),比如下面的例子,订单表中有客户相关信息,在分离出客户表之后,订单表中只需要有一个用户id即可(外键),而不能有其他的客户信息。因为其他的客户信息直接关联于用户id,而不是直接与订单id直接相关。如下图所示:

    分离之后:

    三大范式只是一般设计数据库的基本理念,可以建立冗余较小、结构合理的数据库。如果有特殊情况,当然要特殊对待,数据库设计最重要的是看需求跟性能,需求>性能>表结构。所以不能一味的去追求范式建立数据库!需求才是粑粑

    数据类型

    尽量使用可以正确存储数据的最小数据类型

    更小的数据类型意味着更快,占用更少的磁盘,内存、缓存和处理时间

    尽量使用整型表示字符串

    因为字符集和校对规则,使处理字符比整型更复杂,比如:我们使用数据库内置的datetime类型存储时间而不是字符类型,我们使用整型存储ip而不是直接将ip字符串存到数据库中

    尽可能使用not null

    这个值是很烦人的,建字段时请尽量指定是否非空,NULL使得索引,统计,比较都变得更复杂,而且索引尽量不要创建到可以为null的字段上

    字符串类型

    VARCHAR是可变长字符串

    比定长字符串(CHAR)更节省空间,仅使用必要的空间另外VARCHAR需要额外字节记录字符串长度(不同情况需要字节数不同)

    CHAR类型是定长字符串

    开发中基本很少用(一些公司甚至基本上不考虑这种类型了),注意:字符串长度定义不是字节数,是字符数

    日期和时间类型

    datetime

    使用8字节存储空间,保存从1001年到9999年的秒数。与时区无关,默认情况下,Mysql以一种可排序的格式显示它的值,例如:"2018-10-14 22:30:08"

    timestamp

    只使用4字节存储,保存1970年1月1日午夜以来的秒数,依赖于系统时区,和UNIX时间戳相同,转换函数分别为FROM_UNIXTIME()和UNIX_TIMESTAMP(),可以设置根据当前时间戳更新,比如我们熟悉的update_time字段

    整数类型

    UNSIGNED

    属性表示不允许负值,可以使得正数的上限提高一倍,比如tinyint+unsigned可以使原本的-128~127的范围变为0~255

    tinyint

    我们一般用它存储状态值而不要用int,如果是Boolean类型,那么tinyint(1)当值为1和0时,查询结果自动转为true和false,条件参数相应的也可以直接传入true和false即可

    INT(11)

    不会限制值的范围,只是规定了一些客户端工具用来显示的字符的个数,所以对于存储和计算来说INT(11)和INT(1)相同

    IP地址

    实际上是32位无符号整数,用INT存储,Mysql提供转换函数为INET_ATON()和INET_NTOA()

    小数

    decimal不会损失精度,存储空间会随数据的增大而增大。double占用固定空间,较大数的存储会损失精度,通常存金额用decimal(11,2),这表示整数部分和小数部分分别为9位和2位注意!,当然可以根据具体的金额大小选择长度,注意这时候对应的java中用BigDecimal类来处理运算时要仔细,因为加减法和比较跟平常不一样

    存储引擎

    介绍

    数据库存储引擎是数据库底层组件,数据库管理系统使用数据引擎进行创建、查询、更新和删除数据操作。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能,使用不同的存储引擎还可以获得特定的功能。我们可以通过SHOW ENGINES;

    InnoDB存储引擎

    InnoDB越做越好从MySQL5.5版本之后,MySQL的默认内置存储引擎已经是InnoDB,主要特点有

    1. 容灾恢复性比较好
    2. 支持事务,默认事务隔离界别为可重复读
    3. 使用的锁粒度为行锁,可以支持更高的并发
    4. 支持外键
    5. 配合一些热备工具可以支持在线热备份
    6. 在InnoDB中存在着缓冲管理,通过缓冲池,将索引和数据全部缓存起来,加快查询的速度
    7. 对于InnoDB类型的表,其数据的物理组织形式是聚簇表。所有的数据按照主键来组织。根据主键进行排序,数据和索引放在一块,都位于B+数的叶子节点上

    MyISAM存储引擎

    在5.5版本之前,MyISAM是MySQL的默认存储引擎,该存储引擎并发性差,不支持事务,所以使用场景比较少,主要特点有

    1. 不支持事务
    2. 不支持外键,如果强行增加外键,不会提示错误,只是外键不其作用
    3. 对数据的查询缓存只会缓存索引,不会像InnoDB一样缓存数据,而且是利用操作系统本身的缓存
    4. 默认的锁粒度为表级锁,所以并发度很差,加锁快,锁冲突较少,所以不太容易发生死锁
    5. 支持全文索引(MySQL5.6之后,InnoDB存储引擎也对全文索引做了支持),但是MySQL的全文索引基本不会使用,对于全文索引,现在有其他成熟的解决方案,比如:ElasticSearch,Solr,Sphinx等
    6. 数据库所在主机如果宕机,MyISAM的数据文件容易损坏,而且难恢复

    MEMORY存储引擎

    将数据存在内存中,和市场上的Redis,memcached等思想类似,为了提高数据的访问速度,主要特点有

    1. 支持的数据类型有限制,不支持TEXT和BLOB类型,对于字符串类型的数据,只支持固定长度的行,VARCHAR会被自动存储为CHAR类型
    2. 支持的锁粒度为表级锁。所以,在访问量比较大时,表级锁会成为MEMORY存储引擎的瓶颈
    3. 由于数据是存放在内存中,所以在服务器重启之后,所有数据都会丢失
    4. 查询的时候,如果有用到临时表,而且临时表中有BLOB,TEXT类型的字段,那么这个临时表就会转化为MyISAM类型的表,性能会急剧降低

    ARCHIVE存储引擎

    ARCHIVE存储引擎适合的场景有限,由于其支持压缩,故主要是用来做日志,流水等数据的归档,主要特点有

    1. 支持Zlib压缩,数据在插入表之前,会先被压缩
    2. 仅支持SELECT和INSERT操作,存入的数据就只能查询,不能做修改和删除;
    3. 只支持自增键上的索引,不支持其他索引

    CSV存储引擎

    数据中转试用,主要特点有

    1. 其数据格式为.csv格式的文本,可以直接编辑保存
    2. 导入导出比较方便,可以将某个表中的数据直接导出为csv,试用Excel办公软件打开

    选择依据

    如果没有特殊需求默认使用InnoDB引擎即可

    MyISAM:以读写插入为主的应用程序,比如博客系统、新闻门户网站。

    Innodb:更新(删除)操作频率也高,或者要保证数据的完整性;并发量高,支持事务和外键保证数据完整性。比如OA自动化办公系统

    索引

    已为客官备好,轻点哦《这小伙子把MySQL索引使用讲的真明白,真好,快来戳他》

    索引数据结构在这在这《搞懂MySQL数据库索引数据结构这一篇足够从此不再萌萌哒》

    MySQL读写分离

    点一下就会《看了这篇文章觉得MySQL读写分离这么简单》

    MySQL分表分库

    一样点一下就成《手把手基于Mycat实现MySQL数据拆分》

    SQL优化

    这里列举出来一些用过的,看到的欢迎大家评论区补充讨论

    1、查询尽量避免全表扫描,首先考虑在where、order by字段上添加索引

    2、避免在where字段上使用NULL值,所以在设计表时尽量使用NOT NULL约束,有些数据会默认为NULL,可以设置默认值为0或者-1

    3、避免在where子句中使用!=或<>操作符,Mysql只对<,<=,=,>,>=,BETWEEN,IN,以及某些时候的LIKE使用索引

    4、避免在where中使用OR来连接条件,否则可能导致引擎放弃索引来执行全表扫描,可以使用UNION进行合并查询

          select id from t where num = 30 union select id from t where num = 40;

    5、尽量避免在where子句中进行函数或者表达式操作

    6、最好不要使用select * from t,用具体的字段列表代替"*",不要返回用不到的任何字段

    7、in 和 not in 也要慎用,否则会导致全表扫描,如

    select id from t where num IN(1,2,3)如果是连续的值建议使用between and,select id from t where between 1 and 3;

    8、select id from t where col like %a%;模糊查询左侧有%会导致全表检索,如果需要全文检索可以使用全文搜索引擎比如es,slor

    9、limit offset rows关于分页查询,尽量保证不要出现大的offset,比如limit 10000,10相当于对已查询出来的行数弃掉前10000行后再取10行,完全可以加一些条件过滤一下(完成筛选),而不应该使用limit跳过已查询到的数据。这是一个==offset做无用功==的问题。对应实际工程中,要避免出现大页码的情况,尽量引导用户做条件过滤

    关注本系列文章的朋友应该发现,这里的未完待续已经消失,我们的MySQL优化就告一段落,主要从数据库设计、索引、数据库拆分和SQL语句上进行优化,更多优化方案希望大家通过评论区让晓添和读者朋友们都学习到,谢谢阅读,点赞收藏和关注!


     路漫漫其修远兮,吾将上下而求索

    展开全文
  • 数据库优化方案整理

    万次阅读 多人点赞 2018-08-29 16:05:16
    数据库优化策略有很多,设计初期,建立好的数据结构对于后期性能优化至关重要。因为数据库结构是系统的基石,基础打不好,使用各种优化策略,也不能达到很完美的效果。 B:数据库优化的几个方面 ​​ 可以看...
  • mysql数据库优化方案

    2018-04-16 17:09:34
    简单描述数据库优化方案,以及数据库一些常用的操作,包括一些简单的查询语句,函数使用等等
  • 全面深入Mysql数据库优化

    千人学习 2019-09-26 11:44:58
    本课程作为MySQL高级课程, 主要讲解了MySQL中的视图/存储过程/触发器/索引等对象的使用、常见的SQL语句优化的技巧 、应用优化、数据库优化、数据库日志等方面的知识,并通过综合案例,对课程中的知识进行一个整合...
  • 数据库优化 - 实例优化

    千次阅读 2019-10-25 10:30:00
    从网上去搜数据库优化基本都是从SQL层次进行优化的,很少有提及到数据库本身的实例优化。就算有也都是基于某个特定数据库的实例优化,本文涵盖目前市面上所有主流数据库的实例优化(Oralce、MySQL、POSTGRES、达梦)...
  • 数据库优化思路

    万次阅读 2016-05-04 00:29:48
    最近在学习后端,弄到数据库这一块,一直听到数据库优化,下午在公司老师提了下,现在记录下,大体的方法。首先: 最根本的是优化MYSQL的 一些配置参数,因为MYSQL原生只支持,数十个并发访问。要是数量级是万级百万...
  • 数据库优化详解

    千次阅读 2020-03-06 10:59:44
    数据库优化从以下几个方面优化: 数据库设计—三大范式、字段、表结构 数据库索引 存储过程 (模块化编程,可以提高速度) 分表分库 (水平分割,垂直分割) 主从复制、读写分离 SQL 调优 对 MySQL 配置...
  • MySql数据库优化

    千次阅读 2020-01-21 11:36:50
    数据库优化,是一种综合性的技术,不是通过某一种方式让数据库效率提高很多,而是通过各个方面的优化,来是数据库效率明显的稳步的提高。 主要包括以下: 1、库表的设计优化(三种范式) 2、库表添加合适的索引...
  • MySQL数据库优化的八种方式(经典必看)

    万次阅读 多人点赞 2018-08-12 17:18:52
    MySQL/Oracle数据库优化总结(非常全面) 置顶2017年08月21日 21:05:30 阅读数:8442   MySQL数据库优化的八种方式(经典必看) 引言:   关于数据库优化,网上有不少资料和方法,但是不少质量参差不齐...
  • 数据库SQL优化大总结之 百万级数据库优化方案
  • 1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 2、应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描 3、应尽量避免...
  • 数据库优化指南

    2012-08-05 15:03:56
    数据库优化指南,数据库优化指南
  • 数据库优化原则

    千次阅读 多人点赞 2014-12-30 19:49:13
    本文总结了一些数据库的优化规则和设计知识,整理出来20条数据库优化的实践原则···
  • mysql数据库优化大全

    万次阅读 多人点赞 2018-01-14 00:16:34
    数据库优化 sql语句优化 索引优化 加缓存 读写分离 分区 分布式数据库(垂直切分) 水平切分 MyISAM和InnoDB的区别: 1. InnoDB支持事务,MyISAM不支持,对于InnoDB每一条SQL语言都默认封装成事务,自动...
  • MySQL数据库优化概述

    千次阅读 2016-06-26 08:57:19
    一,数据库优化的目的 1,避免出现页面访问错误 由于数据库的timeout产生的5**错误; 由于慢查询造成的也没无法加载; 由于阻塞造成数据无法提交;2,增加数据库的稳定性 很多数据库的问题都是由于低效的查询...
  • 数据库SQL优化大总结1之- 百万级数据库优化方案 http://blog.csdn.net/wuhuagu_wuhuaguo/article/details/72875054
  • oracle数据库优化总结

    万次阅读 2018-07-11 16:35:03
    1. 数据库优化基本知识I/O 数据库的基本作用就是实现对数据的管理与查询。随之而来的就是大量的IO操作, 在海量数据的情况下,数据库的性能问题有80%以上和IO有关。优化ORACLE数据库的I/O性能一般有两个方面,一是...
  • 数据库优化常用方案

    千次阅读 2019-05-17 10:32:51
    从图中可以很明显的看出Mysql数据库优化的常用方法以及成本的高低。sql语句的优化和索引的优化是成本最小但是效果最好的方法,关于这两点我总结了如下几个优化方法: 1、sql语句中不使用子查询,比如delete from ...
  • MySQL数据库优化实践

    千人学习 2019-05-10 08:59:55
    本课程介绍了如何优化数据库的设计 和 sql语句,以及数据表等优化。 课程难点: MySQL引擎优化,和索引优化原理,以及服务器的主从复制,包括sql语法分析等,在web优化中都是我们需要主意的细节。
  • 一、MySQL数据库优化策略

    千次阅读 2020-05-17 18:17:01
    MySQL数据库优化策略 数据库性能取决于数据库级别的几个因素,例如表,查询和配置设置。这些软件结构导致在硬件级别执行CPU和I / O操作,必须将这些操作最小化并使其尽可能高效。在研究数据库性能时,首先要学习软件...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 91,942
精华内容 36,776
关键字:

数据库优化