oracle索引

逍遥山人的MySQL使用笔记，持续更新中 表结构 新建表以及添加表和字段的注释 create table t_user( ID INT(11) primary key auto_increment comment '主键', NAME VARCHAR(255) comment '姓名', CREATE_TIME date comment '创建时间' )comment = '用户信息表'; 修改字段类型 alter table tablename modify column column_name varchar(30); 查看表结构 查看表的字段、字段类型、索引等 DESC tablename; 或 SHOW COLUMNS FROM tablename; 或包含字符集、字段注释等 SHOW FULL FIELDS from table_name; 查看表生成的DDL 注意表名不加单引号 show create table 表名; 查看分区表的分区情况 SELECT partition_name part, partition_expression expr, partition_description descr, table_rows FROM information_schema.PARTITIONS WHERE table_schema = SCHEMA() AND

前言： 今天在这里总结一下Mysql索引，也给自己加个印象。 我的座右铭：即使记性再差，仍要坚持多读多看。 概念 Mysql索引的建立对于Mysql的高效运行是很重要的，索引可以大大提高Mysql的检索速度。 Mysql目前主要有以下5中索引类型： 普通索引 唯一索引 主键索引 组合索引 全文索引 缺点： 索引也有它的缺点，过多的滥用索引，也会降低更新表的速度。如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。建立索引会占用磁盘空间的索引文件。 5种索引类型 普通索引 这是最基本的索引，他没有任何限制。可以用如下方式创建： 直接创建索引 create index index_name on table ( column ( length ) ) 修改表结构的方式添加索引： alter table table_name add index index_name on ( column ( length ) ) 创建表的时候同时创建索引 CREATE TABLE ` table ` ( ` id ` int ( 11 ) NOT NULL AUTO_INCREMENT , ` title ` char ( 255 ) CHARACTER NOT NULL , ` content ` text CHARACTER NULL

前面一篇文章从实例的角度进行数据库优化，通过配置一些参数让数据库性能达到最优。但是一些“不好”的SQL也会导致数据库查询变慢，影响业务流程。本文从SQL角度进行数据库优化，提升SQL运行效率。 判断问题SQL 判断SQL是否有问题时可以通过两个表象进行判断： 系统级别表象 CPU消耗严重 IO等待严重 页面响应时间过长 应用的日志出现超时等错误 可以使用sar命令，top命令查看当前系统状态。 也可以通过Prometheus、Grafana等监控工具观察系统状态。（感兴趣的可以翻看我之前的文章） SQL语句表象 冗长 执行时间过长 从全表扫描获取数据 执行计划中的rows、cost很大 冗长的SQL都好理解，一段SQL太长阅读性肯定会差，而且出现问题的频率肯定会更高。更进一步判断SQL问题就得从执行计划入手，如下所示： 执行计划告诉我们本次查询走了全表扫描Type=ALL，rows很大(9950400)基本可以判断这是一段"有味道"的SQL。 获取问题SQL 不同数据库有不同的获取方法，以下为目前主流数据库的慢查询SQL获取工具 MySQL 慢查询日志 测试工具loadrunner Percona公司的ptquery等工具 Oracle AWR报告 测试工具loadrunner等 相关内部视图如v 、 、 、 session_wait等 GRID CONTROL监控工具 达梦数据库

36. 用 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, 那就需要返回记录最少的索引列写在最前面 . 注意 : WHERE KEY1 = 10 ( 返回最少记录 ) OR KEY2 = 20 ( 返回最多记录 ) ORACLE 内部将以上转换为 WHERE KEY1 = 10 AND ((NOT KEY1 = 10) AND KEY2 = 20)

摘自 http://www.cnblogs.com/ATree/archive/2011/02/13/sql_optimize_1.html 1、 首先要搞明白什么叫执行计划？ 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个 10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用 “全表扫描”方式。 可见，执行计划并不是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要： (1) SQL语句是否清晰地告诉查询优化器它想干什么？ (2) 查询优化器得到的数据库统计信息是否是最新的、正确的？ 2、 统一SQL语句的写法 对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。 select*from dual select*From dual 其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划。所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！ 3、 不要把SQL语句写得太复杂 我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的

前面一篇文章从实例的角度进行数据库优化，通过配置一些参数让数据库性能达到最优。但是一些“不好”的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

背景说明： 今天查阅书籍时，偶然间发现“在对某个索引行执行删除操作时，只是为该行增加了一个删除标记，这个索引行并不会释放它的存储空间，Insert产生的新的索引行也不能被插入到该位置。索引列的修改过程其实是将对应的列值删除，然后再插入新的列值（与数据行本身的修改是不一致的，这也正是我们尽量不使用修改频繁的列来创建索引的原因）。所以，无论是插入、修改、删除，都需要消耗存储空间，增大B-Tree索引结构的深度，影响数据的查询速度。尤其是删除和修改，不仅造成了存储空间的浪费，而且增加了扫描索引块的数量”，这就是所谓的索引碎片问题，建议定期对经常使用的表执行检查和重建索引操作。 问题重现： 经测试，收集统计信息等操作，无法释放索引删除块所占用的存储空间。 analyze table tkk29 compute statistics; select t.index_name, t.distinct_keys, t.num_rows, t.sample_size, t.last_analyzed , t.blevel, t.leaf_blocks, t.* from user_indexes t where t.table_name = upper('tkk29'); delete from tkk29 where mod(trunc((sysdate-createddate) * 24 *

　　 一、问题的提出 　在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用 系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优 化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的 SQL语句，提高系统的可用性。 　　在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的 SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种 原则来删除索引，这有助于写出高性能的SQL语句。 　　二、SQL语句编写注意问题 　　下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。 　　 1. IS NULL 与 IS NOT NULL 　　 不能用null作索引

索引结构（Index Structure） 所有的SQL Server 索引都是 B-Trees 。在这种树的顶端有一个 根页（root page） ，通过root page来访问N个 中级（intermediate level）页 ，直到树的底部、或 叶级（leaf level） 。可以通过树中每个节点的指针从上向下扫描整个索引树。另外，每个索引级（index leves）（可能是intermediate leve or leaf level）都有一个页链（page chain）。在一个索引中有许多intermediate level。索引树的级数（树的高度）与索引码的宽度、索引类型、记录行数和表中的页数有关，并且索引树的级数是影响索引性能的一个重要参数。 非聚集索引（Nonclustered Indexs） 一个非聚集索引 与一本书的索引相似。数据存储在一个地方，索引存储在另外一个地方 ，可以通过索引中的指针来访问存储的数据。索引中的条目是按照索引码的值按序存储，但是表中的信息可以按照不同的顺序存储（如可以按照聚集索引存储）。如果表中没有创建聚集索引，那么表中的记录就不能保证按照某种特定的顺序。 与你用一本书的索引方式一样，SQL Server2000也是先通过非聚集索引检索到查找数据在表的位置，然后通过该位置来检索数据。 这使得非聚集索引非常适合精确匹配查询（This

数据库： 　　简而言之可视为 电子化 的 文件柜 --- 储存电子文件的处所，用户可以对数据进行 CURD 所谓数据库是以一点方式储存在一起，能与多个用户共享，与应用程序彼此独立的集合 数据库管理系统： 　　英文名 Database Management System （ DBMS ） 是为管理数据而设计的电脑管理软件 一般都有 存储 截取 安全保障 等基础功能 类型： 　关系型数据库 　　MySQL 　　Microsoft SQL Server 　　Microsoft Access 　　Oracle 　　PostgreSQL 　非关系型数据库（ NoSQL ） 　　详细介绍见另文↓（传送门） 　　https://www.cnblogs.com/lky-19990802/p/10596229.html 数据库索引 ： 　　主条目：数据库索引 　　数据索引的观念由来已久，像是一本书前面几页都有目录，目录也算是索引的一种，只是它的分类较广，例如车牌、身份证字号、条码等，都是一个索引的号码，当我们看到号码时，可以从号码中看出其中的端倪，若是要找的人、车或物品，也只要提供相关的号码，即可迅速查到正确的人事物。 　　另外，索引跟字段有着相应的关系，索引即是由字段而来，其中字段有所谓的关键字段（ Key Field ），该字段具有唯一性，即其值不可重复，且不可为 " 空值 （ null ） "