索引

接上篇 elasticsearch 启动运行 ，启动后即可索引json格式文档 给文档添加索引 PUT命令指定将文档添加到某个索引，需要唯一文档id，和k-v对格式的请求体 curl -X PUT "localhost:9200/customer/_doc/1?pretty" -H 'Content-Type: application/json' -d' { "name": "John Doe" } ' 创建一个名为 customer 的索引（如果不存在）添加一个id=1的文档，存储文档并对 name 字段进行索引 返回 { "_index" : "customer", "_type" : "_doc", "_id" : "1", "_version" : 2, "result" : "updated", "_shards" : { "total" : 2, "successful" : 1, "failed" : 0 }, "_seq_no" : 1, "_primary_term" : 4 } 因为是新文档，所以版本号_version 为1 查询文档 次数es集群中任一节点都可查询到该文档 curl -X GET "localhost:9200/customer/_doc/1?pretty" { "_index" : "customer", "_type" : "_doc",

Record和PL/SQL表 一，什么是记录Record和PL/SQL表？ 记录Record：由单行多列的标量类型构成的临时记录对象类型。类似于多维数组。 PL/SQL表：由多行单列的索引列和可用列构成的临时索引表对象类型。类似于一维数组和键值对。 都是用户自定义数据类型。 二，Record + PL/SQL表 用途是什么？ Record + PL/SQL表可以进行数据的多行多列存储。这样我们就可使用Record + PL/SQL表在需要时封装一个临时的表对象，进行传递和操作。 通过Record自定义表结构，封装一条记录。PL/SQL表声明 可用列 类型 为Record类型（将可用列指向Record类型变量），每个索引对应一个Record类型变量。 三，使用Record + PL/SQL表进行数据的多行多列存储 ①声明Record类型和PL/SQL表， 其中PL/SQL表的索引列为主键约束和唯一约束列或自增Integer。可用列为Record类型或%RowType类型。 ②填充PL/SQL表可用列（Record类型）：通过索引指向Record，使用Record访问记录成员。 语法： PL/SQL表名(索引列值).记录成员 := 记录成员类型值； 或 PL/SQL表名(索引列值) := Record类型变量； --注意其PL

摘自 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

在日常工作中，我们有时会开慢查询去记录一些执行时间比较久的SQL语句，找出这些SQL语句并不意味着完事了，此时我们常常用到explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描。所以我们深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用。（QEP：sql生成一个执行计划query Execution plan） mysql> explain select * from servers; +----+-------------+---------+------+---------------+------+---------+------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+---------------+------+---------+------+------+-------+ | 1 | SIMPLE | servers | ALL | NULL | NULL | NULL | NULL |

1，为什么要对elasticsearch进行生命周期管理？ ES索引存活数量过多，会给ES集群带来较大压力，不仅严重影响数据录入和数据查询效率，而且导致磁盘、CPU占用比过高，加大节点“驾崩”的风险。对ES进行索引生命周期管理意义重大，不仅能提高服务器性能，降低内存和磁盘使用率，而且能够优化数据结构，提升读写、查询效率，避免数据丢失情况出现。 2，如何对elasticsearch进行生命周期管理？ 针对索引，根据时间、空间、类型、优先级进行不同种类的管理策略。推荐以时间序列为导向对数据进行应用策略操作。 对于时间序列索引，索引生命周期中有五个阶段： 热数据–索引正在积极更新和查询。 暖数据–索引不再更新，但仍需要查询。 冷数据–索引不再被更新，且很少被查询。数据仍然需要搜索，但查询速度较慢也没关系。 数据归档–索引不在被更新和查询，但需要存储以作备份。 数据删除–不再需要索引，可以安全删除。 以时间序列为导向，控制索引的老化时间，将3天以内的数据定义为热数据，3天以上7天以内的数据定义为暖数据，7天以上30天以内的数据定义为冷数据，30天以上数据进行归档，无需归档的数据进行删除。经过优化处理，可极大提高ES的可用性，避免数据丢失。 3，用什么对elasticsearch进行生命周期管理？ 进行ES索引生命周期管理可借助工具。ES 7

解释 还是从一维数组出发.看下面的例子. import numpy as np a = np.array([3, 1, 2, 4, 6, 1]) print(np.argmax(a))4 argmax返回的是最大数的索引.argmax有一个参数axis,默认是0,表示第几维的最大值.看二维的情况. import numpy as np a = np.array([[1, 5, 5, 2], [9, 6, 2, 8], [3, 7, 9, 1]]) print(np.argmax(a, axis=0))[1,2,2,1] 为了描述方便,a就表示这个二维数组.np.argmax(a, axis=0)的含义是 a[0][j], a[1][j], a[2][j] (j=0,1,2,3)中最大值的索引.(每1列的最大索引) 从a[0][j]开始,最大值索引最初为(0,0,0,0),拿a[0][j]和a[1][j]作比较,9大于1,6大于5,8大于2,所以最大值索引由(0,0,0,0)更新为(1,1,0,1),再和a[1][j]作比较,7大于6,9大于5所以更新为(1,2,2,1).再分析下面的输出. import numpy as np a = np.array([[1, 5, 5, 2], [9, 6, 2, 8], [3, 7, 9, 1]]) print(np.argmax(a,

回表：回到主键索引树搜索的过程，称为回表 覆盖索引：某索引已经覆盖了查询需求，称为覆盖索引，例如：select ID from T where k between 3 and 5 在引擎内部使用覆盖索引在索引K上其实读了三个记录，R3~R5(对应的索引k上的记录项)，但对于MySQL的Server层来说，它就是找引擎拿到了两条记录，因此MySQL认为扫描行数是2 最左前缀原则：B+Tree这种索引结构，可以利用索引的"最左前缀"来定位记录 只要满足最左前缀，就可以利用索引来加速检索。 最左前缀可以是联合索引的最左N个字段，也可以是字符串索引的最左M个字符 第一原则是：如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的。 索引下推：在MySQL5.6之前，只能从根据最左前缀查询到ID开始一个个回表。到主键索引上找出数据行，再对比字段值。 MySQL5.6引入的索引下推优化，可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。 来源： https://www.cnblogs.com/lakeslove/p/12238777.html

sql语句的实质行为就是从磁盘上的文件中读取数据，数据在磁盘上存储是随机IO，效率较低，所以我们需要“索引”B+tree 数据存储时是以页为单位存储的 为什么不用HashTable、二叉树？ HashTable的存储原理是：HashTable的底层也是数组，根据一定算法将key转化成下标，存储至数组中，查询是直接根据key算出下标从数据中拿到数据，K-V的结果不适合存储复杂数据结构的数据，比如一条数据中有多个字段需要存储，另外HashTable的存储顺序是随机的，不能查询大于、小于，只适合精确查找。 完全对称二叉树为什么不合适？ 因为二叉树存储是有序的，完全对称二叉树可以做大于、小于的运算，但是在查找过程中要回去查找父节点中储存的元素，不利于检索 B+tree B+tree也是有序的，在存储过程中是将所有非叶子节点的数据冗余一份到叶子节点中，在查找过程中只关注同级节点就可以了，所以B+tree的有点就在于区间查询，另外B+tree中一个节点存储了多个元素，有助于节省磁盘IO次数。 聚合索引：新建表是默认分配1页资源，索引与数据存在一起，插入数据达到本页最大限制时（默认16k），将第一页复制一份，并开辟一页新的资源，原第一页修改为目录页，以此类推，B+tree形成 ，建表时的第一页目录通常会被缓存，数据量越大，缓存越多。所以建表时务必指定主键索引，如果没有指定，也没有建其他唯一索引

mongo索引 索引的基本理解 索引实际就是对指定字段进行排序的数据结构 。 基于B-Tree的结构提升查询速度。 （时间复杂度logn） 复合键索引可以对多个字段进行排序。复合键索引只能支持前缀子查询 例如创建的复合查询为(a,b,c),匹配的时候只能按照从左往右的形式，比如 (a),(a,b)但是不能对(b,c)或者(b)不能加速索引。 查询索引:db.collection.getIndexes(), 创建索引:db.collection.createIndex(), 删除索引:db.collection.dropIndex() 索引的创建 默认索引 _id db.collection.createIndex({name:1}) #1从小到大排序 返回值 numIndexesBefore:1 numIndexesAfter:2 查询索引:db.collection.getIndexes() 创建复合键索引 db.collection.createIndex({name:1,balance:-1}) #1从小到大排序 多键索引 包含数组元组的字段创建索引。创建方法和单键的一致。 指定为后端形式创建索引 存在大量数据的集合上创建索引是非常耗时的，而且在创建索引的时候，会阻塞所有的读和写请求，一致到索引创建完成。这个时候可以通过设置为在后端创建