索引

15_其它数据库对象 目 标 一、常见的数据库对象 二、序列 1.CREATE SEQUENCE 语句 2.序列相关的两个伪列（NEXTVAL 和 CURRVAL 伪列） 3.查询序列 4.使用序列 5.修改序列 5.1.修改序列的注意事项 6.删除序列 三、索 引 1.创建索引 2.什么时候创建索引 3.什么时候不要创建索引 4.删除索引 四、同义词-synonym 1.创建和删除同义词 总 结 目 标 通过本章学习，您将可以: 创建、维护和使用 序列 创建和维护索引 创建同义词 一、常见的数据库对象 二、序列 序列: 可供多个用户用来产生唯一数值的数据库对象 自动提供唯一的数值 共享对象 主要用于提供主键值 将序列值装入内存可以提高访问效率 1.CREATE SEQUENCE 语句 CREATE SEQUENCE sequence [ INCREMENT BY n ] --每次增长的数值 [ START WITH n ] --从哪个值开始 [ {MAXVALUE n | NOMAXVALUE} ] [ {MINVALUE n | NOMINVALUE} ] [ { CYCLE | NOCYCLE} ] --是否需要循环 [ {CACHE n | NOCACHE} ] ; --是否缓存登录 实例： CREATE SEQUENCE student_stutid_seq

用来记笔记的软件电脑端登不进去了，本来打算过了这段时期，专门总结下知识点，那就直接写在这里吧，有什么问题欢迎指出。 按功能分类 普通索引 唯一索引 主键索引 组合索引 外键索引 全文索引 按结构分类 B+ Tree索引：InnoDB和MyISAM Hash索引：Memory B+ Tree B+ Tree 是基于 B Tree 和叶子节点顺序访问指针进行实现的，一个节点中的key从左到右非递减排列。 Hash 哈希索引能以 O(1) 时间进行查找，但是失去了有序性： 无法用于排序与分组； 只支持精确查找，无法用于部分查找和范围查找。 InnoDB 存储引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的非常频繁时，会在 B+Tree 索引之上再创建一个哈希索引，这样就可以实现快速的哈希查找。 InnoDB存储引擎 InnoDB的数据文件本身就是索引文件。 叶子节点data域保存了完整的数据记录，这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引（这样的索引成为聚集索引）。 InnoDB的辅助索引data域存储相应记录主键的值。这使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引。 MyISAM存储引擎 MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址，索引文件和数据文件是分离的。 比较

文章目录 索引 索引原理 索引技巧与注意事项 建立索引的原则 利用索引排序 InnoDB索引模型 联合索引 聚集索引 辅助索引 覆盖索引 索引合并 Cardinality（基数） 查看索引 Cardinality 优化器选择不使用索引的情况 MRR 验证MRR ICP 验证ICP 索引 只有当索引帮助存储引擎快速查找到记录的带来的好处大于其带来的额外工作时，索引才是有效的。对于非常小的表，大部分情况下简单的全表扫描更高效 在一个100w条数据的表中，如果某一列没有添加索引，那么每一句select语句都要随机地逐条扫描100w行数据，每次都要从中寻找0或者更多匹配的行。虽然这些数据最初是按照顺序加载的，但sql也不能理解这种顺序，它必须要处理所有行才能找到匹配的数据。添加索引并不总能自动改善所有类型的SQL查询的性能。有时候执行全表扫描反而更加高效，这取决于所要求的行数。这就是两种不同访问方式的差异，即通过随机IO操作来获取个别行的数据和使用查询索引及有序IO操作来读取所有数据。 索引除了在给定表上限制需要读取的数据外，索引的另一个主要用途就是快捷高效地在相关的表之间做Join操作。在需要Join的列上使用索引可以显著提升性能，并可以在另一个表中快速找到一个匹配的值。 优点 索引大大减少了服务器需要扫描的数据量 索引可以帮助服务器避免排序和临时表 索引可以将随机IO变为顺序IO

建立索引是优化数据库最直接的手段.遵循以下索引优化原则,可以建立比较高效和合理的索引. 在索引中包含条件的所有列,可以使用索引形成的屏蔽来拒绝结果集中不合适的行 对于需要排序的引用列,适当地创建索引可以避免排序 考虑到管理上的开销,应避免在索引中使用多于5个的列 对于多列索引,将查询中引用最多的列放在定义的前面 不要在索引中包含经常修改或进行插入、删除的列(主关键字和外来关键字除外) “$”符号不可以作为索引的首字母,”.”不能在索引名的任何位置出现. 索引管理 1.建立索引的函数:ensureIndex(); eg.在name上建立索引1(升序)，-1(降序)，默认为升序. db.person.ensureIndex( { name : 1 } ); 当系统已有大量数据时,创建索引非常耗时,需要在后头执行,只需要指定background:true即可. db.user.ensureIndex( { age : 1 } , { background : true } ); 建立索引后,同一条查询语句比较2次扫描的记录条数. > db.user.find( { name:"user5" } ).explain(); 2.获取集合中的索引信息 db.person.getIndexKeys(); db.person.getIndexes(); 3.创建唯一索引

摘要 数据库性能对软件整体性能有着至关重要的影响，对于Mongodb数据库常用的性能优化方法主要有： 范式化与反范式化； 填充因子的使用； 索引的使用； 一. 范式化与反范式化 范式是为了消除重复数据减少冗余数据，从而让数据库内的数据更好的组织，让磁盘空间得到更有效利用的一种标准化标准，满足高等级的范式的先决条件是满足低等级范式。在数据库设计阶段，明确集合的用途是对mongodb数据库性能调优非常重要的一步。根据集合中数据最常用的操作，对于频繁更新和频繁查询的集合，我们最需要关注的重点是他们的范式化程度。 1.1 范式化 1.1.1 范式化的优点： 范式化的数据库更新起来更加快； 范式化之后，只有很少的重复数据，只需要修改更少的数据； 范式化的表更小，可以在内存中执行； 很少的冗余数据，在查询的时候需要更少的distinct或者group by语句。 1.1.2 范式化的缺点： 范式化的表，在查询的时候经常需要很多的关联，因为单独一个表内不存在冗余和重复数据。这导致，稍微复杂一些的查询语句在查询范式的schema上都可能需要较多次的关联。这会增加让查询的代价，也可能使一些索引策略无效。因为范式化将列存放在不同的表中，而这些列在一个表中本可以属于同一个索引。 1.1.3 范式化设计的例子： 以存储一篇图书及其作者为例，作者的信息包括作者的姓名，年龄，国籍。使用范式化的设计如下： {

目录 一、 选择合适的存储引擎: InnoDB 1.1 怎样将现有的 MyISAM 数据库转换为 InnoDB: 1.2 为每一个表分别创建 InnoDB FILE： 二、 保证从内存中读取数据。讲数据保存在内存中 2.1 足够大的 innodb_buffer_pool_size 2.1.1 怎样确定 innodb_buffer_pool_size 足够大。数据是从内存读取而不是硬盘？ 2.1.2 server上是否有足够内存用来规划 2.2 数据预热 2.3 不要让数据存到 SWAP 中 三、定期优化重建数据库 四、降低磁盘写入操作 4.1 使用足够大的写入缓存 innodb_log_file_size 4.2 innodb_flush_log_at_trx_commit 4.3 避免双写入缓冲 五、提高磁盘读写速度 六、充分使用索引 6.1 查看现有表结构和索引 6.2 加入必要的索引 6.2.1 比方，优化用户验证表： 6.2.2 使用自己主动加索引的框架或者自己主动拆分表结构的框架 七、分析查询日志和慢查询日志 八、激进的方法。使用内存磁盘 九、用 NOSQL 的方式使用 MYSQL 十、其它 MYSQL 应该是最流行了 WEB 后端数据库。WEB 开发语言近期发展非常快，PHP， Ruby, Python, Java 各有特点，尽管 NOSQL 近期越來越多的被提到

MySQL索引以及优化总结 B树和B+树结构 MyISAM与InnoDB 的存储区别 索引的本质 联合索引（最左前缀匹配原则） B树和B+树结构 MySQL为什么要用B+树：与二叉树和红黑树不同的是B树的节点上可以存放多个索引，这样降低了树的高度，使得查询效率更高。B+树在B树的基础上加以改进，父节点存放冗余索引，叶子节点存放所有的索引和数据（可能是索引对应行数据的文件地址或，也可能是整行数据），并且节点之间通过指针相互关联，查询效率进一步提升。 MyISAM与InnoDB 的存储区别 InnoDB 是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高，但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，否则其他索引也会很大。而 MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针，主键索引和辅助索引是独立的。 索引的本质 为什么索引一般选用tree而不用hash：因为hash只使用与指定值的查找而范围查找就需要全表扫描。 联合索引（最左前缀匹配原则） 最左前缀匹配原则，是一个非常重要的原则，可以通过以下这几个特性来理解。 1、对于联合索引，MySQL 会一直向右匹配直到遇到范围查询（> ， < ，between，like）就停止匹配。比如 a = 3 and b = 4 and c > 5 and d

Hbase索引表的结构 Hbase Rowkey 设计 Hbase Filter Hbase二级索引 Hbase索引表的结构 　 　在HBase中，表格的Rowkey按照字典排序，Region按照RowKey设置split point进行shard，通过这种方式实现的全局、分布式索引，成为了其成功的最大的砝码 　　每一个索引建立一个表，然后依靠表的row key来实现范围检索。row key在HBase中是以B+ tree结构化有序存储的，所以scan起来会比较效率。 单表以row key存储索引，column value存储id值或其他数据 ，这就是Hbase索引表的结构。 　　Hbase QualifierFilter用于过滤qualifier，也就是一个列族里面data:xxx，冒号后面的字符串 Hbase Rowkey 设计 　　大数据最好从rowkey入手，ColumnValueFilter的数度是很慢的，hbase查询速度还是要依靠rowkey，所以根据业务逻辑把rowkey设计好，之后所有的查询都通过rowkey，是会非常快。 批量查询最好是用 scan的startkey endkey来做查询条件 　　rowkey是hbase中很重要的一个设计，如果你把它当成普通字段那你的设计就有点失败了。它的设计可以说是一门艺术。你的查询如果不能把rowkey加入进来

01 引言 随着用户的增长、业务的发展，大型企业用户的业务系统的数据量越来越大，超大数据表的性能问题成为阻碍业务功能实现的一大障碍。其中，流水表作为最常见的一类超大表，是企业级用户经常碰到的性能瓶颈。 本文就以流水类的超大表，探讨基于SequoiaDB巨杉数据库存储的超大表进行的性能调优。SequoiaDB 巨杉数据库，作为新一代 OLTP 的分布式数据库，被广泛使用于海量数据存储与高并发操作场景中。对于海量数据的存储和高并发操作，分布式数据库相较于传统数据库有着天然的优势，合理利用SequoiaDB巨杉数据库多种特性，轻松解决超大表的性能问题。 02 数据存储规划很重要 对于流水类超大表，前期的数据存储规划尤为重要，合理的数据存储规划能有效利用数据库集群硬件资源，提供更高性能、更高效率的数据服务。 集群规模评估与硬件配置搭配 在数据库集群规划伊始，需要通过调研数据库集群支撑应用规模、系统定位和业务长期发展规划进行摸底，用以评估集群规模以及各服务器的CPU、内存、硬盘、网卡的合理搭配。 精准的评估一个数据库集群规模，是一个宏大且复杂的综合工程，需要有的业务需求评估数据加以支持。通常情况下，由于业务需求变化快、业务增长普遍高于预期，小集群规划可以按照业务调研信息的1.5~2倍进行评估，大集群规划可以按1~1.5倍进行评估。 集群规模需要通过业务规模、数据存储规模

索引目的 索引的目的在于提高查询效率，可以类比字典，如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。如果没有索引，那么你可能需要把所有单词看一遍才能找到你想要的，如果我想找到m开头的单词呢？或者w开头的单词呢？是不是觉得如果没有索引，这个事情根本无法完成？ 索引原理 除了词典，生活中随处可见索引的例子，如火车站的车次表、图书的目录等。它们的原理都是一样的，通过不断的缩小想要获得数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是我们总是通过同一种查找方式来锁定数据。 数据库也是一样，但显然要复杂许多，因为不仅面临着等值查询，还有范围查询(>、<、between、in)、模糊查询(like)、并集查询(or)等等。数据库应该选择怎么样的方式来应对所有的问题呢？我们回想字典的例子，能不能把数据分成段，然后分段查询呢？最简单的如果1000条数据，1到100分成第一段，101到200分成第二段，201到300分成第三段……这样查第250条数据，只要找第三段就可以了，一下子去除了90%的无效数据。但如果是1千万的记录呢，分成几段比较好？稍有算法基础的同学会想到搜索树，其平均复杂度是lgN，具有不错的查询性能。但这里我们忽略了一个关键的问题，复杂度模型是基于每次相同的操作成本来考虑的，数据库实现比较复杂，数据保存在磁盘上