索引

取一个list或tuple的部分元素是非常常见的操作,使用循环显得十分繁琐，但是Python提供了切片操作符（Slice），能很简单的完成对列表或者元组进行取值。接下来根据列表L和L2写几个例子， L = ['tom','bob','mary','lisa','jack'] L2= list(range(50)) 1.L[0:3] L[0:3]表示，从索引0开始取，直到索引3为止，但不包括索引3。即索引0，1，2，正好是3个元素 2.L[:3] 如果第一个索引是0，还可以省略 3.L[1:] 取索引为1到末尾的值 4.L[-2:] 倒数第第二个元素到末尾，倒数第一个元素是L[-1] 5.L2[:10] 取前十个值 6.L2[-10:] 取后十个值 L2[10:20] 前11-20个数 L2[:20:2] 前10个数，每两个取一个 9.L2[::10] 所有数 每隔十个取一个 来源： 51CTO 作者： swq8023 链接： https://blog.51cto.com/8922100/2480729

字符串中的常用方法 所有用单引号，双引号，反引号抱起来的都是字符串 每一个字符串都是由零到多个字符组成的 str.length //=>代表字符串的长度 str[10000] //=>不存在的索引会返回undefined charAt / charCodeAt charAt:根据索引获取指定位置的字符 charCodeAt:获取指定字符的ASII码值(Unicode编码值) params参数 n[number] 获取字符指定的索引 return 返回查找到的字符(找不到的话返回的是空字符串不是undefined)或者对应的编码值 let str = "zhufengjiaoyu"; console.log(str.charAt(0)); //"z" console.log(str[0]); //"z" console.log(str.charAt(100)); //空字符串 console.log(str[100]); //undefined console.log(str.charCodeAt(0)); //"122" console.log(str.charCodeAt(100)); //NaN console.log(String.fromCharCode(122)); //"z" 实现字符串截取的三个方法 substr / substring / slice substr

在自然语言处理和文本分析的问题中，词袋（Bag of Words, BOW）和词向量（Word Embedding）是两种最常用的模型。更准确地说，词向量只能表征单个词，如果要表示文本，需要做一些额外的处理。下面就简单聊一下两种模型的应用。 所谓BOW，就是将文本/Query看作是一系列词的集合。由于词很多，所以咱们就用袋子把它们装起来，简称词袋。至于为什么用袋子而不用筐（basket）或者桶（bucket），这咱就不知道了。举个例子： 文本1：苏宁易购/是/国内/著名/的/B2C/电商/之一 这是一个短文本。“/”作为词与词之间的分割。从中我们可以看到这个文本包含“苏宁易购”，“B2C”，“电商”等词。换句话说，该文本的的词袋由“苏宁易购”，“电商”等词构成。就像这样： 但计算机不认识字，只认识数字，那在计算机中怎么表示词袋模型呢？其实很简单，给每个词一个位置/索引就可以了。例如，我们令“苏宁易购”的索引为0，“电商”的索引为1，其他以此类推。则该文本的词袋就变成了： 是的，词袋变成了一串数字的（索引）的集合。这样计算机就能读懂了。如果用程序来描述的话，就会像：Set<int>(0,1,2…)。当然，刚才的例子中像“苏宁易购”等词只出现了一次，如果出现多次，可能就需要支持重复元素的容器了，如Java/C++中的MultiSet。 可是，在实际的应用中（如：文本的相似度计算）

mysql大数据量使用limit分页，随着页码的增大，查询效率越低下。 测试实验 1. 直接用limit start, count分页语句， 也是我程序中用的方法： select * from product limit start, count 当起始页较小时，查询没有性能问题，我们分别看下从10， 100， 1000， 10000开始分页的执行时间（每页取20条）， 如下： select * from product limit 10, 20 0.016秒 select * from product limit 100, 20 0.016秒 select * from product limit 1000, 20 0.047秒 select * from product limit 10000, 20 0.094秒 我们已经看出随着起始记录的增加，时间也随着增大， 这说明分页语句limit跟起始页码是有很大关系的，那么我们把起始记录改为40w看下（也就是记录的一般左右） select * from product limit 400000, 20 3.229秒 再看我们取最后一页记录的时间 select * from product limit 866613, 20 37.44秒 难怪搜索引擎抓取我们页面的时候经常会报超时，像这种分页最大的页码页显然这种时 间是无法忍受的。

1、haystack简介 Haystack是django的开源全文搜索框架(全文检索不同于特定字段的模糊查询，使用全文检索的效率更高 )，该框架支持 Solr,Elasticsearch,Whoosh, Xapian，搜索引擎它是一个可插拔的后端（很像Django的数据库层），所以几乎你所有 写的代码都可以在不同搜索引擎之间便捷切换； - 全文检索不同于特定字段的模糊查询，使用全文检索的效率更高，并且能够对于中文进行分词处理； - haystack：django的一个包，可以方便地对model里面的内容进行索引、搜索，设计为支持whoosh,solr, Xapian,Elasticsearc四种全文检索引擎后端，属于一种全文检索的框架； - whoosh：纯Python编写的全文搜索引擎，虽然性能比不上sphinx、xapian、Elasticsearc等，但是无二进制包， 程序不会莫名其妙的崩溃，对于小型的站点，whoosh已经足够使用； - jieba：一款免费的中文分词包，如果觉得不好用可以使用一些收费产品； 2、安装 pip3 install django-haystack pip3 install whoosh pip3 install jieba #pip3 install -i https://pypi.tuna.tsinghua.edu.cn/simple

这章涉及记忆性的东西太多。 下面简要讲一下一些主要的内容，关于属性表的内容则省略，虽然貌似也挺重要，但是这方面的知识点太多。 如图所示Class类文件的结构按照从上往下排序依次也对应着class二进制文件里的顺序。 下面则是书上内容的一些摘要： 6.1 Class文件 Class文件是一组以8字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在Class文件中，中间没有添加任何分隔符若遇到需要占用8字节以上空间的数据时，则会按照高位在前的方式分割成若干组8位字节进行存储。 Class文件格式采用一种类似于C语言结构体的伪结构来存储，这种结构只有两种数据类型：无符号数和表。 那么无符号数和表又是什么呢? 无符号数属于基本的数据类型，以u1,u2,u4,u8来分别代表1个字节，2个字节，4个字节和8个字节的无符号数，无符号数可以用来描述数字、索引引用、数量值、或者按照UTF-8编码构成字符串值 表是由多个无符号数或其他表作为数据项构成的复合数据类型，所有表都习惯性地以“_info”结尾，整个Class文件本质上就是一张表。 6.2 魔数(magic Number) Class文件的头4个字节，作用：确定这个文件是否为一个能被虚拟机接受的Class文件。值为：0xCAFEBABE(咖啡宝宝) 这个好理解，比如EXE文件打开前面都也会有一个标记，jpg这些格式也是存在这种标记的。

前言： 如果碎片程度小于30%，建议使用重组而不是重建。因为重组不会锁住数据页或者数据表，并且降低CPU的资源。 总得来说，重组会清空当前的B-TREE，特别是索引的叶子节点，重组数据页和消除碎片。和重建不同，重组不会添加任何新数据页。 准备工作： 为了了解是否有必要重组索引，需要首先查看碎片程度，如果在10%以下，那一般没必要做什么维护，如果在10%~30%，就建议进行重组。 步骤： 1、 以下各种重组索引的方法： --不指定参数重组索引： ALTER INDEX [idx_refno] ON [ordDemo] REORGANIZE GO --重组表中所有索引： ALTER INDEX ALL ON [ordDemo] REORGANIZE GO --使用DBCC INDEXDEFRAG重建表上所有索引： DBCC INDEXDEFRAG( 'AdventureWorks', 'ordDemo') GO --使用DBCC INDEXDEFRAG重组表上一个索引： DBCC INDEXDEFRAG( 'AdventureWorks', 'ordDemo', 'idx_refno') GO 2、 DBCC INDEXDEFRAG命令同样是后续不建议继续使用的命令。 分析： 索引重组，也可以称为碎片重组，对单独索引的操作将使用单独的线程。不可以并行操作。所以同一时刻只有一个索引被操作

InnoDB两大类索引 聚集索引(clustered index) 普通索引(secondary index) InnoDB聚集索引的叶子节点存储行记录，因此， InnoDB必须要有，且只有一个聚集索引 （1）如果表定义了PK，则PK就是聚集索引； （2）如果表没有定义PK，则第一个not NULL unique列是聚集索引； （3）否则，InnoDB会创建一个隐藏的row-id作为聚集索引； 画外音：所以PK查询非常快，直接定位行记录。 InnoDB 普通索引 的叶子节点存储主键值。 画外音：注意，不是存储行记录头指针，MyISAM的索引叶子节点存储记录指针。 假如有如下的表： user(id PK, name Key ,sex) 其中表中有4条数据： 1，zhangsan,19 3, lisi ,22 5, wanger 29 9, mazhi 10 两个B+树索引分别如上图： （1）id为PK，聚集索引，叶子节点存储行记录； （2）name为KEY，普通索引，叶子节点存储PK值，即id； 既然从普通索引无法直接定位行记录，那 普通索引的查询过程是怎么样的呢？ 通常情况下，需要扫码两遍索引树。 这就是所谓的回表查询，先定位主键值，再定位行记录，它的性能较扫一遍索引树更低。 实战引用： 组合索引结构图： create table t1 (a int primary key, b

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

创建索引时，可以指定一个填充因子，以便在索引的每个叶级页上留出额外的间隙和保留一定百分比的空间，供将来表的数据存储容量进行扩充和减少页拆分的可能性。填充因子的值是从 0 到 100 的百分比数值，指定在创建索引后对数据页的填充比例。值为 100 时表示页将填满，所留出的存储空间量最小。只有当不会对数据进行更改时（例如，在只读表中）才会使用此设置。值越小则数据页上的空闲空间越大，这样可以减少在索引增长过程中对数据页进行拆分的需要，但需要更多的存储空间。当表中数据会发生更改时，这种设置更为适当。 填充因子越大,意味着一个索引页包含的索引记录越多,空闲空间越小.一般来说查询的效率越高,因为这样查询的时候,可以减少读取索引页的工作量和减少内存使用 但这样导致的结果是数据变动导致的索引维护的工作量增加,因为索引页的空闲空间小,如果不能在本页内完成索引调整,就会引起调整其他索引页 所以一般的选择是,数据基本不变化的（例如OLAP的场景，数据只用来分析的）,将填充因子设置到足够大,数据经常变化的（例如OLTP的场景）,将填充因子设置为足够小 来源： https://www.cnblogs.com/chenxizhang/archive/2008/08/17/1269682.html