sql优化

如何在 Oracle数据库里写出高质量的SQL语句，如何在Oracle数据库里对有性能问题的SQL做诊断和调整，这是DBA们在ORACLE数据库实践中不可避免的难题。下面就让我们来分析一下拿到一条问题sql后DBA可以如何去开始优化思路。 对于有问题的SQL做SQL优化的具体步骤一般为： 1、查看该SQL语句的执行计划，并结合其资源消耗情况和相关统计信息、Trace文件来分析其执行计划是否合理； 2、通过修正措施（如调整该SQL的执行计划等）来对该SQL做调整以缩短其执行时间，Oracle数据库里SQL优化的终极目标就是要缩短目标SQL语句的执行时间。要达到上述目的，我们通常只有如下三种方法可以选择： 1、降低目标SQL语句的资源消耗； 2、并行执行目标SQL语句； 3、平衡系统的资源消耗。 方法1：降低目标SQL语句的资源消耗”以缩短执行时间，这是DBA们最常用的SQL优化方法。这种方法的核心是要么通过在不更改业务逻辑的情况下改写SQL来降低目标SQL语句的资源消耗，要么不改SQL但通过调整执行计划或相关表的数据来降低目标SQL语句的资源消耗。 方法2：并行执行目标SQL语句”，这实际上是以额外的资源消耗来换取执行时间的缩短，很多情况下使用并行是针对某些SQL的唯一优化手段。 方法3：平衡系统的资源消耗” 可以避免不必要的资源争用所导致的目标SQL语句执行时间的增长

这段时间优化时，发现一个语句执行时间很长，效率很低，语句如下： select id,field015,field016,field017,field001,field020,field010,field014,field011,field013,field004,field018, field005,field007,field003,null ,requestid from ufv3a7n71178865841875 tbalias where requestid in( select id from workflowbase wb where wb.isdelete<>1 and isfinished=0 ) and exists (select 'X' from Permissiondetail p where p.objid=tbalias.requestid and p.objtable='workflowbase' and ((p.userid='40282c48177be3a001177fefe73843d8') or (( p.isalluser=1 or p.orgid='40288a7d0f55fb5a010f569c2bf01205') and (p.minseclevel <= 10 and ((( p.maxseclevel is not null)

在使用Exists时，如果能正确使用，有时会提高查询速度： 1，使用Exists代替inner join 2，使用Exists代替 in 1，使用Exists代替inner join例子: 在一般写sql语句时通常会遇到如下语句： 两个表连接时，取一个表的数据，一般的写法通过关联查询（inner join）： select a.id, a.workflowid,a.operator,a.stepid from dbo.[[zping.com]]] a inner join workflowbase b on a.workflowid=b.id and operator='4028814111ad9dc10111afc134f10041' 查询结果： (1327 行受影响) 表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。 表 'workflowbase'。扫描计数 1，逻辑读取 293 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。 表 '[zping.com]'。扫描计数 1，逻辑读取 1339 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0

在SQL Server中，存储过程是比视图更强大。视图让我们简单地做一个SELECT查询也在可视图本身，它的工作方式是用于运行复杂的查询。 但视图并不姝真正为我们提供代码业务逻辑的能力。例如，视图不会能让我们增加条件代码(如IF语句)。幸运的是存储过程可能使用。 什么是存储过程？ 存储过程是一组SQL语句编译成一个SQL。类似于在说的SQL脚本页面，在这里可以运行许多SQL脚本合为一个整体。 然而，存储过程并不仅仅是一个长脚本。这是已保存在SQL Server中明确在存储过程节点的脚本。存储过程通常包含一些业务逻辑。 例如，一个存储过程可以接受被传递给它的并针对这些参数测试使用IF语句的参数。例如，如果该参数是一个值，这样做，如果它是另一个值。 它们包含业务逻辑的能力使存储过程SQL Server的强大的一部分。存储过程可以提高性能的应用程序，因为存储过程进行解析，并尽快，因为它是建立优化，然后存储在内存中。运行通过存储过程条件的查询可以是非常快 - 相比，发送查询通过网络，到SQL Server的应用程序，遂将全部返还给它在网络上，因此它可以过滤通过它，并挑选出只是它感兴趣的记录数据。 存储过程的好处 下面是一些在使用存储过程的主要优点： 好处 说明 模块化编程 可以写一个存储过程一次，然后一次又一次地调用它，从应用程序的不同部分（甚至多个应用程序）。 性能

MySQL手册中find_in_set函数的语法： FIND_IN_SET(str,strlist) str 要查询的字符串 strlist 字段名 参数以”,”分隔 如 (1,2,6,8) 查询字段(strlist)中包含(str)的结果，返回结果为null或记录 假如字符串str在由N个子链组成的字符串列表strlist 中，则返回值的范围在 1 到 N 之间。 一个字符串列表就是一个由一些被 ‘,’ 符号分开的子链组成的字符串。如果第一个参数是一个常数字符串，而第二个是type SET列，则FIND_IN_SET() 函数被优化，使用比特计算。 如果str不在strlist 或strlist 为空字符串，则返回值为 0 。如任意一个参数为NULL，则返回值为 NULL。这个函数在第一个参数包含一个逗号(‘,’)时将无法正常运行。 用find_in_set(str,strList)函数去进行处理，一个字段多条件的查询 set @field = ‘xx1,xx2’; select * from table where find_in_set(field,@field); 来源： CSDN 作者： snmlm 链接： https://blog.csdn.net/u011133810/article/details/104758547

前言 从 Mysql 数据库角度来说，谈到存储就一定离不开字符集，只不过在我们日常开发中统一的 utf8/utf8mb4 编码，使我们常常忽略了字符集的影响，本文仅从字符集的角度来谈谈对 InnoDB 的存储设计的一点影响，以及 Mysql 是怎么兼容各种字符集的。 过一下字符集 Unicode 作为现在通用的字符集，通常采用两个字节表示一个字符，带来的副作用就是，原本采用 ASCII 字符集只需要一个字节的，却变成了 2 个字节，造成了空间浪费，而 UTF-8 编码规则，将 Unicode 编码成 1～4 个字节，ASCII 字符集继续保持了 1 个字节空间，而中文编码成了三个字节，如下图。 对存储带来了什么影响 先说明下 Mysql 中存在两种字符集 utf8 和 utf8mb4，以下例子均以 Mysql 的 utf8（1～3个字节）为例。 采用 utf8 编码的确很不错，但是也带来了一个问题，例如我在 Mysql 中定义了一个定长字符类型 char(5)： name type length title char 5 所谓定长字符类型代表我要给 title 分配 5 个字符大小的空间，可是 utf8 每个字符可能是 1～3 个字节，我该分配多少空间合适呢？ 理论上为了兼容，最好应该采用 utf8 的最大 3 个字节进行分配，也就是 5*3 = 15 个字节的空间

数据库使用过程当中索引的时候必不可少，合理创建索引可以极大地提升数据查询效率，但是如何索引创建不当也会影响我们的查询效率，如果想使用好索引我们就要来关注一下索引的原理。本文主要讲的mysql索引，且以InnoDB引擎为主，顺带与MyISAM引擎做对比。 1.Mysql表空间、段、区、页 在讲索引的概念之前我们先说一下mysql中段区页的概念。 表空间是Mysql数据库存储的最高层，默认情况下InnoDB引擎只有一个表空间，所有的数据都是存放在这个表空间内。 在表空间下数据是以段区页的形式进行存储的。一张Mysql表存储在数据库当中不是以行为单位存储数据读取的，mysql数据库读取的最小单位是页。 段：一个段是由多个区构成的， 常见的段有数据段、索引段、回滚段等，在InnoDB存储引擎中，对段的管理都是由引擎自身所完成的。 区：一个区是由多个 连续的页组成的空间 ，无论页的大小怎么变动，一个区的默认大小是1M，默认情况下一个区包含64个连续的页，为保证区中的页是连续的 InnoDB会一次从磁盘中申请4~5个区。 页：页也叫做块，默认情况下一个页大小为16K(可以通过 innodb_page_size 参数来设置一个页的大小)， 常见的页类型有：数据页，索引页， undo页 ，系统页，事务数据页等。 每页存储最多的行记录也是有硬性规定的最多16KB/2-200,即7992行 。

说实话，这个问题可以涉及到 MySQL 的很多核心知识，可以扯出一大堆，就像要考你计算机网络的知识时，问你“输入URL回车之后，究竟发生了什么”一样，看看你能说出多少了。 之前腾讯面试的实话，也问到这个问题了，不过答的很不好，之前没去想过相关原因，导致一时之间扯不出来。所以今天，我带大家来详细扯一下有哪些原因，相信你看完之后一定会有所收获，不然你打我。 开始装逼：分类讨论 一条 SQL 语句执行的很慢，那是每次执行都很慢呢？还是大多数情况下是正常的，偶尔出现很慢呢？所以我觉得，我们还得分以下两种情况来讨论。 1、大多数情况是正常的，只是偶尔会出现很慢的情况。 2、在数据量不变的情况下，这条SQL语句一直以来都执行的很慢。 针对这两种情况，我们来分析下可能是哪些原因导致的。 针对偶尔很慢的情况 一条 SQL 大多数情况正常，偶尔才能出现很慢的情况，针对这种情况，我觉得这条SQL语句的书写本身是没什么问题的，而是其他原因导致的，那会是什么原因呢？ 数据库在刷新脏页我也无奈啊 当我们要往数据库插入一条数据、或者要更新一条数据的时候，我们知道数据库会在 内存 中把对应字段的数据更新了，但是更新之后，这些更新的字段并不会马上同步持久化到 磁盘 中去，而是把这些更新的记录写入到 redo log 日记中去，等到空闲的时候，在通过 redo log 里的日记把最新的数据同步到 磁盘 中去。 不过

一、表设计优化 　　1、简单既优 　　　　数组和字符要给范围，不易过长过大 　　　　时间尽量使用时间戳格式，占用的存储空间比较少 　　　　字段和表注释必不可少 　　2、索引设置 　　　　常用查询字段要添加索引 　　　　如果能使用联合索引代替的尽量使用联合索引代替 　　3、合适的表引擎 　　　　myisam更适合读写较快的地方 　　　　innodb更适合处理事务和更新删除 二、查询优化 　　1、范查询最好禁止 　　　　查询字段要具体，尽量避免使用* 　　2、尽可能使用索引 　　　　根据不同索引，查询时最好使用索引 　　3、exists和in使用特点 　　　　如果查询的两个表大小相当，那么用in和exists效率差别不大 　　　　如果两个表中一个较小，一个较大，则子查询表大的用exists，子查询表小的用in 三、数据量过高优化 　　1、分区分表，mysql5.5之后分区逐渐代替了分表 　　2、主从设置，可以一主多从和多主多从 四、sql分析 　　1、explain 后面跟sql语句 　　主要的字段 type，rows，keys ； 　　　　type指定了该sql使用那种类型的查询 　　　　keys知道了该sql使用了那些索引 　　　　rows知道了查询结果需要遍历多少行才可以得到结果 五、常见mysql配置 　　错误日志 　　　log-error= dir 　　慢查询 　　　

昨天晚上看探索栏目， 深海捕捞帝王蟹；在遥远的阿拉斯加，捕捞船若捞上来的是 母蟹会全部重新放到海里 ，每个人手上拿了一个尺子， 若尺寸没达标的公蟹会重新放到大海 里，邪恶的美国你为什么这么强大、我愿意当个幸福的母蟹、但是千万不要把我生在邪恶的东海， 曾经从来没想移民的愿望，看了这期探险节目后，更加懂了什么叫爱护环境爱护地球了。我们的东海别说螃蟹，好像连虾米都被电死得差不多了干得竟都是断子绝孙的事儿，邪恶的美帝你太强大了。希望我们不要成为人类的害虫。 我们可以无知，但是不能愚昧，不能干太多断子绝孙的事情，保护我们生存环境从你我做起。 好久没写博客了，一方面是日常工作繁忙，另外一方面是想更多的时间陪陪家里人，享受春天的美好时光，还在写一本 《程序员，你伤不起》 的一本书要由人民邮电出版社出版；我的性格可能也跟大多数程序员类似吧，没什么兴趣爱好、不擅长与人交流、平时话也少、也不够幽默，唯一的优点就是一个实实在在。 下图命名为：孤独的程序员 其实真正优化信息化系统的核心，还是要靠优化那些SQL语句，当然顶尖高手写的SQL语句没多少可优化的余地，毕竟不是人人都是工作10年以上的资深软件开发人员，有时候由于忙、事情紧急、或者没充分考虑业务逻辑，或者根本没想到网站从一个无名小站变成行业出名的站点。平时事情也是千头万绪只要服务器在能抗得过就没怎么关注吧。 最近我看了主服务器的SQL语句耗时比较多